There is a particular kind of builder who is dangerous to themselves. They wake up early. They ship code every day. They maintain a clean backlog. They feel productive because they are productive — by every internal metric they can invent.
And none of it matters, because no one is using what they build.
This is a story about that builder. It could be about several people we have watched over the years, but the shape is always the same.
The builder had a clear idea. A tool for small teams to manage a specific workflow — the kind of thing they had needed at a previous job and assumed others needed too. Fair enough. Many good products start with that assumption.
Month one: authentication, basic data model, a clean UI. Month two: an integration, notifications, a settings panel with too many options. Month three: an admin view, export to CSV, dark mode. Month four: a second integration, role-based permissions, onboarding tooltips. Month five: performance improvements, a billing page for a plan structure they had not validated, and a landing page with three feature comparison columns.
Month six: a blog post about the architecture.
Six months. Hundreds of commits. No users.
Not zero signups — a handful of people had poked around during a beta invite. But no one used the product for its stated purpose more than once. No one came back.
The builder interpreted this as a marketing problem.
Building is comfortable. You control the inputs. You control the outputs. The compiler does not have opinions about your roadmap. Deploys do not talk back.
Talking to prospects is uncomfortable. They say things you did not expect. They describe their problem differently than you framed it. They look at your carefully designed screen and ask, "What does this button do?" about the one button you thought was obvious.
So the builder kept building. Every feature was a small hit of completion. Every deploy was evidence of progress. The backlog shrank, which felt like forward motion. But the backlog was written by one person, for one person, based on guesses.
Shipping without feedback loops is just expensive journaling. You are recording your assumptions in code instead of a notebook. The output is more expensive but no more valid.
A friend who had shipped a real product — one with paying customers and support tickets and messy compromises — gave the builder blunt advice: stop building for two weeks. Talk to five people who match your target buyer. Not friends. Not other builders. People who have the problem you claim to solve and who are currently solving it some other way.
The builder resisted. Then relented.
The five conversations took eight days to arrange and about four hours total. Here is what came back:
Three of the five did not have the assumed problem. They had an adjacent problem, related but shaped differently. The tool as built addressed maybe 20% of what they actually needed.
Two of the five had the problem but had already solved it. One used a spreadsheet with a specific structure. The other used two existing tools wired together with manual steps. Both were annoyed by their solutions but not annoyed enough to learn a new product — unless it was dramatically simpler than what they had.
None of the five cared about dark mode, role-based permissions, or the second integration. One person asked for a feature that would have taken two days to build. It was not on the backlog. It had never occurred to the builder.
The builder went back and rebuilt. Not from scratch — there was plenty of sound infrastructure underneath. But they cut half the features from the UI, reframed the core workflow around the adjacent problem three prospects had described, and built the two-day feature.
Then they put it in front of the same five people.
Two started using it that week. One paid for it the following month.
More progress in two weeks than in six months. Not because the builder suddenly got better at building. They were always good at building. They got better at listening.
This pattern is not rare. It is the default for technically skilled people who work alone. The instinct is to build your way to clarity. But clarity about what customers need does not come from code. It comes from contact.
A few things worth remembering:
Velocity is not progress. Shipping fast in the wrong direction just gets you further from where you need to be.
Five conversations cost less than one feature. The time you spend building an unvalidated feature almost always exceeds the time it takes to learn whether anyone wants it.
Discomfort is data. If you are avoiding talking to prospects, that avoidance is telling you something. Usually that you suspect, quietly, that your assumptions might not hold.
The backlog is not the product. The product is the change in someone's workday. If no one's workday has changed, you do not have a product. You have a project.
There is nothing wrong with building for the joy of building. Side projects, explorations, learning exercises — all valuable. But if you intend to solve a real problem for real people, the work of understanding those people is not optional. It is not a phase you get to after the MVP. It is the MVP.
The builder in this story lost six months. They recovered. Many do not. They run out of savings, or motivation, or both, still convinced they had a marketing problem.
They never had a marketing problem. They had a listening problem. The fix was five conversations and the willingness to hear answers they did not want.
Be the first to comment.
0 comments
Loading comments...