Every product starts with someone’s problem
Tonight you turn an idea into a problem a real person has, and plan how to find out whether it is true.
MVPAI: map, validate, plan, assemble, ignite
- MAPUnderstand the problem
- VALIDATEProve the opportunity
- PLANDefine the MVP
- ASSEMBLEBuild, show and grade
- IGNITELaunch and grow
Map the problem. Validate the idea. Plan the MVP. Assemble with AI. Ignite the business.
What you will leave with tonight
- Explain how a product differs from a project and from a feature
- Explain why AI makes building cheaper but does not make being wrong cheaper
- Write a problem statement: user, situation, struggle, consequence, evidence
- Plan a 20-minute customer conversation that asks about past behaviour
- Set up a Claude Project for your product with a working agreement
OUTPUT · Problem Statement v1 + interview guide, saved in your Product Book
Building got cheap. Being wrong did not.
What AI made cheaper
- A working screen in an afternoon instead of a month
- Trying three versions of an idea in one evening
- A first draft of almost any document or plan
What still costs the same
- Months spent on something nobody needed
- Your savings, your evenings and your credibility
- Users who try it once and do not come back
When building is cheap, the expensive mistake is building the wrong thing well.
Project thinking vs product thinking
Project thinking
- Success means delivered on time and on budget
- Starts from a list of features to build
- Ends at launch, and the team moves on
Product thinking
- Success means a person’s problem is solved and they come back
- Starts from a problem and a guess about how to solve it
- Launch is the start of learning, and the work continues
A feature is a part. A project is a delivery. A product is an ongoing answer to a problem.
Four levels of evidence
- OPINION“That sounds useful.” Polite, free to give, and the weakest signal
- STATED NEED“I’d definitely use that.” A prediction about the future, often wrong
- OBSERVED BEHAVIOURWhat they did last time: the workaround, the missed message, the lost booking
- COMMITMENTThey give time, money or reputation: a trial, a deposit, an introduction
Climb the levels. One real commitment outweighs twenty compliments.
From “an AI booking app” to a real problem
“An AI-powered booking app for tutors.”
Independent tutors with 5–30 regular learners lose new lesson enquiries in WhatsApp and email during busy weeks, and only notice when a parent has booked someone else.
Ask
- Which words in the weak version describe technology, not a problem?
- Who exactly has the problem, and when does it happen?
- What does it cost the tutor when it goes wrong?
- What would we need to see to believe it is real?
Anatomy of a problem statement
- USERA specific kind of person, narrow enough to find and contact this week
- SITUATIONThe moment it happens: when, where, and what set it off
- STRUGGLEWhat goes wrong for them, described in their words, not your solution
- CONSEQUENCEWhat it costs them: time, money, stress or a missed opportunity
- EVIDENCEAssumed, heard or observed, and from how many people
If your statement names your product, it is a solution statement. Rewrite it.
Weak vs strong problem statement
“Tutors need a better way to manage their bookings.”
Solo maths tutors with 10–30 learners miss enquiries sent by WhatsApp during exam season and lose paying learners as a result. Evidence: assumed, not yet tested with tutors.
Ask
- Which of the five parts are missing from the weak version?
- Could two people read the strong version and picture different users?
- What one conversation would change its evidence status?
Questions that mislead vs questions that reveal
Questions that mislead
- “Would you use an app that…?” invites a polite yes
- “How much would you pay for…?” asks for a guess
- “Don’t you find it annoying when…?” leads the answer
Questions that reveal
- “Tell me about the last time a new learner contacted you.”
- “What did you do next? Then what happened?”
- “What have you tried to fix it, and what did that cost you?”
Ask about the past, not the future. People are reliable about what they did, not what they will do.
A 20-minute customer conversation
- OPEN2 min: thank them, say you are learning not selling, ask to take notes
- THE LAST TIME6 min: “Tell me about the last time…” and follow the story in order
- WORKAROUNDS5 min: what they did instead, and which tools, people or tricks they used
- COST4 min: what it cost in time, money or stress, and how often it happens
- CLOSE3 min: “Who else should I talk to?” and ask if you can follow up
Your guide is a plan, not a script. Follow their story; return to the plan when it ends.
Claude Studio: a Project with a working agreement
I’m building [MY PRODUCT] for [WHO IT IS FOR]. This Project holds my Product Book, so every chat here starts from the same context. I’m at the very start: I want to find out whether the problem is real before I build anything, so challenge my assumptions rather than encourage me. Tell me when you’re unsure, and separate what you know from what you’re guessing by labelling guesses “assumption”. Explain trade-offs in plain English. Ask before adding dependencies, touching data or deleting anything. Report what you actually did. A good answer is short, written for someone non-technical, and ends with the one question I should answer next. Nothing you say counts as customer evidence; only real people can give me that.
Check the response
- Claude summarises your product from the Project context
- Guesses are labelled as assumptions
- It challenges your idea instead of praising it
Claude Studio: rehearse the interview
I’m preparing my first customer conversation for TutorDesk, a booking tool for independent tutors. I want to practise here first, so that I make my mistakes before I meet real tutors. <guide>[PASTE YOUR INTERVIEW GUIDE]</guide> Please play a solo tutor with about 15 regular learners who is busy and polite. Answer only what I ask, the way a real person would: if my question invites a polite yes, give one. When I type “end”, step out of the role and review my questions. List each question that was leading or about the future, say why it misleads, and give a past-behaviour rewrite. If you’re unsure whether a question was leading, say so. Your tutor is invented, so I’ll treat this as practice, not evidence.
Check the response
- The rehearsal exposes at least one leading question
- Each weak question gets a past-behaviour rewrite
- Nothing from the rehearsal goes in the evidence log
What Claude can and cannot do in discovery
Claude can help you
- Sharpen a vague problem statement into its five parts
- Rehearse an interview and critique your questions
- List alternatives to investigate, with sources you can check
Only real people can
- Tell you what actually happened last Tuesday
- Show you their workaround: the inbox, the diary, the spreadsheet
- Commit time or money, the evidence that counts most
Claude improves your thinking. Customers supply the evidence. Keep the two apart in your Product Book.
How gates work: proceed, with conditions, or go back
- PROCEEDThere is enough evidence to move on. Nothing extra to record.
- WITH CONDITIONSMove on with a known gap: write the assumption, its owner and where it is re-checked
- GO BACKA critical gap: return to the phase the gate names and say what must change
- QUALITY SCOREPass, Merit or Distinction: how good the work is, with a person signing it off
- MUST-PASSBlocking checks, such as secrets kept out of code; never passed with conditions
The grade says how good the work is. The decision says whether you move on. Must-pass checks block either way.
Workshop: Problem Statement v1 + interview guide
Write the problem your product solves, with honest evidence labels, and a guide for the conversations that will test it.
- Write your problem statement in five parts; label evidence as assumed, heard or observed
- Swap with a partner, who circles technology words and missing parts; then rewrite
- Draft a 20-minute guide: open, the last time, workarounds, cost, close
- Practise in pairs, 5 minutes each; your partner plays the user and notes leading questions
- Save both in your Claude Project and list three real people to talk to this week
Problem Statement v1 + interview guide in product/01-discovery.md
Gate: Problem Statement v1
- Names one user group narrow enough to contact this week
- Describes the situation where the problem happens, with a trigger or moment
- States the struggle in the user’s terms, without naming a product or technology
- Names a consequence: time, money, stress or a lost opportunity
- Labels evidence honestly as assumed, heard or observed, and from how many people
- Interview guide asks about past behaviour; no question invites a polite yes
HOMEWORK · Hold one or two real conversations before Thursday; bring your notes and one surprise
© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms