How a Product Discovery Process Kills Bad Ideas Before You Fund Them

Why bad ideas survive without a product discovery process

In mid-market companies, bad ideas survive for structural reasons. Smart people make smart arguments for things that should not exist, because the room is organised in a way that makes saying no expensive.

Four mechanisms keep weak ideas alive.

The first is the HiPPO effect. The highest-paid person's opinion carries disproportionate weight, especially when that person is the founder or the operator who built the business. Their pattern recognition is real, but it is also non-falsifiable in a casual setting. Nobody runs the test that would prove the CEO wrong, because nobody is paid to.

The second is sunk equity in the idea itself. By the time it reaches a planning meeting, somebody has already invested social capital in it. They have pitched it internally, brought it up in two board updates, and described it to a customer. Killing it now means walking back. The bar for killing rises as the social cost of killing rises, and that bar tends to be much higher than the bar for funding.

The third is confirmation-biased research. Teams do "discovery" by talking to five friendly customers, asking leading questions, and writing up the answers as validation. The output looks like evidence. It is something else.

The fourth is the assumption that build will reveal the truth. The reasoning runs: we will figure it out once we start shipping. In agile theory, kind of. In practice, by the time shipping reveals the truth, the team is six months in, and the political cost of pivoting is higher than the cost of muddling through.

A typical scenario: a 90-person B2B SaaS company with three product lines puts £350,000 into a workflow automation feature because two large customers asked about it in QBRs. Eighteen months later, adoption sits at 4%. Nobody asked the question that would have killed it in week three, which is whether the customers would actually change their existing workflows to use the new tool. They would not.

What a product discovery process actually does

A discovery process is a decision pipeline, with research as the input and a funding call as the output. The work it does between those two ends is what separates real discovery from theatre.

First, it translates the idea into a set of explicit assumptions. "We should build a workflow automation feature" is not testable. The assumptions underneath it are: customers will change their existing workflow to use ours, the time saved is large enough to justify switching, the integration with the systems they already use is feasible within budget. Assumption mapping makes those claims visible. Once they are visible, they can be ranked by how much you would have to bet on them being true, and which would do the most damage if they turn out to be false.

Second, it sets kill criteria before the research starts. This is the part that mid-market teams routinely skip and that experienced practitioners insist on. If you do not write down, before talking to a single user, what evidence would convince you to walk away, you will not walk away. You will rationalise whatever you find. Pre-agreed criteria turn the conversation from "what does this finding mean" into "did we hit the threshold."

Third, it sequences the work so the riskiest assumptions get tested first. Opportunity solution trees, hypothesis testing against real user data, jobs-to-be-done interviews, and prototype testing are the standard tools. The taxonomy matters less than the order. You test value before usability, usability before feasibility, feasibility before viability, because each one is cheaper to disprove than the one after it. The Five Product Discovery Phases Most Mid-Market Teams Get Wrong walks through how those phases map onto a typical engagement.

Fourth, the process forces a real go, pivot, or kill call at defined gates. No gate, no decision. Without gates, discovery turns into a continuous research function that produces insights and slides forever without ever cutting anything.

Good product discovery services are designed around all four. Weaker ones do the first well, the second sometimes, the third accidentally, and the fourth never.

The four risks every product discovery process must test against

Marty Cagan's four-risk model is one of the few frameworks that survives contact with mid-market reality. It works because it maps directly onto the questions a sceptical CFO would ask. The discovery process exists to generate honest answers to each.

Value risk

Will users want this enough to change their behaviour. This is the risk most often skipped, because asking people whether they like something tends to produce false positives. Users are polite, especially to the company they are buying from. The signal that matters is switching cost. Would the user stop using their current workaround? Would they rearrange a workflow to fit yours? Would they pay more? Enthusiasm in interviews misleads. Value risk is tested through qualitative interviews structured around what users currently do, and through prototype testing where users complete real tasks rather than rate concepts.

