product-loop

Product Loop

One product decision cycle in four phases: Discover what deserves building, Specify what must be true, Launch to a bounded audience, then Learn whether the bet paid. Enter at the phase the evidence supports and stop at the next decision; repository planning belongs to implementation-plan and interface critique to product-design-review.

Situation	Phase
The problem, demand, or wedge is still unproven	Discover
Discovery is validated and behavior must be pinned down	Specify
The change is built and needs a staged audience	Launch
The experiment, launch, or sales attempt has produced results	Learn

Ground Rules

• Separate observations, supplied evidence, inferences, and assumptions. Never convert enthusiasm into proof.
• Do not invent quotes, logos, metrics, demand, research, legal requirements, availability, or support capacity.
• Do not contact customers, create accounts, mutate a CRM or analytics, publish pages, buy ads, or spend money without explicit authorization.
• Use a requirements echo only when the input is long, contradictory, or course-changing; label user statements, evidence, inference, and proposals separately.

Workflow

Discover

Challenge the premise before refining the solution, and keep doing nothing, a manual service, or a smaller change among the alternatives. Close with the discovery brief from briefs.

1. Recover context: read supplied research, product artifacts, and repository constraints; use technical-research when external facts could change the decision.
2. State the thesis: target user, painful job, proposed change, expected outcome, and why now in one sentence; mark unsupported parts as assumptions.
3. Interrogate the problem: how users solve it today, how often, what it costs them, who chooses or pays, and what evidence shows urgency.
4. Find the wedge: the smallest end-to-end result with standalone value; reject bundles of independent products and defer scale architecture until demand justifies it.
5. Test founder logic: unique insight, distribution path, switching friction, business model, defensibility, operational ownership, and unfair access to the problem.
6. Generate alternatives: two or three materially different paths with trade-offs, led by the simplest and including a credible no-build path.
7. Rank assumptions: score value, usability, viability, feasibility, distribution, and trust assumptions by impact and uncertainty; keep the list short.
8. Design the cheapest decisive test: behavior to observe, segment, exposure, time box, success threshold, guardrail, and kill criterion; prefer commitments over compliments (see demand-tests).
9. Make the call: BUILD, TEST FIRST, PARK, or STOP, naming the evidence that would change it.