Product discovery in B2B, where you can't just run an experiment

Almost all published discovery practice assumes two things: enough traffic to reach statistical significance in a week, and the ability to talk to users whenever you like. B2B products routinely have neither. You have twelve accounts that matter, a sales team that guards them, and a buyer who isn’t the user.

The advice doesn’t transfer, and the usual response — running the consumer playbook anyway and concluding discovery doesn’t work here — is how B2B teams end up building whatever the loudest customer asked for.

Here’s what actually works.

The three-audience problem

In consumer, the person who chooses, pays and uses is the same person. In B2B they’re three:

• The buyer signs. Cares about risk, compliance, and the business case.
• The champion pushes internally. Cares about looking right for having recommended you.
• The user uses it daily. Cares about whether it’s tedious.

Discovery that talks only to buyers produces a roadmap of procurement features. Discovery that talks only to users produces things that delight and don’t renew. You need both, and you need to know which one you’re hearing from at any moment — which is the single most common defect in B2B research: notes that don’t record which hat the person was wearing.

Getting access

The honest blocker is usually not the customer’s willingness, it’s your own account management. Three things that work:

Ride along on existing calls rather than requesting new ones. QBRs, support escalations, onboarding sessions. You’ll get less structured material and far more of it, and nobody has to grant you anything.

Ask sales for the loss reasons, not the wins. Win interviews tell you what you already believe. The accounts that churned or never closed are where the information density is, and they’re the ones nobody schedules.

Make it worth the account manager’s while. They’re protecting a relationship they’re measured on. “I want to talk to your customer” costs them something and returns them nothing. “I’ll join and answer their three open product questions” changes the trade.

Instruments that work at low volume

Support tickets as a standing dataset. Underused and free. Read three months of them properly, tagged by circumstance rather than by feature area, and you’ll have a better problem list than most research rounds produce.

The five-account deep read. Instead of a thin signal across everyone, go deep on five accounts that represent a segment you care about. Usage data, ticket history, and one conversation each. Small-n done properly beats large-n done shallowly when you’re trying to understand a why.

Sales-call transcripts. If your team records calls, you have a large corpus of customers describing their problems in their own words, generated for free, that product almost never reads.

The design partner arrangement. Three or four accounts who get early access and real influence in exchange for real engagement. Formalise it — a named contact, a monthly session — or it decays into a mailing list.

Experiments, adapted

You can still run fake door tests in B2B, with two adjustments:

Segment before you conclude. A 4% click-through rate spread evenly across your base and 4% concentrated in three enterprise accounts are opposite findings. In B2B the second is common and the average hides it entirely.

Watch the trust cost more carefully. A consumer user seeing a “not built yet” panel shrugs. An enterprise champion who showed it to their boss is embarrassed. Keep fake doors out of surfaces your champions demo, or brief them first.

Where the volume genuinely isn’t there, replace the experiment with a prototype and a conversation. Five design partners clicking through a working slice will tell you more than an underpowered test that can’t reach significance anyway.

The customer-request trap

The defining B2B discovery failure: a named account asks for a feature, and it goes into the roadmap because of who asked rather than what it would do.

The fix is a question, asked every time, before any estimating happens:

What are you doing today instead?

Three possible answers, three different responses:

• “A workaround that mostly works.” Low urgency. It’s a preference, not a need — and it’ll be quietly dropped if you deprioritise it.
• “Something manual and expensive.” Real problem. Now size it: how many accounts do this, and what does it cost them?
• “Nothing, we just don’t do that.” The most interesting answer, and the most ambiguous. Either a genuine unmet need or something nobody actually needs.

That single question converts a feature request into a problem statement, which is the thing you can prioritise. Without it, you’re ranking solutions, which is the structural defect underneath most stalled B2B roadmaps.

What good looks like

You don’t need a research function. You need three habits, held weekly:

1. One customer conversation a week, by the people building the product. Not a researcher reporting back.
2. Support tickets read, not summarised. Twenty minutes, weekly.
3. Every request logged with its “instead” answer. This one costs almost nothing and changes prioritisation more than any framework.

Teams that hold those three for a quarter stop needing to be told what discovery is for. Teams that adopt tooling instead of habits generate documents and change nothing — which is the pattern behind most research nobody acts on.

Establishing the habits is harder than knowing them, mostly because the first month produces no visible output and something urgent always arrives. Getting through that month with the habits intact is a fair description of what coaching is useful for here.