Product & Delivery · Chapter 3 of 13
Discovery when your users are not consumers
The literature describes consumer discovery. Most postings in this atlas are B2B, platform or internal — where the method differs.
Across 331 parsed product job descriptions, roadmap and strategy appear in 99% and customer research in 20%. That is not because these teams do not care about users. It is because in B2B, platform and internal contexts, the discovery method is different and the consumer playbook transfers badly.
What changes
| Consumer | B2B / platform / internal | |
|---|---|---|
| Sample size | Thousands; statistics work | Five to fifteen; statistics do not |
| Who you talk to | The user | The buyer, the admin and the user — often three different people who disagree |
| Signal | Behaviour in the product | What they will pay for, or what they build themselves instead |
| Experimentation | A/B tests on real traffic | Rarely possible; too few accounts, too much variance |
| The strongest evidence | Retention curves | A customer doing the thing manually today, at cost |
| The trap | Vocal minority | The loudest account — usually your largest, rarely representative |
What to do instead of A/B tests
- Find who is already solving it manually. A customer paying three people to do something by hand is far stronger evidence than any stated preference. Ask what it costs them today — that is your value ceiling.
- Separate the buyer from the user, deliberately. The buyer's problem is usually risk, cost or compliance; the user's is friction. A product that solves only one loses either the deal or the renewal.
- Ask about the last time, not the general case. ‘Walk me through the last time this happened’ produces facts; ‘would you use a feature that…’ produces politeness.
- For internal platforms, watch rather than ask. Sit with a team for a morning. What they complain about and what actually costs them time are frequently different things.
- Discount the largest account by default. Its requirements are real and they are not the market, and building a roadmap from them is how a product becomes one customer's bespoke system.
The four risks, and the one that gets skipped
The most durable discovery frame in the field names four risks, and it is worth knowing that the fourth was added to an older three-part version — explicitly because the older one was obscuring serious risks and making it too easy for product managers to focus on customer value while overlooking business value.
| Risk | The question | Who owns it |
|---|---|---|
| Value | Will customers buy it, or choose to use it? | Product manager |
| Usability | Can users work out how to use it? | Product designer |
| Feasibility | Can engineering build it with the time, skills and technology available? | Lead engineer |
| Business viability | Does it work for sales channel, legal and compliance, partner contracts, cost of acquisition, monetisation, brand? | Product manager — and this is the one candidates skip |
A candidate who answers a discovery question only in terms of value and usability is answering the older version of the framework. In a business-to-business context viability is usually the binding risk: the feature is desirable, usable and buildable, and it cannot ship because of a contractual commitment, a data-residency rule, or a sales compensation structure that makes nobody want to sell it.
Opportunities versus solutions
The structure that most improves a discovery answer is separating the opportunity space — customer needs, pains and desires — from the solution space, and hanging both under a business outcome rather than a customer one.
That root is deliberately a business outcome, and it is where most people get it wrong: a tree rooted in ‘customers are happier’ has no way to be prioritised against anything else the company is doing.
A test worth applying to your own opportunity list: is this actually a solution in disguise?
‘Users need a bulk export’ is a solution. ‘Users cannot get our data into the tool they actually plan in’ is an opportunity, and it admits several solutions of which export is the most obvious and probably not the best.
And a discipline that runs directly against the prioritisation chapter: one prominent practitioner deliberately excludes effort from opportunity assessment. The reasoning is that any opportunity can have both easy and difficult solutions, and teams routinely dismiss an opportunity as too hard and then find a simple solution once they actually look at it.
So the sequence is: choose the opportunity on customer importance and how badly served it currently is, and only then let effort discriminate between solutions.
The killer move in an interview: name the assumption which, if false, kills the idea — and the cheapest test that would falsify it. That converts a design answer into a discovery answer and almost nobody does it.
One correction worth having ready, because the statistic is everywhere: the widely-repeated claim that 95% of new products fail, usually attributed to a well-known business academic, is not supportable. The business-school article it comes from now carries an editorial note saying it was updated to clarify a failure rate figure included in an earlier version, and the surviving text says only that many of the tens of thousands of new consumer products launched each year fail. The institution corrected it; the internet did not.
Check yourself