From Problem to Prototype Thinking 🎯
Three frameworks. Three minutes each. The fastest way to shift your brain from thinking about ideas to making something real.
Why Fast Beats Perfect
Every great product company shares one habit: they stop talking about ideas and start making them tangible, fast. Not because they have resources — because a rough prototype teaches you more in 30 minutes than a week of discussion.
"Build to Think"
- Prototype to learn, not to present
- "Fail often to succeed sooner"
- Empathy first — watch real people
- Low-fidelity beats no prototype
- Bodystorming: act it out physically
"Compress Time"
- Map → Sketch → Decide → Prototype → Test
- Realistic prototype in one day
- 5-person test reveals 85% of issues
- Note-and-vote decisions
- Lightning demos for inspiration
"Talk to Users"
- "Do things that don't scale"
- 10 conversations > 1 survey
- Concierge MVP: do it by hand first
- Launch fast, iterate always
- "What would have to be true?"
3 Minutes: Steal Like an Artist
Before building, get inspired by what already exists. Each team member spends 3 minutes finding one product, service, or solution anywhere in the world that tackles a similar problem — any industry.
Share in 30 seconds each: "This is [X]. What I want to steal from it is [Y]." Write stolen ideas on sticky notes. These become ingredients for your prototype.
Revisit Your Wanted Poster — Choose One Idea to Test
Take out your Wanted Poster from Workshop 1. Read the root cause and problem statement aloud as a team.
Each member shares one idea from Crazy 8s in 60 seconds — no debate yet, just share.
Dot-vote (2 dots each). Pick the idea with most votes. If tied, pick the one where you are most uncertain — that's the one most worth testing today.
Write your belief statement: "We believe that [IDEA] will help [WHO] solve [PROBLEM]."
Surface Your Assumptions 🗺
Every idea is a stack of unproven beliefs. Get them on the table and find the one that would kill your idea if it turns out to be wrong.
Brain-dump Every Assumption (15 min)
On Print 01, write every belief your idea depends on. One assumption per sticky note.
| Category | The question to ask | Example |
|---|---|---|
| Customer | Does this problem actually exist for them? | "Students find the canteen queue frustrating enough to act" |
| Behaviour | Will they change what they currently do? | "They'll check an app before walking to lunch" |
| Value | Is our solution clearly better than the alternative? | "Real-time queue data is worth downloading an app for" |
| Willingness to pay | Would they pay, subscribe, or consistently use this? | "Canteen operators would pay €50/month for this data" |
| Access | Can we actually reach these people? | "We can get canteen staff to install sensors" |
| Technical | Can this actually be built? | "Queue length can be estimated from camera footage" |
Find the Riskiest Assumption (10 min)
Draw a 2×2 on Print 01. Plot each assumption on two axes. The top-left quadrant (high importance + low certainty) is your Critical Assumption. Circle it in red — your prototype must test this today.
Y-axis: Importance — If wrong, does the whole idea collapse?
X-axis: Certainty — Real evidence, or just a hunch?
Top-left = Critical Assumption. Circle it. That's what you're testing today.
Turn the Problem into a Design Challenge (10 min)
Created by IDEO and used in every Google Design Sprint. Take your critical assumption and reframe it as an open question — an invitation to solve rather than a problem to complain about.
Formula: How Might We [verb] [user's need] so that [positive outcome]?
Write 3 HMW questions on Print 02. Vote on the one most exciting to solve. This is your design challenge for the prototype sprint.
"What Would Have to Be True?"
Y Combinator partners use this question with every startup pitch: "For your idea to work, what would have to be true about the world?" If your answers sound unlikely — you've found your critical assumption.
Build the Minimum Testable Thing 🔧
Choose a technique from IDEO, Google or YC. Build the cheapest thing that can test your critical assumption. Ugly is fine. Done is mandatory.
The Prototype Is a Question Made Tangible
You are not building a product. You are building the minimum thing needed to get a genuine reaction from a real person. The moment someone interacts with it, you learn something no conversation can give you.
7 Prototype Formats — Pick One
Build Focused on Your Critical Assumption
Use Print 03 — Prototype Plan to plan before building:
Write your critical assumption at the top. Everything you build must test this — nothing else.
Find the one moment in your idea where the user either "gets it" or doesn't. Build that moment first.
If you spend more than 5 minutes on any element — simplify it. Ugly is fine. Missing features are fine. Testable is mandatory.
Before finishing, write exactly 3 questions to ask real people. Open-ended: "What do you think this is?" not leading: "Do you like it?"
Common Mistakes
Building too much: You're testing one assumption. Don't add features. More fidelity doesn't mean more insight — it means more wasted time.
Pitching instead of showing: Put the prototype in front of someone and stay quiet. The moment you explain it, you've invalidated the test — you want their natural reaction.
Testing on friends who want to be nice: YC calls this the "Mom test failure." Find people who match your target user and have no reason to be polite about your idea.
Test with AI Before Testing with Humans 🤖
Run a rapid digital simulation before your field sprint. Get your first round of feedback in minutes — then go outside sharper and better prepared. Choose 1–2 activities based on time.
Roleplay Your Target User
Before testing with real people, rehearse with AI. Give it a precise persona and ask it to react to your prototype as a real user would. You'll find obvious holes before going outside.
User Interview Simulation Prompt
One team member pastes this into Claude or ChatGPT and describes your prototype.
Another team member "interviews" the AI using your 3 prepared questions.
Note every surprise or confusion. These are likely real reactions you'll get outside too.
Refine your 3 questions or tweak your prototype based on what you learned. Then go test for real.
Ask AI to Destroy Your Idea
Y Combinator investors challenge every startup with hard questions. Simulate this before your real test — find the weaknesses yourself first.
Stress-Test Your Idea
After reading: which criticisms surprised you? Which worry you most? Does your prototype test any of these risks?
Build a Testable Landing Page in 10 Minutes
Use AI to generate landing page copy, then paste it into a free tool (Google Forms, Carrd.co, or Notion) to create a testable digital artefact before the field sprint.
Generate Your Landing Page
Copy the output into Carrd.co (free, no-code, 5 min to publish) or paste into a Google Doc.
Add a Google Form link as your "Sign up" button — see if people actually click.
Show this on your phone in the field test alongside your paper prototype.
What Each Is Good For
| AI simulation is good for… | Real users are irreplaceable for… |
|---|---|
| Finding obvious logical holes in your idea | Genuine emotional reactions you didn't expect |
| Practising your interview questions | Body language, hesitation, real confusion |
| Red-teaming before investors or advisors | Behavioural insights — what people do vs. say |
| Rapidly generating testable digital artefacts | The moment someone picks up your prototype and tries to use it |
| Synthesising patterns from interview notes | Discovering problems you didn't know existed |
"I noticed… I wonder… What if…"
For each person tested, capture three layers on Print 05:
I noticed: Observable facts only — what did the person actually say or do? No interpretation yet.
I wonder: What question does this raise? What don't you understand about their reaction?
What if: One quick "what if we changed X" idea triggered by this observation.
Ask Questions They Can't Lie About
Don't ask: "Would you use this?" / "Is this a good idea?" — people say yes to be polite.
Ask instead: "How do you currently deal with this?" / "Tell me about the last time this happened to you." / "What have you already tried?"
IDEO rule: If they say your idea is great, ask "What would make you NOT use it?" That's where real insight lives.
The Google Sprint Research Principle
Research cited in the Google Design Sprint shows that 5 user tests reveal ~85% of all usability issues. After 5 people you'll start hearing the same things — that's your signal. Three strong conversations beat twenty weak surveys.
Synthesise What You Found 💬
Back in the room. Turn raw observations — AI and human — into clear learning. Did your critical assumption hold up?
Find the Pattern
Brain dump (3 min): Everyone shares observations — facts only, no interpretation. What did people say? What did they do?
Theme hunt (5 min): Group similar observations on Print 06. Look for patterns across all people you tested with.
Compare AI vs. real (3 min): Did the AI simulation predict any of what you found? What did real humans reveal that AI missed?
The verdict (4 min): Was your critical assumption confirmed, contradicted, or unclear? Write: "We now know that [INSIGHT] because [EVIDENCE]."
Feed Your Notes to AI — Get Instant Patterns
Find Patterns in Interview Notes
Example: Campus Food App
Build: Paper prototype + AI-generated landing page showing "live queue times for campus canteens."
AI simulation found: AI persona said "I'd download it but probably forget to check it." Red team flagged habit formation as the biggest risk — not the technology.
Real test found: 3 of 4 students said they don't change where they eat — they eat where their friends are going. Queue length isn't the problem. Social coordination is.
Learning: Critical assumption CONTRADICTED. New insight: students plan lunch based on who they're eating with, not queue length.
Next loop: What if the solution helped groups coordinate where to eat together?
Pivot, Persist, or Zoom? 🔄
Based on what you learned — from AI and real humans — what should you do next? This decision separates good entrepreneurs from those who keep building the wrong thing.
Make a Deliberate Choice
Persist
Your assumption held up. Keep going — build more, test more, narrow your target user further.
Pivot
The problem is real but your solution needs to change. Adjust who you serve, what you build, or how you deliver value.
Zoom
Your idea is too broad. Focus on the one moment or user segment that resonated most — do that one thing brilliantly.
Decide Together in 10 Minutes
Each person writes silently: "I think we should [persist / pivot / zoom] because the evidence shows [X]." (90 seconds)
Share. If aligned — great. If not, the disagreement is itself a signal: what assumptions are you still split on?
Write your updated belief statement: "We now believe [UPDATED IDEA] will help [WHO] do [WHAT]."
Set up for Workshop 3 (MVP): What is the one cheapest test you could run before next session?