Product Discovery and Validation for Companies That Have to Ship Anyway

Why "stop and discover" advice fails mid-market companies

The dominant discovery literature is written by and for people who work in product organisations that can afford to slow down. Venture-funded startups before product-market fit. Platform teams inside large tech companies with budget air-cover. R&D groups carved out from the operating P&L. In those settings, six weeks of dedicated discovery is a credible ask.

A mid-market company with £30M of recurring revenue across two product lines, fifteen engineers, and a renewal cycle that starts in November does not have that flexibility. The roadmap was negotiated with sales. The board has been told what is coming. The customer success team has commitments in writing. Stopping to "go and discover" reads, internally, as either negligence or an abdication of commercial reality.

So the advice gets ignored, or it gets performed. Performed discovery is worse than no discovery, because it consumes time and budget while producing artefacts that do not change what gets built. A research repository full of customer quotes that nobody opens. An opportunity solution tree that lives on a Miro board until the licence expires. A round of usability tests run on a feature that was already scoped, estimated, and committed.

The honest answer is not to do less discovery. It is to do discovery and validation that runs alongside delivery, at a depth chosen deliberately, with explicit trade-offs about which risks you can afford to leave unvalidated. That is harder to write a framework about, which is probably why so few people do, and it is the gap that mature product discovery services are built to fill for clients who cannot suspend commercial operations to learn.

What product discovery and validation actually means when you can't stop shipping

The two halves of the phrase do different work, and conflating them is part of why teams produce theatre.

Discovery is the work of figuring out what is worth building. Which problem is worth solving for which customer. Which opportunity sits at a sensible intersection of customer pain, business strategy, and what your team can credibly deliver. Discovery outputs are bets, framed as outcomes, with the reasoning behind them visible.

Validation is the work of reducing the risk that the bet will fail. It happens before code, sometimes during code, and occasionally only after a thin version reaches production. Validation does not certify that an idea will work. It reduces, on evidence, the probability that you are about to spend six months on something that will not.

They overlap. A round of customer interviews can be discovery (we are learning what matters) and validation (we are testing whether the thing we already think matters actually does). The same artefact can serve both, which is part of why teams get confused about what they are doing.

The four risks worth validating before you commit code

The framing most widely used, from Marty Cagan, splits risk into four kinds. Value risk: will customers buy or use it. Usability risk: can they figure out how. Feasibility risk: can we actually build it within constraints we can live with. Viability risk: does it work for the business, including legal, compliance, support, and commercial model.

For most mid-market bets, value and viability dominate. Feasibility is usually known, because the engineering team has seen the territory. Usability becomes a serious risk only when the workflow is genuinely new or the user is unusual. Putting equal effort into all four is a way to spend evenly rather than wisely.

Why "validated" is a dangerous word

Anyone who tells you a feature is "validated" after twelve interviews is selling you confidence you have not earned. Validation reduces risk; it does not eliminate it. The most disciplined teams talk about evidence, not validation. A bet has more evidence behind it than it did last week, or it does not. That framing is harder to oversell, which is why it is more honest.

Dual-track discovery in practice, not in theory

Dual-track discovery is presented as elegant. One track does discovery work. One track does delivery work. They feed each other continuously. In the canonical diagram, both tracks hum along at steady capacity, with insights flowing left to right and constraints flowing right to left.

In real mid-market organisations, the discovery track gets starved the moment delivery pressure spikes, which is most of the time. The PM gets pulled into release coordination. The designer gets pulled into production design polish. The research function, if there is one, gets asked to produce a deck for an exec who wants to "see what we've learned." Discovery becomes the variable cost; delivery is fixed.

What actually works is more modest than the diagram suggests. A small protected discovery capacity. Usually one PM at maybe 40% of their time, one designer at 30% to 50%, and intermittent engineering input from a tech lead who is allowed to spend a day a week thinking ahead. This capacity runs 6 to 10 weeks ahead of the delivery roadmap. Handoff into delivery happens through explicit rituals: a written brief, a kill criterion, a definition of what the first slice in production should teach.

