Discovery is the process product teams run to find out what's actually different or required when a Business Strategy target points them at new territory — a new market (e.g., China or Africa vs. domestic) or a new OKR/KPI — before committing to it in a Product Strategy.
The output of discovery isn't a solution yet; it's the evidence of how difficult the required product changes will be — exactly the kind of data a good strategy is supposed to be transparent about.
Apply: Before locking in a strategy around a business-strategy-driven target, run discovery to learn how hard the needed product changes actually are, rather than assuming the target is achievable as stated.
Discovery splits into two distinct skills. Problem discovery is identifying which problems are worth solving in the first place; solution discovery is figuring out how to solve a given problem once it's been chosen. Empowered teams are expected to do both, but the trust to do problem discovery independently is usually earned later — see Earning the Right to Define Problems. New or unproven teams should focus on solution discovery first, delivering well against problems already identified by the product leader, and only take on independent problem discovery once that track record exists.
Datasite's Doug and Thomas draw a sharp line between "visiting customers" and doing discovery: visiting customers and then building whatever was already on the roadmap is not discovery, even if it looks similar from the outside. Real discovery means the customer engagement is what determines prioritization, sprint planning, and the phasing of what gets released — insights have to be traceable into what actually gets built.
They also close a loop that is often left open: after building something driven by a discovery conversation, they go back to the customer and tell them what was built because of their input. That feedback loop is itself a trust-building act, reinforcing Culture Bank (Trust Reserve for Crises) and complementing Feature Flagging / Cohort Release, which lets the resulting hypothesis be tested against a real cohort before a full rollout.
Apply: audit whether "customer visits" actually change prioritization and release plans — if not, it's relationship maintenance, not discovery — and always close the loop back to the customer about what their input produced.
A pilot team at Palace Hotels (see Single Pilot Team as Transformation Proof of Concept) initially assumed, based on an old survey where 40% of guests said they'd like to book via a mobile app, that the fix for a weak booking experience was a native app. Direct customer research overturned that assumption; the team chose not to build the app and instead improved an existing, unmaintained booking web page, ultimately tripling its conversion rate. Anoir: 'the funny thing is that we didn't build anything because thanks to this research we ended up realizing that this multi-million dollar effort was going to waste.' A clean example of discovery preventing a costly build based on a stale signal; compare Data as Political Trust-Builder (Myth-Busting) for the same episode viewed as a political/trust event rather than a discovery event.
Anoir frames product discovery as detective work: "Customers are not going to tell you what to build. Your teams are not going to tell you what to build because they don't know. This is your job and this is what's fun about doing product." Neither customer interviews nor internal stakeholder requests are transcribable requirements — they're clues. The product team's job is to synthesize evidence from both sources into a solution nobody handed them directly, which is what separates discovery from an intake process.
Discovery isn't limited to deciding what feature to build — at Palace Hotels it was used to reframe two other kinds of decisions:
Both cases apply the same discipline: validate the assumed solution against real user/field evidence before committing budget, whether that budget is construction dollars or an app build.
Two Palace Hotels examples reframe discovery's payoff as avoiding costly commitments rather than only finding new opportunities:
Discovery isn't a phase that precedes building — it's the ongoing day job of product and design work, continuous rather than front-loaded. Treating it as a gate before "real work" begins is itself a symptom of the roadmap/software-factory mindset. See Design as a Discovery Discipline (Not Downstream Delivery) and Software Factory Delivery Model.
Discovery means giving a team a problem and success measure, generating many candidate solutions, and testing them — often via Rapid Multi-Fidelity Prototyping — until one clears all four risks in Valuable / Usable / Feasible / Viable. The prescription: replace feature roadmaps with discovery cycles that validate ideas quickly and cheaply before committing engineering time to build.
Cagan frames discovery as the practice that differentiates empowered teams from feature teams: nothing goes to engineering delivery until the proposed solution has been validated with customers and data (e.g. prototype testing), because building the wrong thing at full engineering cost is the expensive failure mode discovery exists to prevent.
Из тем: The Product Operating Model