Framework / Discovery

Discovery

The left loop of the Double Loop — seven nodes from signal to acceptance criteria. Not every node fires on every initiative; the documentation menu right-sizes the rigor to the scale and risk of the work.

Published Jun 20, 2026

The Principle

The Big Idea

Discovery is the problem-and-solution loop: signal to acceptance criteria, before any production code is written. The seven nodes describe the full path, but the path is a menu, not a mandatory pipeline. A small, well-understood enhancement might move from a quick problem check straight to acceptance criteria. A large strategic initiative works through every node and documents each one deeply.

The goal is not to traverse the nodes. The goal is to understand the problem well enough to build the right solution.

Over-investing in discovery on small bets creates bureaucratic overhead that slows teams without improving outcomes. Under-investing on large, ambiguous bets creates the expensive misdirection that wastes quarters of engineering effort. The judgment call — which nodes matter for this work, and how deeply to document each — is the PM's to make. The harness provides the nodes and the templates; it doesn't mandate the sequence.

When Discovery Applies

When to Start Upstream

Discovery is warranted when significant uncertainty exists about the problem, the opportunity, the solution, or the evidence supporting any of them. Common triggers: new problem spaces where the team lacks deep customer or market understanding; ambiguous signals where multiple problem definitions are competing; significant investment where the cost of being wrong is high; competitive responses where the threat and the right counter-move are unclear; and new markets or customer segments the team hasn't served before.

The contrast matters. Small enhancements and bug fixes with well-understood problems don't need the full loop — the problem is clear, the solution is constrained, and the risk is low. Features that represent strategic bets, new capabilities, or significant engineering investment do. If the PM can't clearly articulate what problem this solves and for whom, that's a signal to go upstream before writing acceptance criteria.

The Discovery Loop

The Seven Nodes

The loop runs clockwise through seven nodes, each building confidence that the team is solving the right problem in the right way. Node 1 (Signal) is the entry point and also where Delivery's Impact signal returns; node 7 (Acceptance Criteria) is the optional exit across the crossing point into Delivery.

Signal / Trigger

What it is: Something prompts inquiry — a user complaint, a metric drop, a strategic initiative, or an Impact signal returning from Delivery. The entry point to Discovery and the point where the Delivery loop hands back.

Produces: A logged signal with enough context to decide whether it's worth defining — a signals inventory entry, not yet a problem statement.

AI's role: Cluster raw signals from support tickets, usage data, and feedback themes; surface recurring patterns a human hasn't yet named; draft a first articulation of what's being observed.

Human judgment: Is this worth pursuing at all? Distinguishing noise from a real problem, and deciding what earns attention, is the PM's triage call.

Problem Definition

What it is: A scoped, agreed-upon statement of the problem and who has it. Without it, everything downstream aims at a moving target.

Produces: Problem statement, affected customer segments, and the evidence behind the problem.

AI's role: Draft problem statements from the signals inventory; check the framing for ambiguity; surface where stakeholders would define the problem differently.

Human judgment: What problem are we actually solving, and for whom? Reconciling competing definitions and committing to one is the PM's call.

Solution Design

What it is: Exploring the solution space — options, trade-offs, a direction. Not a final answer; a recommendation that can be iterated.

Produces: Solution options, trade-off analysis, a direction recommendation. When investment warrants it, an Opportunity Assessment validates the direction is worth committing to — see the Documentation Menu.

AI's role: Generate alternative approaches; map trade-offs across options; pull comparable patterns from the codebase or prior work; structure the assessment against value, usability, feasibility, and viability.

Human judgment: Which direction, and is it worth committing resources to? Strategic fit, build-vs-buy, and the commit/no-commit decision require human accountability.

Designs

What it is: UX artifacts, interaction models, and interface definitions shaped by the chosen direction. The design brief becomes a structured handoff, not a Figma link and a prayer.

Produces: UX artifacts, interaction models, component-level design intent, and the visual states the prototype will render.

AI's role: Translate design frames into component code following the team's tokens and conventions; generate Storybook states; flag mismatches between a design and the system it has to live in — a field the UI expects that the data model doesn't provide.

Human judgment: Does this match the intended experience? Visual hierarchy, interaction feel, and design-system fit are the designer's call — AI renders the design, it doesn't decide it.

Prototype

What it is: A working, testable artifact — lo-fi to hi-fi depending on the confidence the team needs. The PM builds this in the developer environment with an AI coding agent, before engineering begins.

Produces: A running prototype reviewable by stakeholders and users — the thing validation is run against.

AI's role: Scaffold a working prototype from the designs and direction; apply repo conventions by default so the prototype reads like real product; iterate quickly as the PM refines.

Human judgment: Is this faithful enough to learn from? How much fidelity this decision actually requires — and when to stop building and start testing — is the PM's judgment.

Validation

What it is: Real feedback on the prototype from stakeholders and users. Where the four product risks — value, usability, feasibility, and business viability — get answered with evidence rather than opinion, before any production code is written.

Produces: Research findings, prototype results, and technical-spike outcomes — assumptions converted into known facts. May loop back to Problem Definition or Solution Design if the prototype reveals a misalignment.

AI's role: Synthesize feedback across sessions; surface patterns and contradictions in what users did; draft findings against each of the four risks.

Human judgment: What does the evidence actually mean, and is it enough? Interpreting weak signals and making the go/no-go call is product judgment AI can inform but not own.

Acceptance Criteria

What it is: The contract for done, authored from the validated prototype rather than abstract specification. The optional exit point — when AC is confident and signed off, the team crosses into Delivery.

Produces: Structured, testable acceptance criteria with the gaps closed — published to the backlog and test management as downstream copies, authored once in the repo.

AI's role: Refine criteria for testability; run gap analysis for missing edge cases, loading and error states, and criteria that contradict each other; convert loose criteria into machine-readable form; publish to tracking systems without retyping.

Human judgment: Are these specific enough to build against, and is this ready to cross into Delivery? Scope and the commit-to-build decision stay with the PM.

Right-Sizing the Work

How Many Nodes, How Deep

The right amount of discovery is proportional to the uncertainty and investment associated with the work — not to an arbitrary standard of rigor. How many nodes you traverse, and how deeply you document each, scales with the bet:

Small Work

Problem Check → Acceptance Criteria

Well-understood problem, clear solution, low risk. Enhancements to existing functionality, bug fixes with clear root causes, UX polish on established patterns.

A quick Problem Definition check that everyone agrees, then straight to Acceptance Criteria. The middle nodes are skipped.

Medium Work

Solution Design → Validation

New capability with some uncertainty about problem or opportunity. A feature in a well-understood area but with non-trivial investment or stakeholder alignment requirements.

Explore the solution space, prototype, validate against the four risks, then author Acceptance Criteria from what was tested.

Large Work

All Seven Nodes

Strategic initiative, new market, significant resource commitment, high uncertainty about problem, solution, or both. The cost of being wrong justifies the full traverse.

Every node, documented deeply, plus the Opportunity Assessment and Pitch artifacts. Leadership alignment before engineering begins.

The full picture, including exploratory work:

Idea Scale	Typical Path (nodes)	Documentation Depth
Small	Problem Definition → Acceptance Criteria	Backlog ticket + acceptance criteria
Medium	Solution Design → Designs → Prototype → Validation → AC	Solution Discovery + Validation & Evidence + AC
Large	Signal → … → Acceptance Criteria (all seven)	Full menu, incl. Opportunity Assessment + Pitch
Exploratory	Signal → Problem Definition, then pause and reassess	Problem Framing only — the goal is to understand, not commit

Exploratory work is a legitimate discovery path that the standard three-bucket model misses. Sometimes the right outcome of discovery is "we need more time to understand this before committing." Defining the problem produces a shared statement that lets the team make a deliberate choice to pause, deprioritize, or continue — rather than either over-investing in uncertainty or avoiding the hard work of understanding it.

The Documentation Menu

Artifacts That Span the Nodes

The nodes describe the path; the documentation menu is how you record it. Each artifact spans one or more nodes, and its depth scales with the evidence available at that moment. None is required for every initiative — each is available whenever the scale or audience calls for it. Opportunity Assessment is a commit/no-commit decision document, not a workflow node — it lives here, in the menu, rather than on the loop.

Artifact	Nodes it covers	Purpose
Problem Framing	Signal / Trigger → Problem Definition	Structures raw signals into a shared problem statement
Opportunity Assessment	Decision between Problem Definition & Solution Design	Is this worth pursuing? A decision document, not a node
Solution Discovery	Solution Design → Designs	Maps the solution space and chosen direction
Validation & Evidence	Prototype → Validation → Acceptance Criteria	Converts assumptions into evidence; produces the AC

Problem Framing

When to use: When the problem itself is unclear, contested, or defined differently by different stakeholders. When signals exist but haven't been synthesized into a coherent problem statement. When a new area is being entered and customer context is thin.

When to skip: When the problem is well-understood and uncontested, or the work is an improvement to existing, well-defined functionality.

Produces: Problem statement, customer segments, signals inventory — the artifact that ensures teams agree on what they're solving before solution thinking begins.

Opportunity Assessment

When to use: When investment size warrants market validation. When leadership needs a business case before committing resources. When the competitive landscape is relevant to the decision. When legal or compliance implications exist.

When to skip: For low-stakes improvements where the business case is obvious, or when the decision is already made at a leadership level and the PM's job is execution, not evaluation.

