Opening moment or tension

My final-year project was a 3D campus map. Students lost time finding lecture halls and offices they had never visited before, so a few of us built something that would show them where everything was. The presentation went well. Judged as a piece of work, it was sound.

I had never asked a student whether a map was what they needed.

That reads like an obvious omission now. At the time it did not feel like an omission at all, because I had not knowingly skipped anything. I heard that students get lost. Somewhere between hearing that and opening the editor, it became "students need a better map." I never noticed the substitution happen. Everything after it was execution, and the execution was fine.

What the obvious explanation misses

The obvious explanation is that this is a research failure and the fix is to do research. That is true, and it is not very useful, because almost every team that fails this way believes it did its research.

What the explanation misses is where the failure actually happens. It is not at the moment a team decides to skip user interviews. It happens earlier and much faster, in the sentence where someone converts a user's goal into a solution shape. "Students get lost" becomes "a map." "I need someone reliable to fix my sink" becomes "a directory of plumbers." The conversion is quick and it does not feel like a decision at the time. It usually happens in the first conversation anyone has about the idea, often before a word of it is written down.

From that moment on, the shape is the thing being built, and every quality process in the company measures the work against the shape. Code review checks that the shape is implemented well. QA checks that the shape holds up. Design polish makes the shape pleasant to move through. The demo shows the shape working.

Not one of those steps contains a question about whether the shape is right. That is not a defect in them. They were never built to ask it.

Evidence

FACT: I built a 3D campus map as a final-year project with friends, to reduce confusion finding university locations. No student was interviewed about the problem before the build began.

INTERPRETATION: the job was reducing confusion about where things were. A map is one possible answer to that job. It is not the job itself. Other answers existed and were never weighed, because by the time anyone could have weighed them the shape was already fixed. I am reading this back with judgment I did not have then.

FACT: more recently I was brought into an artisan-services marketplace as a contracted product manager, after building had already started. My brief was to check whether what was being built had been built for the people meant to use it. The app followed a familiar pattern: browse the providers near you, read their profiles and past jobs, compare, choose, book. It was competently built.

FACT: I ran ten interviews. The same pattern kept surfacing: when people need an artisan, they tend to ask someone they already trust rather than go looking for one. I do not have a record of how those ten split between homeowners and artisans, which limits how hard that finding can be leaned on.

INTERPRETATION: they were not looking for a catalogue. The part they found hardest was deciding whether a stranger could be trusted inside their home, and it was the part they least wanted to own. The product had taken that exact decision and handed it back to them, presented as a feature. Profiles, ratings, past jobs, side-by-side comparison: all of it is choosing infrastructure. The team had built a good version of the work customers wanted least.

FACT, as a limit: the team went back and rebuilt around what the interviews showed. That rebuilt product has not launched publicly. I have no outcome to show you. What happened there is a decision, not a result, and the launch will test it.

HYPOTHESIS: that this failure is common in the specific way described here. That most teams who build the wrong thing did not skip the user at all, but converted the user's goal into a shape too early and then never revisited the conversion. Two instances make the pattern worth watching for. They do not make it a law.

The emerging principle

You can build the wrong product correctly.

The reason this survives so long is that it produces no error signal. A wrong product built badly gets caught early. It crashes, it confuses people, it fails review, somebody complains. A wrong product built well produces a clean build, a good demo, a team that feels slightly ahead of schedule, and a launch date everyone is looking forward to.

When it finally does surface, it almost never arrives labelled correctly. It arrives as flat growth, as signups that never return, as a sense that the market has not heard about you yet. Every one of those readings fits the evidence. Every one of them points the next round of spending somewhere other than the product.

There is a boundary worth stating, because the principle is easy to over-apply. This is not an argument that building should stop until the research is perfect. The conversion from goal to shape is necessary work. You cannot build a goal; you can only build a shape. The failure is not making the conversion. The failure is making it invisibly, and then treating it as settled ground rather than as the largest untested assumption in the company.

For builders

Take the main flow of your product and write down every step it asks a person to do. Then go through the list and ask, for each step, whether that person would pay money to not do it.

Steps people would pay to skip are work you have transferred to them. Some of that transfer is unavoidable and honest. But if something you think of as a core feature shows up on that list, the comparison view, the configuration screen, the choice you are proud of offering, then you have a candidate for a shape that was chosen by the people building rather than the people using.

Then ask the second question, which is harder to ask out loud in a room full of people who built the thing. Who authored this decision, and what had they actually observed? Not what they concluded. What they saw.

Ending

Evidence does not care how much you have already built.