Product playbook
How the Product Team compiles definitions from the founding Hypothesis, ranks one build list, ships daily, and keeps only what wins.
The Product Team decides what a Startup builds, ships it as one small Change a day, and learns from what buyers do. Its inputs are the founding Hypothesis, graded Evidence and one ranked build list.
Start from the hypothesis
Every Product definition traces back to the founding Hypothesis. Its customer slot names the ICP, its problem slot carries what the job costs today, and its approach slot names a Product Template. The Product Team never writes a definition from a blank page.
Take a Startup that sells an Agent to bookkeeping firms with 5 to 20 staff. Matching bank lines to invoices takes 6 hours per client each month, at $40 an hour. The Price compiles as a ratio of that $240 cost, so the Offer lists at $60 per client per month.
Every compiled sentence, Price and Persona records the slot it came from. Editing a compiled line keeps the edit as an override. Changing the slot is a pivot: everything downstream recompiles, and the diff shows what moved.
One build list
Every input becomes an Issue on one list. A miss from support, a feature request, a step done by hand three times and a failed call from an Agent buyer all land there. The Product Lead ranks the list by the outside revenue at stake.
Take a directory of licensed home inspectors that sells featured listings. This week the list holds three Issues.
| Issue | Outside revenue at stake | Rank |
|---|---|---|
| Search returns no inspectors outside 50 metro areas; 31 Visitors a day leave | 4 featured listings a week | 1 |
| Staff typed credential numbers by hand three times | 2 hours a week | 2 |
| One inspector asks for calendar sync | None until a second paying inspector asks | 3 |
Each morning Daily ship hands the top Issue to the Engineering Lead as one Change. Small is the rule: a Change to one Verb ships the same day, and a redesign of five Verbs is five Changes. Once a week the same Workflow prunes features no Customer used in 30 days.
Definitions before code
A new Product starts Define a Product. The Product Lead reads the Offer’s promise and its checkable done state. Then it names the Nouns the Product stores and the Verbs that act on them, each with inputs, outputs and an Event.
A Dataset API of vehicle recall notices declares a Recall Noun, a Vehicle Noun and a match Verb that emits Recall.matched. From that definition the API, CLI, MCP server and SDK generate together. The Engineering Lead implements what the definition declares.
The Designer shapes each screen as data. One definition renders as rich UI for Humans and as Markdown for Agents, so neither reader gets a second-class copy.
Evidence over opinion
The Researcher asks one question when a buyer accepts an Offer: what did you do about this before, and what did it cost? It never asks what a buyer would pay. Each answer is graded as behavior, commitment or opinion, and opinions weigh zero.
An Agent buyer cannot be interviewed, so its errors are its Interview. Twelve failed calls that send the model year as text are behavior, as strong as any quote.
Each grade lands on the Hypothesis slot it supports. The Weekly review ranks slots by one minus their grade, times their impact, and picks the week’s one test.
Test, then keep the winner
Any Change to an Offer, a Page or an onboarding step can run as an Experiment. A Flag splits traffic between variants, one primary Metric decides, and guardrail Metrics stop a variant that harms. The winner becomes the definition; the loser concludes and stays on record.
Take a SaaS that sends appointment reminders for dental clinics, with 400 signups a week. One variant asks for the patient list first; the other starts from a reminder template. Activation in 7 days moves from 31% to 38% on the import-first variant, and it ships.
Small traffic calls for cheaper tests: a smoke page, a fake door, a concierge run or a $100 probe. The Product Team picks the cheapest that yields the grade it needs. It asks for the Portfolio’s prior result first.
Prices
Price change runs on demand. The Product Lead proposes the new Price with its value metric and margin. A Price is never randomized for the same Offer in one market; it is tested as a sibling Offer, by geography or by switching periods.
The new Price applies to new buyers only. Existing Customers get notice before any change to their terms, and the updated Offer publishes last.
Handoffs
| From | To | What passes |
|---|---|---|
| Product Lead | Engineering Lead | The top Issue, as one Change |
| Product Lead | Designer | The flow where buyers leak most |
| Product Lead | Content Lead | Overrides to compiled Site copy |
| Customer Team | Product Lead | Issues from Conversations and onboarding |
| Product Lead | Founder | Any change to the founding Hypothesis |
Next
- Product Team: Roles, Processes and Metrics.
- Engineering playbook: how a Change reaches all traffic.
- Quality playbook: how every Change earns its verdict.