Small Team, Big Trap: Building for Yourself, Not Your Customer

When I started coding (many years ago), I built an app that I was very proud of at the time. It had functions and features I wanted. I was impressed with my own level of polish, I had achieve, it felt right to me. Then I put it in front of the others who I had envisaged would use it. They looked at it politely, complimented me, but never used it.

That gap between what I loved and what they needed took me a while to understand.

These days, I am regularly involved in many such conversations. One of your people , often technical or creative, has poured months into a product. They can tell you every impressive thing it does. They can walk you through the settings they agonised over. What they can't always tell you is who actually needs it, and why that person would part with money for it today.

It is an easy trap to fall into, and it is almost invisible from the inside. When you are the whole team, you are also the whole feedback loop. You are the designer, the tester, the first user, and the harshest critic, especially in today's age of "AI coding". So you build for the person you know best. Yourself. You solve the problem the way you would want it solved. You add the feature that would delight you. You polish the corner that only you will ever notice.

The problem is that you are not your customer. You have the context, the patience, and the tolerance for complexity that a customer simply does not have. What feels elegant to you can feel like effort to them. What feels essential to you might not even register as a problem for them.

This is a pattern I see play out again and again. The build is beautiful. The demand is assumed.

The shift is not about building less. It is about pointing your attention outward before you fall in love with your own solution. A few things that consistently help:

👉 Talk to customers before you build, not after. Ask people about their problem, not your product. Let them describe the pain in their own words. If they don't have the problem, no amount of polish will fix that. 👉 Watch what people do, not what they say. Someone will tell you a feature sounds great. Then they never use it. Behaviour is honest in a way that opinions are not. 👉 Sell it before it's finished. A pre-order, a deposit, a paid pilot. Money is the clearest commitment and signal you will ever get. Praise is cheap. Payment is not. 👉 Separate "would I use this" from "would they pay for this." These are two different questions. Your enthusiasm is not market demand. 👉 Kill the features nobody asked for. Every hour spent polishing something only you value is an hour not spent on what your customer actually needs.

None of this means abandoning your taste or your standards. Your judgement is part of why people will buy from you. But taste has to be in service of the customer, not the other way round. The goal is a product that earns its place in someone else's life, not just yours.

The hardest part is emotional. When you are small, the product often feels personal. Criticism of the product can feel like criticism of you. So you retreat into the "version" you can control. The version you already love.

I have learned to ask myself one uncomfortable question before I get too attached to anything I am building: am I solving this for my customer, or am I solving it for me?

When was the last time you asked a customer what they actually needed, and really listened to the answer?