A kill signal on value risk usually looks like users acknowledging the problem exists but ranking it well below other problems they already tolerate. That is a no, even when the interviewer wants it to be a yes.

Usability risk

Can the user figure out how to get value from the product. Usability gets attention in design reviews and is therefore the risk most people assume is being managed. In practice, it is often the second-biggest source of post-launch failure. A feature that requires the user to read documentation is a feature that will not be adopted by users who do not have time.

Prototype testing with real target users, observing where they hesitate or click incorrectly, is the cheap way to test this. Failure rates of more than 30% on a primary task are a strong kill signal at this stage.

Feasibility risk

Can your team actually build this within the budget and timeline you have. This is the risk that engineering should own, and the one that gets ignored when discovery is run by a research or design function in isolation. Integration with legacy systems, data quality, third-party dependencies, regulatory constraints, and scaling assumptions all sit here. A discovery without an engineer in the room is not a discovery of feasibility.

A kill signal looks like the technical estimate landing at 2× or more of the funding envelope, or a dependency on a third party that has no commercial reason to cooperate.

Viability risk

Does the unit economics work. Does it fit your business. Does it create more cost in support and operations than it generates in revenue. Viability risk is the one operators are usually best at intuiting, but a discovery process makes the intuition explicit. The MVP definition that emerges has to be one the business can sustain, which is a higher bar than one engineering can build.

A kill on viability looks like a feature that would technically work, would be adopted, but would erode margin on the segment that adopts it.

Decision gates: where bad ideas actually get killed

The most important artefact in a discovery process is not the research output. It is the calendar invite for the gate review.

A gate is a scheduled point at which the team reviews evidence against pre-agreed criteria and makes a go, pivot, or kill call. A standard discovery engagement has three: one after the initial research phase, one after prototype validation, and one immediately before the MVP commit. Each gate has a different question.

The first gate asks whether the problem and the market are real. If the research has not produced evidence of a real user problem that target customers would change behaviour to solve, the discovery stops. Cheap kill. The team has spent four to six weeks and a fraction of the build budget.

The second gate asks whether the proposed solution actually solves the problem in a way users can use. This is where prototype testing earns its keep. If users cannot complete the core flow, or complete it but report no improvement on what they currently do, the design direction is wrong. The kill at this gate is rarely a full kill. More often it is a pivot back to problem definition.

The third gate asks whether the team has a build plan it can defend to the board. Technical estimates have to be grounded, integration risks have to be mapped, and the MVP scope has to be defensible as the minimum that produces validated learning. If the build plan smells optimistic, the gate is the time to send it back, before the second sprint hits the same wall.

A fintech client of ours was three weeks into prototype testing on a new account-opening flow when the gate review revealed that 8 of the 12 target users had failed the identity verification step in roughly the same place. The feature was not dead, but the design direction was. The team killed the original flow at the gate, rebuilt the verification step with a different approach, and ran a second prototype cycle. Without the gate, the same finding would have surfaced at QA or in production, both of which are at least an order of magnitude more expensive to fix.

What killing a bad idea actually looks like

The clean version of "kill the bad idea" rarely happens. The real version is messier. Findings come in piece by piece, the team has equity in the original direction, and the call is usually a judgement on a body of evidence rather than a single clear signal.

A composite example, drawn from several engagements. A healthtech company with a successful patient-facing app wanted to build a scheduling and triage platform for the GP practices that referred to them. The hypothesis was that practices would adopt a tool that reduced the time their staff spent on phone triage. The discovery ran ten weeks. Market research showed the problem was real and widely felt. User research with eleven practice managers confirmed the pain. Initial enthusiasm was high.

The kill signal came from feasibility and viability. The technical assessment showed that integration with the four most-used UK practice management systems would require bespoke work for each, with no API stability guarantees. The viability analysis showed that GP practices were on fixed budgets set centrally, with no line item for the kind of tool being proposed. The path to revenue ran through a procurement cycle that took 18 to 24 months. The product would technically work, users would in principle want it, and the company would still go broke building it.

