What Customer Research Is Actually For

A lot of customer research gets conducted after the real decisions have already been made — a product has been scoped, a feature has been designed, and the interviews that follow are really just a search for validation. That’s not research. It’s confirmation-seeking wearing research’s clothes, and it tends to produce exactly the reassuring answers everyone was hoping for.

Research is for reducing a specific uncertainty

Good customer research starts from a genuine, specific uncertainty — not “do people like this?” but something closer to “will a small business owner actually change how they invoice customers to use this, or is the current way of doing it not actually painful enough to switch?” The narrower and more honest the question, the more useful the answer.

This matters because a vague question invites a vague, agreeable answer. Almost everyone will say they’d find a useful tool useful. Far fewer will say, specifically, what they currently do, why it’s frustrating, and what would have to be true for them to change it — and that second kind of answer is the one actually worth having.

What research can’t do

Customer research is very good at surfacing real problems, real language, and real behavior. It is much less reliable at predicting what people will do with something that doesn’t exist yet. People are honest about their past behavior and unreliable about their hypothetical future behavior — which is exactly why the strongest research questions ask about what someone already does, not what they’d theoretically do.

• Reliable: “Walk me through the last time you dealt with this problem.”
• Less reliable: “Would you use a feature that did X?”
• Reliable: “What have you tried already, and why didn’t it stick?”
• Less reliable: “How likely are you to buy this on a scale of one to ten?”

Using research to say no

The most valuable outcome of a round of customer research is often a confident no — evidence that a planned feature solves a problem few people actually have, before months are spent building it. That’s a much less satisfying result to present than a green light, which is exactly why it gets skipped so often. It’s also, frequently, the more useful finding.

Treated this way, customer research stops being a formality that happens before the real decision, and becomes part of how the decision gets made in the first place.

A Practical Way to Prioritise Product Features

Ask a product team how they prioritise, and you’ll often hear about a scoring framework with weighted columns for impact, effort, confidence, and reach — a spreadsheet elaborate enough to feel rigorous, and just complicated enough that everyone quietly overrides it whenever the numbers disagree with what they already wanted to build.

Complexity isn’t the same as rigor

A prioritisation framework’s job is to force an honest comparison between competing ideas. Once it gets complicated enough, it stops doing that — it becomes a way to justify a decision that’s already been made, dressed up in numbers that feel more objective than they are. That’s not a failure of the specific framework. It’s what happens to almost any scoring system once enough inputs get added to it.

A shorter version that still works

A simpler method holds up surprisingly well in practice: for each candidate feature, answer two questions honestly.

1. What specifically breaks if we don’t build this? Not “it would be nice to have” — a concrete cost, complaint, or lost opportunity that’s actually happening right now.
2. What’s the smallest version that addresses it? Not the fully-realised feature from the roadmap deck — the narrowest version that would genuinely fix the specific problem in question one.

Features where the answer to the first question is vague — “it would improve engagement,” “competitors have it” — usually don’t survive this filter, and that’s the point. Features tied to something concrete and currently happening tend to rise to the top without needing a spreadsheet to prove it.

Where this still needs judgment

This method won’t resolve genuine trade-offs between two well-justified features competing for the same engineering quarter — that still requires a judgment call, ideally made by someone accountable for the outcome. What it’s good for is clearing out the larger number of features that sound reasonable but aren’t actually solving a problem anyone currently has.

A shorter list, built from two honest questions, tends to produce a roadmap a team can actually defend — including to themselves, months later, when they’re asked why a particular feature made the cut.

Why Good Strategy Begins With Fewer Decisions

Ask a small business owner what their strategy is, and you’ll often get a list: expand into a new market, improve retention, launch a referral program, refresh the brand, hire a sales lead, and — somewhere near the bottom — fix the thing that’s actually losing them money every week. Every item on the list is defensible. That’s exactly the problem.

A strategy with twelve priorities isn’t a strategy. It’s a wish list with a deadline attached. The work of strategy isn’t generating good ideas — most experienced operators already have more good ideas than they can execute. The work is refusing most of them, on purpose, so the few that remain get the attention and resources they actually need to succeed.

The cost of an unfiltered list

Every additional priority doesn’t just add its own cost — it quietly taxes everything else on the list. A team split across six initiatives moves slower on all six than a team focused on two would move on those two alone. This is not a motivational problem. It’s arithmetic: attention, budget, and management time are fixed, and each new priority divides them further.

Founders often resist cutting the list because every item feels like a real opportunity being left on the table. That’s true. It’s also unavoidable. A strategy that tries to capture every opportunity captures none of them well.

What deserves to survive the cut

Three questions tend to separate what belongs on a real strategic list from what belongs on someone’s someday folder:

• Does it address the actual constraint? Not the loudest problem — the one thing actually limiting growth right now.
• Can it be started this quarter? A priority that depends on three other things happening first isn’t a priority yet.
• Would removing it change the outcome? If the business would end up in roughly the same place without it, it’s not strategic — it’s just activity.

Most lists survive this filtering down to two or three items. That feels uncomfortably small to most people the first time they do it. It’s also, almost always, the right size to actually execute against.

Fewer decisions, made well

The discipline isn’t in having fewer ideas. It’s in having the judgment to set most of them aside for later, and the follow-through to finish the few that remain before reaching for the next one. That’s a less exciting story to tell at a planning offsite than a twelve-point roadmap. It’s also the version that tends to actually happen.