From idea to evidence and real-world impact, with AI in your product team. Five phases, eleven steps, a decision gate at the end of each phase, and one Product Book that carries the context.
Select a phase, a person or a decision gate.
Independent tutors lose track of confirmations and reschedules, and spend about an hour each Sunday chasing messages. Hypothesis: a booking link will cut rescheduling messages, shown by 50% of reschedules going through the link.
Gate: Is the problem real, and worth solving? Proceed Twelve tutor conversations; nine described the Sunday chase unprompted.
Alternatives: WhatsApp, spreadsheets, paper diaries and booking platforms that take a fee. Riskiest assumption: parents will book without help. Test: 8 tutors for 2 weeks, with a threshold of 50% of reschedules through the link.
Gate: Does the evidence support proceeding? Proceed with conditions The booking link scored best of three concepts. Still assumed: parents will book without help. Owner: the founder; checked at the Assemble gate.
Must have: a tutor shares a link, a parent picks a slot, the tutor sees bookings. Not now: payments, text reminders, a mobile app. Decision: one simple web application and one database.
Gate: Is the solution feasible, proportionate and well designed? Proceed Thresholds set before building; the decision record compares two options.
Two slices built and tested: share a link, and book a slot. In the demo, five tutors set up their link unaided; one parent missed the confirm button, so it moved before launch.
Gate: Does the MVP meet its objectives, and is it ready to launch? Proceed The condition closed: parents booked unaided in the demo, after the confirm button moved.
Launched to 8 tutors with real sign-in, backups, a privacy notice and error alerts. 41% of reschedules went through the link, below the 50% bar. Decision: iterate, adding reminders, and test again.
Gate: Persevere, iterate, pivot, pause or stop? Iterate 41% of reschedules through the link, against a 50% bar set in advance. Back to Plan to add reminders, then test again: the next loop.
Growth evidence becomes the next problem statement. TutorDesk goes round again with real usage data, and later, grown to 2,000 tutors, becomes the case study in Think Like a CTO.
Customer interviews and research
Users, customers and stakeholders
Product, design and engineering
Development, testing and real users
Early adopters and the wider market
Shared source of context for people and AI
Problem statement
Research and evidence
Concepts and hypotheses
Business model and experiment
MVP objectives and design
Architecture decision record
Backlog and build notes
Sprint review and grade
Launch plan and readiness
Decision memo and next loop
Categories, not brands: the framework works with any capable tools, because the briefs live in the Product Book.
Is there a real problem, for whom, and how do we know?
Start with people, not features. Talk to the people who have the problem, write down what you observed rather than what you hoped, and turn it into a problem statement and one testable hypothesis.
product/01-discovery.md product/evidence/
Plans interviews, summarises notes you collected, and challenges vague or self-serving problem statements. It never stands in for a conversation with a real customer.
Is the problem real, and worth solving?
To proceed: Pain backed by real conversations, reported as counts with a base, and a hypothesis that names a metric.
Go back: Gather more evidence, or stop.
ProceedProceed with conditionsGo back
TutorDesk, illustrative: Independent tutors lose track of confirmations and reschedules, and spend about an hour each Sunday chasing messages. Hypothesis: a booking link will cut rescheduling messages, shown by 50% of reschedules going through the link.
Is this the best bet, will anyone pay, and how will we test it cheaply?
Generate more than one answer, compare them fairly, and look hard at what people use today, including doing nothing. Then design the cheapest test that could prove the riskiest assumption wrong, with the bar set before the results come in.
product/02-strategy.md
Generates alternative concepts, scores them against the same criteria, maps assumptions across desirability, viability, feasibility and usability, and drafts the experiment.
Does the evidence support proceeding?
To proceed: Three or more concepts scored, the gap stated with evidence, and a willingness-to-pay test designed or run.
Go back: Back to 02 Idea or 03 Ideation.
ProceedProceed with conditionsGo back
TutorDesk, illustrative: Alternatives: WhatsApp, spreadsheets, paper diaries and booking platforms that take a fee. Riskiest assumption: parents will book without help. Test: 8 tutors for 2 weeks, with a threshold of 50% of reschedules through the link.
What must the MVP prove, and what should the experience and the system look like?
Decide the smallest product that can prove the hypothesis, and what it will deliberately leave out. Design the journey, prototype it with users, and choose the simplest architecture that meets the priorities, with every decision written down.
product/03-design.md product/decisions/0001-architecture.md
Compares architecture options, explains the trade-offs in plain English, gives costs as ranges with assumptions, and drafts the decision record. Anything regulated is flagged for a specialist.
Is the solution feasible, proportionate and well designed?
To proceed: Objectives with thresholds written before building, a decision record comparing two options, and the must-pass checks planned.
Go back: Back to Validate.
ProceedProceed with conditionsGo back
TutorDesk, illustrative: Must have: a tutor shares a link, a parent picks a slot, the tutor sees bookings. Not now: payments, text reminders, a mobile app. Decision: one simple web application and one database.
How do we build quickly and safely, and is it good enough?
Build in thin vertical slices, each with acceptance criteria, tests and a review. Show it to real users early, then grade it honestly before anyone relies on it.
product/04-backlog.md product/05-sprint-review.md
Builds slices from a written brief, writes tests and reviews code. A person approves every plan and every change, and an AI review is one input to the grade, never the verdict.
Does the MVP meet its objectives, and is it ready to launch?
To proceed: Slices meet their acceptance criteria, a demo to real users, and both rails graded.
Go back: A weak grade returns to 07. A weak demo returns to 05, or to 03 if the concept is wrong.
ProceedProceed with conditionsGo back
TutorDesk, illustrative: Two slices built and tested: share a link, and book a slot. In the demo, five tutors set up their link unaided; one parent missed the confirm button, so it moved before launch.
Do real people get value, and what do we do next?
Make it safe to rely on, put it in front of real users, and measure the behaviour the hypothesis predicted. Then decide: persevere, iterate, pivot, pause or stop.
product/06-launch.md product/06-decision-memo.md
Works through the readiness checklist, drafts positioning, helps read the funnel and drafts the decision memo. The decision, and the evidence behind it, stay with the team.
Persevere, iterate, pivot, pause or stop?
To proceed: The readiness checklist shown working, and a growth experiment with a threshold and a guardrail.
Go back: A must-pass failure returns to 07. Growth evidence starts the next loop at 01.
ProceedProceed with conditionsGo back
TutorDesk, illustrative: Launched to 8 tutors with real sign-in, backups, a privacy notice and error alerts. 41% of reschedules went through the link, below the 50% bar. Decision: iterate, adding reminders, and test again.
| Who | Map | Validate | Plan | Assemble | Ignite |
|---|---|---|---|---|---|
| Customers and users | Describe the problem in interviews and observation | React to concepts, and to a price | Try the prototype | Use the demo, unaided | Rely on the live product, and show what they value |
| Business owners | Set the ambition and the limits | Judge the business model | Agree scope, budget and risk | Review the demo | Make the persevere-or-pivot call |
| Product team | Run the research and write the problem statement | Generate and score concepts; design the experiment | Set objectives; design and test the journey | Write acceptance criteria; run the demo | Measure, decide and plan the next loop |
| AI assistants | Research partner and challenger | Experiment designer | Virtual CTO | Pair engineer and reviewer | Launch and analytics assistant |
| Engineering team | — | Check feasibility early | Choose the architecture and plan the must-pass checks | Build, test and review each slice | Make it reliable, secure and observable |
Learn MVPAI with the Academy, try the free tools, or talk to us about building your product.