The recommendation was to kill the idea in its proposed form and pivot to a much narrower problem that could be sold into the existing patient-facing relationship. The client did. A £50,000 to £75,000 discovery engagement, which is broadly the range for a comprehensive eight to twelve-week programme at mid-market scale, replaced what would have been a £600,000 to £1.4 million build that shipped into a market that could not buy it.

That is the trade. The cost of running rigorous product discovery services is a fraction of the cost of finding out the same information through delivery. The harder part is institutional. Killing the original idea meant a director who had championed it internally had to walk it back to the board. Discovery findings make that conversation possible, because the kill is grounded in evidence rather than opinion, but it is still a conversation that requires support from the leadership team. The structure of the discovery, including the pre-agreed kill criteria and the gate review, gives that conversation somewhere to land.

Discovery theatre: when the process looks rigorous but kills nothing

The reader who has bought discovery before knows the failure mode. The engagement runs, the deck is delivered, everybody nods, and the team builds roughly what they were going to build anyway. The findings appear to inform the work without actually constraining it.

Several patterns produce that result.

The first is the research-to-deck pipeline. A research team runs interviews, synthesises findings into themes, presents the deck, and walks away. The engineering team, which was not in the room for any of it, receives the deck two weeks later and builds from a backlog that pre-dates the discovery. The research is real. The connection between research and what gets built is decorative.

The second is the prescribed solution dressed up as discovery. The brief from the client specifies the feature, the technology, and roughly the timeline. The discovery is asked to "validate" this. Done honestly, that scope cannot validate anything; it can only design what was already decided. The output is a research narrative that justifies a foregone conclusion. Vendors that take this work without renegotiating the scope are selling theatre.

The third is framework worship. The discovery uses opportunity solution trees, jobs-to-be-done, and continuous discovery loops, presented with the confidence of a Silicon Valley playbook. The methods are sound. The fit to a 120-person mid-market company with a single product team and a six-month roadmap commitment is questionable. Frameworks built in environments with dedicated research staff, weekly user touches, and the freedom to abandon directions every quarter do not transfer cleanly to companies where the product manager also runs customer success. Cargo-culting the form without the operating conditions produces ceremony where insight is needed.

The fourth is "continuous" discovery that is in practice discontinuous. The team intends to keep running user research alongside delivery. In month one they do. By month three the sprint backlog has consumed everyone, and the continuous discovery is a recurring calendar invite nobody attends. This is a predictable outcome of treating discovery as something you bolt on to a delivery team that is already at capacity.

The honest position is that the industry produces a lot of discovery theatre, that the buyer is right to be sceptical, and that the rigour of the methods matters less than whether the process is structured to produce decisions. A research output that does not change what gets shipped is shelfware regardless of how well it is researched.

A product discovery process only kills ideas if it connects to delivery

The shelfware problem has one root cause. The discovery team and the delivery team operate as separate functions, sequenced rather than overlapping. The discovery hands off, the delivery picks up, and the link between what was learned and what is being built is mediated by a document.

The fix is structural. Dual-track discovery, where research and delivery happen in parallel rather than in sequence, is the most common formulation. Engineers are involved in feasibility assessment from the beginning, well before the design is locked. User research continues during delivery, so that what is learned in the first two sprints can adjust the scope of the next four. Continuous user research loops are easier to sustain when they are funded as part of the build, rather than as an afterthought.

The other fix is governance. A discovery output that arrives in delivery with no enforcement mechanism is a suggestion. The decisions made at the discovery gates have to carry forward, which usually means somebody from the discovery team stays close to the build, reviewing scope changes, flagging where new assumptions are being made without testing, and making sure the MVP that ships is recognisably the one that was scoped. This is the kind of work we cover in our product discovery service, and it is also where most engagements that look successful on paper quietly fail on delivery.