Produces: Opportunity sizing, competitive landscape, business case inputs. Evaluates value, usability, feasibility, and business viability before significant resource commitment. A decision document that sits between Problem Definition and Solution Design — not a node on the loop.

Solution Discovery

When to use: When multiple approaches to solving the problem are viable and the right one isn't obvious. When the solution space hasn't been explored. When technical or UX trade-offs need to be surfaced before committing.

When to skip: When the solution is obvious, constrained by existing architecture, or already decided. When the team is implementing a well-defined spec, not choosing a direction.

Produces: Solution options, trade-off analysis, direction recommendation. Maps the solution space before locking in a path.

Validation & Evidence

When to use: Before significant investment in a direction. When assumptions about user behavior or market response need validating. When a go/no-go decision requires evidence, not opinion. When new technology, new UX patterns, or regulatory questions create meaningful uncertainty.

When to skip: For fast-moving experiments where the cost of being wrong is low and speed of learning is high. When prior evidence already supports the direction.

Produces: User research findings, prototype results, technical spike outcomes, regulatory confirmations — and the acceptance criteria that hand off across the crossing point into Delivery.

—

Pitch / Business Case

A persuasion document for decision-makers — combines discovery outputs into a leadership-ready narrative. Can be generated from any node; depth scales with the evidence available at that moment. Early on, it's a lightweight problem framing with a hypothesis about the opportunity. By Designs or Validation, it's a fully evidenced business case with validated solution direction, sizing, and risk assessment. The same document evolves rather than being replaced.

—

PRFAQ

"Working backwards" clarity tool. Write the press release as if the solution shipped — what would be announced, and would customers care? — then stress-test it with FAQs from multiple stakeholder angles (customers, engineering, legal, support). Best introduced once a solution direction is taking shape but hasn't been fully committed to. An early PRFAQ exposes assumptions; a late one, anchored in validation evidence, tests the narrative against the findings.

Decision Accountability

DACI — Who Owns Each Decision

Each discovery artifact includes a DACI line that makes decision-making accountability explicit. Discovery decisions are no different from delivery decisions — the ProductHarness principle that accountability stays with people applies here too. "We discussed it" is not a decision. DACI is what converts a discussion into a traceable commitment.

Even one line is enough for medium-scale work. The discipline of filling in the DACI forces a specific question: who actually makes this call? When that question isn't answered before the work begins, it has to be answered mid-flight — usually at the most expensive possible moment.

Role	Definition	Notes
D — Driver	Owns moving the work forward; accountable for the decision process	Typically the PM. Ensures the right inputs are gathered and the decision gets made. Does not necessarily make the final call — that's the Approver.
A — Approver	Makes the final call; can be one person or a defined group	There should be exactly one Approver. If a group needs to approve, name the group but clarify who has final authority when the group disagrees.
C — Contributors	Provide input, expertise, or review before the decision	Their input is required before the Approver decides, but they don't make the call. Include engineering leads for feasibility, legal for compliance implications, design for UX risks.
I — Informed	Notified of the decision after it's made	Stakeholders who need to know but don't need to input. Being Informed is a courtesy, not a gatekeeping role — the decision doesn't require their agreement.

Framework References

The Frameworks This Draws On

The ProductHarness discovery templates synthesize established product discovery frameworks rather than inventing new ones. Understanding the source frameworks helps PMs apply the templates more skillfully — especially in edge cases the template structure doesn't explicitly cover.

Marty Cagan's Opportunity Assessment — SVPG

Ten questions for evaluating whether to pursue an opportunity. Structures the Opportunity Assessment with concrete questions about problem significance, market size, solution existence, and strategic alignment. Ensures the assessment covers the dimensions that matter before committing resources — not just "is this interesting?" but "is this worth pursuing at this scale, against these alternatives, with these risks?" The ten questions are especially useful for prompting the agent to help complete the assessment.

Cagan's Four Big Risks — SVPG

Value, Usability, Feasibility, Business Viability. The four dimensions of product risk that must be addressed before committing to a solution. Value risk: will customers actually use this? Usability risk: can users figure out how to use it? Feasibility risk: can engineering build it in a reasonable timeframe? Business viability risk: does this work for the business model, legal constraints, and organizational capacity? The four risks are answered with evidence at the Validation node, and referenced throughout Solution Design as options are evaluated.

Teresa Torres' Opportunity Solution Tree

Outcomes → Opportunities → Solutions → Experiments. A visual thinking tool for structuring the solution space at the Solution Design node. The tree starts with the desired outcome (what business or user result are we driving toward?), maps the opportunities that could contribute to it, branches into possible solutions for each opportunity, and then into experiments that could validate those solutions. It prevents teams from jumping to a single solution and validates that the chosen direction is the best available path through the opportunity space. Especially useful when multiple solution approaches exist and trade-offs need to be made explicit.