Concrete example. A 90-person B2B SaaS company in the field operations space, three product lines, around £18M ARR. The team introduced a two-week discovery sprint ahead of each quarterly planning cycle. During those two weeks, the top three candidate bets for the next quarter were stress-tested through customer interviews, assumption mapping, and where appropriate a clickable prototype shown to ten or twelve customers across two segments. The output was a fund / reshape / kill decision for each bet, with the reasoning written down.

In the first four cycles, roughly a third of the proposed work was killed before it entered the backlog. That is the kind of throughput that justifies the headcount cost of the protected capacity. It is also the kind of result that requires the discipline to actually kill things, which is the part most teams quietly avoid.

A working method for validating bets while you ship

There is no single right sequence, but the following holds up across most mid-market situations. It is deliberately stripped down.

1. Frame the bet as an outcome, not a feature. "Reduce time to first invoice for new customers from 14 days to 5" is a bet. "Build an onboarding wizard" is a solution. The wizard might be the answer; it might not be.
2. Surface the assumptions that have to be true for the bet to deliver the outcome. Assumption mapping works for this. You list assumptions across customer behaviour, problem severity, willingness to adopt, technical feasibility, and commercial model. You will usually surface 20 to 40 of these in an hour.
3. Rank the assumptions by risk and evidence. The combinations that matter are high-risk, low-evidence. Those are the things that, if false, kill the bet.
4. Pick the cheapest test that meaningfully reduces the top one or two risks. Customer interviews for problem severity. Clickable prototypes for workflow fit. Fake doors or painted doors for demand. A concierge version where the team manually does what the product would automate. A pricing test if viability is the dominant risk.
5. Set a kill criterion before you run the test. Write down, in advance, what evidence would cause you to walk away. This is the step that separates real validation from confirmation theatre. If you cannot define what would change your mind, you are not testing the bet; you are collecting reassurance.
6. Run the test. Decide. Fund, reshape, or kill.

The fifth step is the one that gets skipped, and it is the one that matters. A test without a pre-committed kill criterion will, almost without exception, be interpreted in favour of continuing. Humans are bad at killing their own ideas. Pre-commitment is the trick that makes evidence-based decision making survive contact with the team's emotional investment in being right.

Red flags that you are doing validation theatre

The patterns repeat across companies, sectors, and continents. If you see these, your discovery and validation work is producing comfort, not evidence.

Interviews that confirm. The questions are leading, the moderator is enthusiastic, the report aggregates positive quotes. Anyone who has read the raw transcripts can tell within five minutes whether the conversation was real.

Surveys designed to produce the answer the sponsor wants. The wording betrays the intent. A senior stakeholder asked to be reassured, and the research function obliged.

Prototype tests where the moderator leads. The user is gently steered through the happy path. Confusion is glossed. The recording, watched at 1.5x with the sound off, shows the moderator's hands more than the user's.

"We talked to 30 customers." With no record of what was asked, what was disconfirming, or what changed as a result. Volume of interviews is not evidence; calibrated learning is. Five interviews with a clear hypothesis and a kill criterion produce more useful information than thirty without one.

Research decks that get presented, applauded, and shelved. The deck is good. The room nods. Nothing in the roadmap changes. A month later, the deck has been forgotten. This is the most expensive pattern, because it consumes senior time and produces nothing that touches engineering.

The Miro board that does not lead to a decision. Opportunity solution trees and assumption maps are tools, not deliverables. If the workshop ends without a fund / reshape / kill decision attached to specific bets, the workshop did not finish.

Discovery dressed as a deliverable. There is a category of work that gets sold as product discovery services and is really just structured opinion delivery. A team comes in, runs some workshops, produces a polished output, and leaves. Whether any of it changes what gets built is not the seller's problem. The buyer's first defence against this is to ask, before engagement, what decisions the work will inform and what evidence will be collected to inform them. If those questions are answered with frameworks rather than specifics, walk away.

When the answer is to ship a small thing and learn from production

Sometimes the most expensive form of validation is more validation. If a credible thin version of the feature can be built for roughly the same cost as a convincing simulation, the thin version is usually the better instrument. It gets you real behaviour, real money, real edge cases. Lab validation generalises poorly when the user has skin in the game.