Even with good structural fixes, delivery realities push back. Deadlines arrive. Stakeholders change. A feature that polled well in research turns out to be more expensive to build than estimated. The team has to decide whether to descope, redesign, or push back the launch. Those decisions are easier when the discovery findings are still live, and harder when the deck has been archived. Product Discovery and Validation for Companies That Have to Ship Anyway covers what happens when discovery and delivery have to run in the same room because the launch date is fixed.

Product discovery services that do not include a delivery integration plan are selling half the work. The kills they identify in research will not stick in production unless something is in place to defend them.

How to commission a process you can trust

Most discovery engagements are sold and bought on credentials. The vendor lists the methods, shows the case studies, and quotes a budget. Credentials matter, but they do not tell you whether the process this vendor will run for you is structured to produce decisions or theatre.

The questions that do tell you that:

• What evidence would you accept as proof to kill this idea, and will you agree to those criteria before research begins
• Who on your team is an engineer, and will they be in the room for the technical feasibility work or attached at the end
• Show me a discovery you ran that resulted in a kill or major pivot, and walk me through how the client received the finding
• How does your discovery output integrate with our delivery team, and what happens if our delivery starts before discovery completes
• What is the gate structure, who attends, and who makes the call
• What is excluded from this scope, and what would trigger a scope renegotiation

A vendor who can answer those without hedging has run real discoveries. A vendor who reframes them as the wrong questions is selling something different.

Two other markers are worth watching. The first is whether the vendor pushes back during scoping. A discovery that arrives with a clean, smooth statement of work saying exactly what the buyer asked for is often one that will deliver exactly what the buyer asked for, which is usually not what the buyer needs. The second is the level of seniority in the actual delivery. Discovery is sold by partners and delivered by analysts in many agencies. If the engineer who scopes feasibility risk is two years out of university, the feasibility findings will be wrong in ways the buyer cannot see until the build hits them.

The right vendor for a given engagement is the one whose stated process matches their actual operating model, and whose actual operating model is set up to kill bad ideas rather than to confirm them.

Conclusion

The honest product you buy when you commission a product discovery process is the institutional permission to say no. The research outputs and the prototype work are in service of building the structure that lets a leadership team kill a weak idea without it being a political event. That structure is what saves the budget.

The cost gradient is unforgiving. Killing at the post-research gate costs roughly the discovery budget. Killing at prototype review costs that plus a few weeks of design. Killing at MVP commit costs significantly more. Killing post-launch costs the full build, the opportunity cost of what the team was not doing, and a credibility hit with the board. Early kills are the cheap ones, and they are the ones that almost never happen without a process designed to produce them.

If you are weighing a discovery engagement, the most useful first step is to write down, before talking to a vendor, the three assumptions you would have to be wrong about for this idea to fail. A credible conversation will start there.

Frequently Asked Questions

What does understanding user needs and problems mean in product discovery?

Understanding user needs and problems is the foundation of product discovery. It is the work of identifying who your users are, what problems they face, and how they currently behave when trying to solve those problems. Without that foundation, every later decision rests on assumption rather than evidence.

The practical work covers value risk, usability risk, feasibility risk, and business viability risk, often framed through the jobs to be done (JTBD) framework. Teams run user interviews to surface customer pain points, build customer personas grounded in demographic and psychographic profiles, and produce a user journey map that shows where the problem actually bites. The output is a clear problem statement and disciplined problem framing the team can defend, rather than a list of features somebody assumed users wanted.

What tools and templates support the product discovery process?

Tools and templates exist to make discovery repeatable rather than improvised. The right ones speed up collaboration, structure thinking, and keep findings in one place where the delivery team can actually find them.

Common categories include Jira templates and product OKR templates for tracking and alignment, opportunity solution tree templates for mapping problem-to-solution relationships, feature usability templates for structured testing, and user need templates for capturing what was learned in research. Collaboration tools with customisable boards support remote and hybrid teams, prototyping tools let teams test ideas before committing to code, and product discovery frameworks rooted in design thinking principles provide the structure underneath. Integration capabilities matter as well, since automation between research, backlog, and delivery tools is what keeps discovery from drifting into a parallel universe the delivery team never sees.

