Choose one sheet, not all six
| If you are stuck on | Use | Finish with |
|---|---|---|
| Whether the problem is real | Problem evidence log | A testable problem statement and the next missing fact. |
| What belongs in version one | MVP scope sheet | One complete flow with explicit exclusions. |
| Which technology to commit to | Stack risk register | A choice tied to maintenance and failure recovery. |
| How to charge | Pricing decision sheet | A value metric, package boundary and test. |
| How to learn from early outreach | Buyer conversation ledger | A record of fit, timing, objections and next steps. |
| Why users do not return | Retention trace | The earliest break between signup and repeated value. |
1. Problem evidence log
Use this before treating an idea as a product opportunity. Add one row for each real incident, not one row for each person who says the idea sounds useful.
| Field | What to record |
|---|---|
| Date and trigger | When the workflow started and what created the need. |
| Person and responsibility | Who did the work and who was accountable for the result. |
| Current steps | The tools, handoffs, files and checks used today. |
| Failure or friction | What was slow, confusing, risky or repeatedly corrected. |
| Consequence | What changed because of the problem: delay, extra work, missed follow-up, rework or uncertainty. |
| Buying authority | Who could approve a change, and what else would influence the decision. |
| Unknown | The most important fact still based on assumption. |
Decision prompt: “For [buyer role], [trigger] creates [specific workflow problem]. They currently use [workaround], which leads to [observable consequence]. We still need to learn [unknown].”
Next move: If incidents do not share a buyer, trigger or consequence, collect more evidence. If they do, choose a test from the validation hub.
2. MVP scope sheet
Use this when the backlog contains several reasonable ideas but the first useful release is still hard to describe.
Write the core flow in one line
“When [trigger], the user provides [minimum input], the product helps them [critical action], and they leave with [useful result].”
| Part of the flow | Define it | Boundary question |
|---|---|---|
| Entry | What the user must already know, have or upload. | Can setup be handled manually for the first pilot? |
| Core action | The smallest transformation from input to result. | Which steps need judgment rather than automation? |
| Result | What the user can review, send, decide or complete. | Can the user tell whether the result is correct? |
| Risky state | Bad data, missing permission, failed payment or unavailable integration. | What must be prevented, explained or recovered? |
| Support fallback | What the operator can inspect or repair. | Can you help without editing production data blindly? |
| Explicitly out | Adjacent jobs, custom requests and edge cases postponed for now. | Would removing this break the core result? |
Decision prompt: Keep an item only if removing it prevents the first useful result, creates unacceptable risk or makes support impossible. Move the rest outside the pilot boundary. The MVP hub has deeper guides for each part.
3. Stack risk register
Use this after the workflow is clear. Comparing feature lists too early rewards novelty and hides the cost of operating the product.
| Component | Questions to answer before choosing |
|---|---|
| Customer data | Where does it live? How is access separated? Can customers export or delete it? |
| Authentication | Who manages identity, password recovery, organisations and permissions? |
| Critical integration | What does the user see when it is slow or unavailable? Can the job be retried safely? |
| Automation | Where are runs logged? Who receives failure alerts? Which steps must be idempotent? |
| Billing | Which states affect access? How are failed payments, refunds and plan changes handled? |
| AI or variable-cost service | What is the cost unit? How is poor output reviewed? What fallback exists? |
| Deployment and backup | Who can restore the service, and what has actually been backed up? |
| Exit path | What would be difficult to migrate if cost, policy or product needs changed? |
Decision prompt: For each realistic option, record the likely failure, who can recover it and what switching away would require. Prefer the choice whose risks you can explain and operate. Continue in the stack hub.
4. Pricing decision sheet
Use this when the price came from a competitor page, a round number or a fear of asking too much.
- Buyer: Who approves the spend, and who uses the product?
- Result: What becomes faster, safer, more reliable or easier to complete?
- Value unit: Which count grows with customer value: location, project, report, invoice, active record or another workflow unit?
- Current alternative: What combination of software, manual work and outside help handles the job now?
- Variable cost: Which types of usage increase infrastructure, model, transaction or communication costs?
- Support load: Which account types need setup, migration or recurring assistance?
- Package boundary: What meaningful difference separates one offer from another?
- Objection: What does a buyer need to believe before the price feels coherent?
Decision prompt: “The price changes with [value unit] because [reason]. The base package includes [complete outcome]. The next package is for [different operational need], not merely more buttons.”
Test: Ask a buyer to explain the offer back to you before defending it. If the unit or boundary is confusing, revise the package with the pricing hub.
5. Buyer conversation ledger
Use this for outreach, discovery calls and demos. It keeps a quiet “not now” separate from a true mismatch and stops useful objections from disappearing into an inbox.
| Field | Record |
|---|---|
| Reason for contact | The sourced situation that made the buyer relevant. Do not write a generic persona label. |
| Problem language | The buyer’s own words for the job, friction and consequence. |
| Current approach | Tools, people and workarounds already in place. |
| Timing | Why the issue matters now, later or not at all. |
| Objection | Fit, trust, price, switching effort, authority, priority or another specific barrier. |
| Product evidence | What the conversation confirms, weakens or leaves unknown. |
| Next step | A dated action agreed by both sides, or a clear closed outcome. |
Weekly review: Group conversations by trigger and objection. Change the message when relevant buyers misunderstand it; change the target when the problem is not important to the people reached. The acquisition hub helps choose the next channel or conversation.
6. Retention trace
Use this when signups, usage or cancellations do not explain why value fails to repeat. Trace individual accounts before averaging them together.
| Moment | Evidence to inspect | Question |
|---|---|---|
| Promise | Landing page, sales notes, plan selected. | What did the customer expect to achieve? |
| Setup | Invites, permissions, imports, integrations. | What had to be true before useful work could begin? |
| First result | Completed workflow, saved output, sent report or resolved task. | Did the customer reach a result they could judge? |
| Repeat use | Second workflow, return interval, shared output. | Was there a natural reason to come back? |
| Friction | Errors, abandoned steps, support requests, manual intervention. | Where did confidence or momentum break? |
| Outcome | Continued use, downgrade, cancellation or silent inactivity. | What happened after the break, and what replaced the product? |
Decision prompt: Compare a successful trace with a stalled one. Fix the earliest difference that the product can reasonably influence. Do not use a late reminder to cover an early setup failure. Continue with the growth hub.