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’d like to see code next week. I understand that, because code looks like progress and research looks like a delay. But building the wrong product is much more expensive, even if it’s built well.

Why we insist on it

In CB Insights’ 2021 analysis of 111 startup post-mortems, “no market need” was the second most common reason for failure at 35%, just behind running out of money. The numbers change from edition to edition, and they’re based on what founders said about their own startups, so I wouldn’t put too much weight on the exact figures. Still, they match what I see. Products rarely fail because of bad code. They fail because nobody needed them in the form they were built.

A few weeks of research won’t guarantee success. They do catch the big mistakes while they’re still cheap to fix.

What we do before writing code

“Discovery” sounds bigger than it is. Most of it is talking to the people who’ll use the product, about their day and not about our idea. We ask how they solve the problem today, what they’ve already tried and what it cost them. The best guide I know for these conversations is Rob Fitzpatrick’s The Mom Test. His main point is to ask about things people actually did, not what they think they’d do, because people are polite and will tell you your idea is great.

Then we test a rough, clickable version of the screens. Jakob Nielsen’s well-known rule of thumb says that about five users already show you most usability problems in one round. So we don’t run a big study, just a few honest sessions, fix what we find and test again.

With AI features we also check early whether the idea works technically. Can the model do it reliably, what does a request cost, and what happens when it gets something wrong? A day of trying this out can save a month of building on a wrong assumption.

How we sell it

At some point we stopped calling it “research”. We treat it as the first part of the build, and at the end the client gets three things: a short list of what goes into the first version and what doesn’t, tested screens the developers can build from, and a cost and time estimate we trust ourselves.

Clients care most about the estimate. After discovery it’s based on what we’ve learned, not on a guess from the first call, so there are fewer surprises and fewer arguments halfway through.

When we keep it short

Not every project needs much discovery. If the client has already talked to their users, has data, or is rebuilding something that already works, we keep it brief. The goal is to get rid of the biggest risk, and sometimes that’s already done.

When a client says “we know exactly what users want” but has never watched anyone use the product, though, we usually need it the most.