What are the stages of the product discovery process?

The product discovery process moves through a sequence of stages, from initial research to validation. Each stage answers a different question and produces a different artefact, which is what makes the process auditable rather than improvised.

Typical stages start with market research and user research to understand the landscape and the people in it. Problem definition turns what was learned into a clear statement of what the product should solve. Teams then ideate solutions, often through a design sprint or product braintrust review, before producing low-fidelity wireframes and prototypes. Concept validation interviews and customer feedback test whether the proposed direction holds up. Usability patterns and prototype testing surface design issues early. The final stage is to prioritise development initiatives, so what enters the backlog is what actually survived scrutiny.

Which product discovery frameworks and methodologies are most commonly used?

A handful of frameworks and methodologies dominate the practice of product discovery. They overlap, and most working teams borrow from several rather than picking one and applying it rigidly.

The DFV framework (desirability, feasibility, viability) sits at the centre of most modern discovery work. Double Diamond structures the move from problem exploration to solution definition. Lean startup methodology and the build-measure-learn cycle apply to MVP thinking. Dual-track agile keeps discovery running in parallel with delivery rather than ahead of it. Continuous discovery, drawing on the customer development process, treats research as an ongoing habit rather than a one-off event. The jobs to be done framework focuses attention on what users are trying to achieve. Opportunity solution trees connect outcomes to opportunities to solutions, and prioritisation methods such as RICE and value/effort scoring help teams choose between them. Validated customer feedback is the common thread holding all of these together.

Who owns product discovery and what team roles are involved?

Ownership of product discovery is rarely a single role. It is a cross-functional effort that needs leadership, product, design, and engineering at the table together.

Key stakeholders typically include the product manager who coordinates the work, product and UX designers who lead solution exploration, engineers who assess feasibility, and business or commercial leaders who hold the viability lens. Leadership sets direction and authorises resource allocation. Customer-facing teams contribute customer viewpoints from sales, success, and support. Within the engagement, task owners and input providers are defined explicitly, so the product decision-making process has clear accountability. Strong team participation, paired with company-wide alignment, is what turns research into shipped product and product-market fit, rather than research that ends in a slide deck.

What methods and techniques are used during product discovery?

Several methods and techniques sit at the core of product discovery. Most teams use a combination, weighted by where the highest risk lies in their idea.

Customer interviews and user interviews are the workhorse method, since structured conversation surfaces the problem space in detail. Focus groups appear in some contexts but tend to skew toward groupthink. Journey mapping captures how users move through tasks today. Concept testing puts early ideas in front of users for reaction. Rapid prototyping and prototype testing, including remote usability testing and broader usability testing, validate whether a proposed solution actually works in practice. Product analytics inform a quantitative view of behaviour. Customer feedback gathered across these channels feeds back into the product discovery frameworks the team uses to make decisions.

Why is product discovery important?

Product discovery is important because it dictates whether the product you build is one anyone actually wants. The cost of skipping it shows up later, when development costs are sunk and the launch lands flat.

A working discovery process protects against three failure modes. It reduces development costs by killing weak ideas before code is written. It improves prioritisation decisions, so the roadmap reflects what matters from the user perspective rather than what is loudest in the room. And it creates stakeholder buy-in, because decisions are grounded in evidence. Beyond that, product discovery techniques sharpen differentiation, refine the value proposition, and accelerate the path to product-market fit.

What are the benefits of product discovery?

Effective product discovery helps teams make better product decisions by connecting business objectives with real user needs. Instead of building features based on assumptions, teams can use validated data, customer insights, and market context to understand what should be prioritised and why.

The main benefits include stronger product-market fit, more efficient resource optimisation, lower delivery risk, and clearer stakeholder alignment. Product discovery also supports innovation by helping teams identify opportunities, evaluate the competitive landscape, and build a roadmap around features that create measurable value.