How to Run Product Discovery Without Buying Your Own Story

A polished demo is not product discovery. Neither is a customer saying, “That’s interesting,” after you explain a future workflow they will never have to budget for, implement, or defend internally.

If you are figuring out how to run product discovery, start by treating it as a process for killing bad assumptions cheaply. Its purpose is not to gather compliments, validate a roadmap you already wrote, or produce a slide deck that makes an investment committee feel soothed. Its purpose is to determine whether a specific buyer has a painful enough problem, a viable enough path to adoption, and a reason to pay for what you can actually deliver.

For AI, data, and blockchain ventures, the distinction matters. Technical capability can be real while commercial demand is imaginary. A model can perform well in a controlled environment and still fail the moment a security team, a messy data source, or a frontline operator enters the room. Discovery is where that gap becomes visible, ideally before it becomes expensive.

Start with the decision, not the interview script

Most discovery programs fail before the first call because nobody has defined what decision the research is meant to inform. The team starts asking broad questions about pain points, receives broadly encouraging answers, and discovers three months later that it has learned nothing useful about product, pricing, or market entry.

Write down the decision first. It might be: should we build an autonomous workflow or keep a human approval step? Is the initial buyer a head of operations, a data leader, or the business-unit owner who owns the budget? Can this be sold as a point solution, or does it require an enterprise platform sale that a six-person company is not equipped to run?

Then write the assumptions beneath that decision. Be uncomfortably specific. “Enterprise teams need better AI governance” is not an assumption you can test. “Risk leaders at regulated lenders will pay for audit trails that show which sources informed an AI-generated decision” is closer. It identifies a buyer, a context, a job, and a potentially monetizable requirement.

You are looking for assumptions that would materially change the company’s next move if they proved false. If the answer to a research question cannot alter scope, positioning, buyer selection, pricing, or timing, it is probably intellectual decoration.

Recruit people with consequences, not opinions

The wrong participants will make any concept sound promising. Friendly peers, innovation teams without purchasing authority, and people who enjoy talking about technology are all useful for perspective. They are poor evidence of demand.

Recruit people who have lived with the problem recently and who bear some consequence for solving it. That consequence might be missed revenue, operating cost, compliance exposure, customer churn, or a deadline that keeps reappearing in board meetings. The person does not always need to be the economic buyer, but you need to understand how their pain travels through the organization to the person who controls the budget.

For technical infrastructure, do not stop at the executive sponsor. A CTO may want a data platform. The data engineer may tell you whether it survives integration. Security may tell you whether it clears review. Procurement may tell you whether the contract shape is dead on arrival. Discovery that ignores these actors is not discovery. It is early-stage demo hypnosis.

A small number of high-quality conversations can beat a large survey. Five buyers facing the same urgent, measurable problem are more useful than 100 respondents selecting “very interested” from a form. Surveys are excellent at measuring patterns after you know what to ask. They are terrible at discovering whether you are asking the wrong question.

Ask for the past, not predictions

Do not ask, “Would you use this?” People are generous with hypothetical enthusiasm because it costs them nothing.

Ask what they did the last time the problem occurred. Who noticed it? What process followed? What systems were involved? How long did it take? What did it cost? Who approved the workaround? What prevented a better solution from being adopted?

Past behavior exposes constraints that abstract conversations conceal. If a prospect says they need automated decisioning but every consequential decision currently requires legal review, that is not a minor implementation detail. It may define the product. If they say the team is drowning in manual analysis but cannot expose source data to third parties, your deployment model has become the product question.

Listen for evidence of existing spend. A spreadsheet maintained by three analysts, a consulting engagement, a homegrown pipeline, or a tolerated operational failure all indicate that the problem has weight. None guarantees a market, but each is more valuable than applause.

Test the whole adoption path

A discovery effort that validates user pain but ignores buying and deployment risk will produce a product that users like and companies cannot adopt. This happens constantly in AI.

The real product is not just the interface, model, or protocol. It is the entire path from first interest to reliable use: data access, integration, evaluation, security review, change management, commercial approval, and ongoing accountability when something goes wrong.

Map that path with prospective customers. Ask what must be true before they can run a pilot. Ask what would make a pilot credible internally. Ask what metrics would determine whether it expands or quietly dies after the champion loses interest.

For an AI product, quality metrics need scrutiny. Accuracy is often too blunt. A buyer may care more about citation quality, escalation rates, time saved per case, error severity, or the ability to inspect why a recommendation appeared. For a data platform, the constraint may be lineage and reliability rather than raw query speed. For a blockchain product, legal ownership, liquidity, custody, or settlement workflow may matter more than the chain architecture.

This is where founders often get defensive. A customer raises a constraint, and the team hears an objection to overcome. Sometimes it is. More often, it is evidence that the proposed product is only one component of a larger, harder buying problem.

Use artifacts that force a reaction

Conversation alone has limits. People can agree with a verbal concept while imagining entirely different products. Give them something concrete enough to challenge.

That artifact can be a workflow map, a mock output, a pricing page, a proposed implementation plan, or a manually delivered version of the promised outcome. The point is not visual polish. It is to make trade-offs visible.

Show the AI-generated report and ask what they would trust, edit, or refuse to send. Show the required data fields and ask which are unavailable. Show a proposed $40,000 pilot and ask who signs it, what budget it comes from, and what result justifies renewal. If the conversation becomes awkward, good. You are finally getting near the truth.

A concierge or manual pilot is especially useful when the underlying technology is not ready or when the workflow is uncertain. It lets you test whether buyers value the outcome before you spend months automating it. The trade-off is obvious: manual delivery does not prove software scalability. But it can prove whether the problem is worth automating at all, which is the earlier and more valuable question.

Define evidence thresholds before you see the results

Teams routinely move the goalposts after discovery because they are emotionally attached to the answer. Prevent that by setting thresholds in advance.

For example, you might require repeated evidence that a defined buyer has experienced the problem in the past quarter, can name an existing workaround, agrees to share data or access needed for a pilot, and can identify a budget owner. You might decide not to build a feature unless several target accounts independently describe the same workflow and failure cost.

The exact threshold depends on the market. A narrow, high-value enterprise problem may justify deeper work with fewer accounts. A self-serve product needs broader behavioral evidence. A venture pursuing a regulated market may need to validate implementation feasibility before it can credibly test pricing.

What matters is discipline. Discovery is not a vote where the most enthusiastic comment wins. It is a body of evidence weighed against the cost of being wrong.

Turn findings into a harder strategy

The output of product discovery should be decisions, not a repository full of interview notes nobody reads again. At the end of each cycle, state plainly what changed.

You may narrow the initial segment because only one buyer profile has an urgent use case. You may remove a feature that impressed prospects but did not affect purchase intent. You may discover that your claimed wedge is not sufficiently distinct, or that the market needs services before it will buy software. Those are not failures of discovery. They are its return on investment.

Document the evidence, the unresolved risks, and the next test. Then make a choice. A company that learns it lacks a credible route to adoption has two options: change the product or continue funding the story. Only one of those is strategy.

The useful closing question is not whether customers liked what you showed them. Ask whether they gave you evidence that they will change behavior, allocate resources, and tolerate the friction required to get value. If they did not, do not decorate the finding. Let it redirect the company while you still can.

Where is your leadership effective, and where is it costing the company?

Most of the problems this blog covers trace back to how the founder runs the company. The Trellis Leadership Diagnostic maps that in 24 behavior-anchored items across six dimensions: about 12 minutes, instant results, free to take self-serve.

Take the Leadership Diagnostic →

Exploring a fractional or advisory engagement instead? Book a discovery call →