Don't code yet: ten hours of user interviews save three months of rework

Founders regularly arrive at our door with a finished spec: two pages of features, a dozen wireframes, and one question — "how much, and how fast?" We usually ask one thing back: how many target users have you actually sat down with? Most of the time, the answer is zero.

That's not pedantry. The most common way startups die isn't failing to build the product — it's building something nobody wants. CB Insights' autopsy of a hundred-plus failed startups put "no market need" as the number-one cause of death at 42%, ahead of "ran out of cash" at 38%. The biggest risk in a project isn't in the development phase. It's before a single line is written.

Ten hours of interviews beat three months of coding

Nielsen Norman Group ran the famous math: testing with 5 target users exposes about 85% of usability problems — add more users and new findings drop off sharply. Our own coaching experience matches: interview 10 to 15 target users properly, and by the eighth or ninth, the complaints start repeating. That repetition is the moment the requirements list surfaces on its own.

Run the numbers: 10 users, 30 minutes each, plus scheduling and write-ups — a dozen hours in total. A core feature built in the wrong direction costs two to three months of development, then the same again to tear down and redo. The saddest case we've seen: a team spent four months building a "multi-account dashboard," only to discover after launch that 90% of real users had exactly one account. Three phone calls would have surfaced that fact.

Why nobody wants to ask

The excuses are always the same: "users don't know what they want," "interviews only produce fake needs," "Jobs never did market research." Half true — users genuinely can't articulate solutions, but they can describe their problems perfectly. An interview shouldn't ask "what features do you want." It should ask "last time you hit this problem, what did you do?" The first gets you politeness; the second gets you facts.

The Mom Test has a rule worth copying verbatim: never ask about future commitments ("would you pay for this?" — nobody says no to your face); only ask about past behavior ("when did you last spend money solving this, and how much?"). The money, time and detours a user has already spent on a problem are the true scale of demand. A verbal "I'd definitely use it" is worth nothing.

Three things that actually work

• Before coding, interview 10 target users, 30 minutes each. Ask only three things: how often do you hit this problem? What did you do last time? How much money or time has it cost you? Record their exact words, not your paraphrase — those words later become your product copy and page headlines.
• Compress the interviews into a one-page hypothesis. Who, in what scenario, hurting from what, willing to give what. If you can write that page, you've earned the right to wireframe. If you can't, keep interviewing.
• Validate the hypothesis with the smallest possible artifact before real development. A landing page collecting signups, a clickable demo, even a manually delivered "fake product" all work. Validation costs little, and being wrong in validation costs nothing — what costs money is skipping it and starting construction.

That's why every 51Kaifa engagement starts with a fixed ritual: before any development schedule, we write the target users, core scenarios and acceptance criteria onto one page with the client — and only then start. When the requirements are clear, a two-week MVP doesn't drag into three months of rework. Speed only matters once the direction is right.