Skip to content

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.

IssueOutside revenue at stakeRank
Search returns no inspectors outside 50 metro areas; 31 Visitors a day leave4 featured listings a week1
Staff typed credential numbers by hand three times2 hours a week2
One inspector asks for calendar syncNone until a second paying inspector asks3

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

FromToWhat passes
Product LeadEngineering LeadThe top Issue, as one Change
Product LeadDesignerThe flow where buyers leak most
Product LeadContent LeadOverrides to compiled Site copy
Customer TeamProduct LeadIssues from Conversations and onboarding
Product LeadFounderAny change to the founding Hypothesis

Next