Selling research to clients who want code tomorrow

Most clients come to us with a clear picture. They know what they want, they’ve been thinking about it for months, and they want to see code next week. I get it. Code feels like progress. Research feels like a delay.

But the most expensive thing you can build is the wrong thing, done well.

The wrong product is the real risk

When CB Insights went through startup post-mortems, “no market need” came up as the most common reason for failure in their 2021 analysis, cited by 42% of the companies. The exact number changes between editions of the report, and it’s based on what founders said about themselves, so take it with a grain of salt. But the pattern is hard to ignore. Many products don’t fail because the code is bad. They fail because nobody needed them the way they were built.

A few weeks of research won’t guarantee a hit. It does catch the big, obvious mistakes while they’re still cheap to fix.

What we actually do before writing code

“Discovery” sounds fancy. In practice it’s a short list:

• Talk to the people who’ll use it. Not about our idea, but about their day. How do they solve the problem today? What did they try? What did it cost them? Rob Fitzpatrick’s book The Mom Test is the best guide I know for this. Ask about real past behaviour, not opinions about the future, because people are nice and will tell you your idea is great.
• Test a rough version. Clickable screens, nothing more. Jakob Nielsen’s well-known rule of thumb is that around five users already reveal most of the usability problems in a test round. You don’t need a big study. You need a few honest sessions, then fix, then test again.
• Check what’s technically possible. Especially with AI features. Can the model actually do this reliably? What does it cost per request? What happens when it’s wrong? A one-day spike can save a month of building on a wrong assumption.

How we sell it

Here’s what changed for us. We stopped calling it “research” and started treating it as the first part of the build, with a clear result:

• a short list of what goes into the first version, and what doesn’t
• tested screens that the developers can build from
• a cost and time estimate we actually trust

That last point matters to clients more than anything else. An estimate after discovery is based on what we’ve learned, not on what we guessed in the first call. That means fewer surprises and fewer arguments halfway through the project.

When it’s fine to skip

Not every project needs a big discovery phase. If the client already talked to their users, has data, or is rebuilding something that already works, we keep it short. Research isn’t a ritual. It’s there to remove the biggest risk, and sometimes that risk is already gone.

But when someone says “we know exactly what users want” and has never watched one of them use the product, that’s usually when we need it most.