One question kills half the initiatives I see: what number moves if this works?
Ask it at a discovery readout and watch the room. When the answer is a number — onboarding time, activation rate, tickets per week — you’re looking at a team that did discovery. When the answer is a feature — “well… we’re building the export flow” — you’re looking at a team that spent six weeks decorating a decision they’d already made. The interviews confirmed the roadmap. The research validated the backlog. Nothing was discovered; a solution got dressed up as a research phase.
Protocol #1 put a gate on intake: no work enters the system without a problem stated as a problem, a named beneficiary, and a metric that’s an outcome. Gate 20 — Discovery Complete — is where that outcome earns its map. Of the twelve gates, this one stands on the loudest doctrine, because the product canon has been shouting it for a decade. Cagan’s version: ask what problem the product solves and you usually get “a rambling list of features.” Torres’s version is the fix, and it’s the frame I run this gate on: the opportunity solution tree. It’s worth walking its spine slowly, because the shape is the check.
What does the tree actually look like?
At the root: one desired outcome. One. Measurable, agreed, written down. Not the five priorities from the quarterly deck — one number this initiative exists to move. If you can’t name it, nothing below matters, because every branch hangs off the root.
Below the root: the opportunity space. The unmet needs, pains, and desires that could move that outcome — mapped from real customer signal, before anyone is allowed to propose a solution. This is where most discovery quietly inverts. Teams start with the solution — it came from a stakeholder, a competitor, a hackathon demo — and run “discovery” to justify it. The tree forces the opposite order: opportunities first, solutions attached to the opportunity they serve. A solution with no opportunity above it is an orphan — and an orphan solution is the tell of a decided-then-decorated initiative.
Then: solutions, plural, competing to serve an opportunity. And under those, assumption tests — the cheap, fast experiments that kill the weak candidates before they reach a sprint. Root, opportunities, solutions, tests. Zoom out to the one outcome; zoom in on the branch that actually moves it.
What does Gate 20 actually check?
That’s the map. Gate 20 checks three things about it, and the first catches almost everybody:
- An outcome at the root, not an output. Torres’s own tell is brutal: “deliver an Android app” — did you do it, yes or no? That’s an output. Binary, did-we-ship-it, dead on arrival as a root. An outcome is a number that moves: Cagan’s worked example is onboarding falling from thirty days to under three hours. When I find a binary metric at the root of an initiative, discovery isn’t complete — it never started.
- The trace from product outcome to business outcome. The number at the root should be a behavior in the product — a leading indicator. Revenue, retention, market share are lagging; they arrive months later and a dozen teams share the credit. The gate wants both named and the thread between them stated: support contacts per order drop by a quarter → support cost per order falls. A leading number for the team to steer by, a lagging number for the business case. If nobody can draw that thread in one sentence, the initiative is running on faith.
- Value and business-viability risk, burned down here — the first two of Cagan’s four big risks. Will customers actually choose this? Does it work for our business — legal, financial, brand? The other two risks, usability and feasibility, get their own gates next; Gate 20 refuses to pass work whose value is still a guess. And the unglamorous fields still count: scope with an explicit out-of-scope list, a draft initiative with a value statement, risks and dependencies written down even as TBDs.
Isn’t discovery product’s lane?
Here’s the conviction, same spine as Protocol #1: my team executes better when they can see the whole picture. But there’s a harder-nosed reason too. Discovery debt gets paid by engineering. Every carryover from a story that pivoted mid-sprint, every “actually, the requirement changed” — that’s skipped discovery arriving late, with interest, in my team’s velocity. The people who pay for the missing map get a say in whether the map exists. That’s standing.
How do you run the gate in minutes, not weeks?
The augmentation, concretely: I don’t audit discovery by gut. I point AI at whatever exists — the initiative, the research notes, the deck — and have it re-draw the tree from the evidence: What outcome sits at the root, and is it a number or a feature in disguise? Which solutions have no opportunity above them? Where’s the leading-to-lagging trace? It comes back with the holes phrased as questions I can hand straight to the PM: “No customer signal behind opportunity two — what did we hear that says this pain is real?” Minutes of AI reading, and the gate conversation starts from evidence instead of vibes. Then the standing rule from Protocol #1: AI maps the holes in the tree. The human decides which branch lives.
Two honesty notes, so the model doesn’t oversell. The numbered gates are my mapping, not Torres’s or Cagan’s — they don’t run phase-gates; I built the gate system because a model you can’t run is a poster. And the amplifier law still binds: point AI at solution-first discovery and it will happily generate prettier justifications for the wrong thing, faster. The tree has to be honest before the machine makes it fast.
That’s Protocol #2. Gate 30 — Design Complete, where usability risk gets burned down before a line of code is written — is next. Ten gates to go.