Fintech is the cleanest example. Simulated user testing of fee structures, payment timing, or transaction confirmation flows is unreliable, because real money behaviour diverges sharply from hypothetical money behaviour. People say they will accept a 0.4% fee in an interview and decline it at the point of payment. The honest move, when the regulatory frame allows it, is a tightly scoped beta with five to ten named customers, full instrumentation, and a written plan for what you are watching for.

Conditions that make this approach right: the change is reversible, the blast radius is small, you can instrument the relevant behaviour, the customers involved have agreed to act as beta users, and you have a kill plan if the data goes against you.

Conditions that make it wrong: regulated workflows where partial failure has compliance consequences, anything that touches critical customer data without a clean rollback, anything where pulling the feature back damages trust more than not shipping it would have. Healthtech and some parts of financial services sit in this second category more often than people admit.

The point is that "validate first, then build" is a heuristic, not a rule. The real question is always which form of evidence is cheapest per unit of risk reduced. Sometimes that is an interview. Sometimes it is a prototype. Sometimes it is a small beta with real customers.

How discovery, validation, and delivery feed each other

The most consistent failure mode in mid-market product work is not bad discovery or bad delivery. It is the absence of a working loop between them.

Discovery without delivery feedback gets stale. The team's mental model of how customers actually use the product drifts from reality, because nobody is watching the production signal closely enough to update it. Six months later, the discovery work is built on assumptions that were true a year ago.

Delivery without discovery input ships waste. The backlog grows. Features go out. Usage data is either not collected or not looked at. Engineering hours convert into shelfware at scale.

Validation that does not loop back into discovery becomes a one-time exercise. The team validates a bet, ships it, and then never returns to update the assumption map with what production actually taught them. The next bet is then framed against an unchanged model of the world.

The loop, when it works, looks like this. Discovery produces a bet. Validation reduces the risk on the bet to a defensible level. A first slice ships, with instrumentation defined before code. Production signal feeds back into the assumption map and the opportunity solution tree. The next bet is framed against an updated view. This is the version of continuous discovery that earns its name, because it is actually wired into delivery rather than running alongside it.

The five phases that sit underneath this loop, including how to scope a discovery engagement against them, are covered in more depth in The Five Product Discovery Phases Most Mid-Market Teams Get Wrong. The loop sits on top of the phases; the phases produce the artefacts the loop relies on.

Budgets, timelines, and what a serious engagement looks like

Ranges, with the reasoning behind them.

A focused discovery and validation engagement for a single product bet typically runs 4 to 8 weeks. That window is long enough to do real customer research, build and test a prototype where appropriate, and produce a defensible fund / reshape / kill decision. Shorter than 4 weeks tends to compress the research into something that confirms whatever the sponsor walked in believing. Longer than 8 weeks, for a single bet, usually means the bet was poorly framed at the start.

A broader engagement covering portfolio prioritisation across multiple product lines runs 8 to 12 weeks. There is more stakeholder work, more segments to research, more assumptions to map, and more bets to triage. The output is usually a prioritised set of opportunities with the top two or three carried into deeper validation.

Budget ranges for mid-market work, in our experience, sit between £40k and £150k depending on scope, depth, and how much of the work is done with the client team rather than for them. What drives the range up: regulated industries with compliance overhead, multiple stakeholder groups with conflicting views, international customer research, segments that are hard to reach. What keeps it down: a single product, a single segment, customers who are accessible because the company already has relationships with them, and an existing research repository the engagement can build on.

The work you are paying for, in a serious engagement, includes evidence-driven prioritisation across competing bets, assumption mapping workshops that produce a written record of what has to be true, prototype-led validation on the highest-risk assumptions, and an explicit handoff into delivery with kill criteria attached. The kind of work we cover in our product discovery service is built around this shape, because the alternative, a research output that does not connect to a delivery decision, is the failure mode most engagements quietly produce.

How this validation work integrates with the broader discovery process, and how to recognise when an engagement is producing real evidence rather than packaged opinion, is covered in How a Product Discovery Process Kills Bad Ideas Before You Fund Them.

Conclusion

Mid-market companies that have to ship can still do honest product discovery and validation. The trade-offs are real, and the work looks different from the version in the canonical literature, but the underlying logic holds. Protected discovery capacity, even small. Kill criteria set in advance, not after the fact. Validation depth chosen by the cost of being wrong, not by the framework being followed. A working loop between discovery, validation, delivery, and production signal, with each one updating the others.

The companies that do this well are not the ones with the best frameworks. They are the ones willing to kill their own ideas on the evidence they collected. That is a cultural fact more than a methodological one, and it is the part that no engagement can install for you. What good product discovery services can do is build the artefacts, the rituals, and the evidence base that make killing ideas defensible inside your organisation. Whether you then actually do it is the question that decides whether the work was worth commissioning. If you are weighing that decision now, the next step is a conversation about which specific bets on your roadmap are unvalidated, and which of those you would most regret being wrong about.

Frequently Asked Questions

What is contextual inquiry and workflow analysis?

Contextual inquiry and workflow analysis help product teams understand how users complete tasks in their real work environment. Instead of relying only on what users say, teams observe how people actually work, what tools they use, where they struggle, and what conditions shape their behaviour.

These methods are especially useful for complex workflows because they reveal process gaps, workflow inefficiencies, and hidden pain points. Through job shadowing, observation, process analysis, and detailed workflow maps, teams can better understand user goals, work context, and the steps required for successful goal accomplishment.

What are common user research techniques in product discovery?

Common user research techniques include user interviews, surveys, observation, and structured conversations. These methods help teams gather feedback, understand user experiences, and identify user motivations, needs, and pain points. Tools such as Google Forms, SurveyMonkey, and Typeform can support user surveys, while interviews and observation help teams explore behaviour in more depth. By combining direct feedback with research in the user's natural environment, teams can test hypotheses and build a clearer understanding of what users actually need.

How should teams select and apply product discovery techniques?

Teams should select discovery and validation techniques based on the project's goals, constraints, available data, and the type of risk they need to reduce. For example, some projects may require discovery experiments to test demand, while others may need sprint reviews, usability testing, or research synthesis to evaluate whether a solution is working.

The right technique should connect directly to a success metric and produce useful discovery findings. Teams also need to consider whether statistical significance is required or whether early qualitative feedback is enough to guide the next decision.

How does prototyping and interface evaluation support product discovery?

Prototyping and interface evaluation help teams explore and refine product ideas before full development begins. By creating paper prototypes, digital wireframes, clickable prototypes, interactive mockups, or video demonstrations, teams can test design alternatives and identify potential usability issues early. These methods allow teams to evaluate user experience, interface behaviour, touchpoints, and overall product flow before investing in production-level development. Prototype tests and user experience testing help teams understand what works, what feels confusing, and what should be improved before the solution moves forward.

What are product validation methods?

Product validation methods are techniques used to test whether a product concept, feature, or interface is likely to work for users. Common methods include usability testing, A/B testing, Wizard of Oz testing, and prototyping. These methods help teams validate ideas through direct user interaction and data-driven experiments. Usability testing can reveal whether users understand and can complete key tasks, while A/B testing helps compare different versions of a feature. Wizard of Oz testing allows teams to simulate product functionality before fully building it. Each reduces a different kind of risk: A/B testing produces quantitative evidence at scale, Wizard of Oz testing simulates functionality before it is built, prototyping puts a tangible artefact in front of users, and usability testing surfaces friction in how people interact with the product.

How can product discovery support process integration and continuous learning?

Product discovery supports continuous learning when discovery and validation activities are integrated into the regular product development process. Instead of treating discovery as a one-time phase, teams can use experiments, refinement, sprint planning, future sprints, and validation activities to keep learning throughout development.

This approach helps teams de-risk product decisions, improve user-to-product interactions, and create a stronger connection between discovery techniques and delivery work. By continuously testing, learning, and adjusting, teams can improve the development process and build more innovative products over time.