30-Day MVP Sprint Planner

Week 1 · Days 1–7

Define the problem.
Write the spec.

Before any tool opens, the problem must be precise. Vague problems produce MVPs that test nothing. This week uses Claude and Gemini to turn a founder's brain dump into a build-ready specification document.

Brain dump — get everything out

No tool needed Day 1 · 30–60 min

↓

What to do

Record a voice note or write freely for 30–60 minutes. Do not organise. Do not edit. The goal is to get every thought, fear, assumption, and idea about the product out of your head and into a document.

Cover: the problem, who has it, what you have already tried, what you are afraid of getting wrong, and what success looks like in 30 days.

Checklist

Describe the problem in your own words — not as a pitch
Name the specific person who has this problem
Describe what they currently do instead of using your product
State your three biggest fears about this idea
Describe what Day 30 success looks like — in specific terms

Output

A raw transcript or document — 500 to 2,000 words. Unorganised. This is your input for Stage 2.

Problem clarification — Claude surfaces the assumptions

Claude Day 2 · 1–2 hours

↓

What to do

Paste your brain dump transcript into Claude. Use the prompt below. Review every output critically — Claude does not know your customer. You do. The value is in seeing your own assumptions listed back to you in one place.

Prompt 01 — Claude · Problem Clarification

You are a product strategist working with a non-technical founder. Here is a voice note transcript of their product idea. Your job is to: 1. Rewrite the problem statement in one precise sentence. No more than 25 words. No jargon. 2. List the 5 biggest assumptions hidden in this idea — things the founder is treating as true that have not been tested. Be specific. 3. Write the one question this MVP needs to answer. Not multiple questions. One. 4. Define what a YES looks like at the end of 30 days. Be specific — numbers, actions, thresholds. 5. Define what a NO looks like at the end of 30 days. Do not be encouraging. Do not add qualifications. Be precise and accurate. [PASTE TRANSCRIPT HERE]

Checklist

Problem statement is one sentence — precise, no jargon
5 assumptions listed — review each one honestly
The YES definition is specific and measurable
The NO definition is equally specific
The MVP question aligns with your hypothesis sentence

Output

A one-page clarity document: precise problem statement, 5 named assumptions, MVP question, and success/failure definitions. Input for Stage 3.

Spec generation — Gemini writes the build document

Gemini Days 3–4 · 2–3 hours

↓

What to do

Take Claude's output from Stage 2 and feed it to Gemini with the prompt below. Gemini's integration with Google Workspace means the spec lives in Google Docs immediately — shareable and editable without switching tools. Review every section. Add context only you have.

Prompt 02 — Gemini · MVP Spec Document

You are a senior product manager creating an MVP specification document. Using the problem statement, assumptions, and success criteria below, write a structured 2-page MVP spec. The document must include: PRODUCT OVERVIEW Two sentences maximum. What it is and who it is for. TARGET USER Specific description — role, situation, pain point. Not broad demographics. CORE USER JOURNEY Maximum 3 steps. What the user does from arrival to the moment of value. FEATURES IN SCOPE (MVP only) Maximum 5 features. Each with one sentence explaining why it is included. FEATURES EXPLICITLY OUT OF SCOPE List at least 5. This section is as important as what is in scope. SUCCESS METRICS 3 metrics only. Each must be measurable and time-bound. OPEN QUESTIONS Questions that must be answered before development begins. These are decisions you are not making in this document. Format as a clean Google Doc structure. Use plain language. A developer who has never met this founder should be able to read this document and know what to build. [PASTE CLAUDE OUTPUT FROM STAGE 2 HERE]

Checklist

User journey has maximum 3 steps
Features in scope: maximum 5, each with a reason
Out of scope list is longer than in scope list
Success metrics are specific numbers with timeframes
Open questions are listed — do not skip these

Output

A 2-page MVP spec in Google Docs. This is the document that governs everything built in Week 3. Nothing gets built that is not in this document.

Week 2 · Days 8–14

Design the screens.
Align before building.

Week 2 turns the spec into screens. Every decision made visually this week is a decision that does not become a conversation with a developer during build week. Google Stitch and Gemini close the gap between spec and build-ready document.

Mockups — Google Stitch screen by screen

Google Stitch Days 8–10 · 3–4 hours

↓

What to do

Open Google Stitch. For each step of your core user journey (maximum 3 steps from your spec), create a mockup screen. Describe what you want in plain language — Stitch generates the layout. You are not designing a beautiful product. You are mapping the journey visually so that navigation gaps become visible before anything is built.

Stitch Brief — Screen Description Template

Screen name: [e.g. "Homepage / Landing"] Purpose: [What this screen must communicate or enable] Primary action: [The one thing a user should do on this screen] Key information visible: [What the user needs to see to take the action] What happens after the action: [Next screen or outcome] Repeat for each screen in the user journey.

Checklist

One mockup per step in the user journey
Each screen has one primary action — not multiple
Navigation between screens is logical without explanation
Every feature in the spec appears on at least one screen
Export all screens as images for Stage 5

Output

Screen mockups exported as images — one per step in the user journey. These are the input for Stage 5 (design document).

Design document — Gemini describes every screen

Gemini Days 11–12 · 2–3 hours

↓

What to do

Upload the Stitch mockup images to Gemini. Use the prompt below. The output is a design specification document — the handoff document that a developer, no-code operator, or Claude (for vibe coding) can follow without asking questions.

Prompt 03 — Gemini · Design Specification Document

You are a UX designer creating a design specification document from mockup screens. Here are the mockup screens for an MVP. For each screen, provide: SCREEN NAME AND PURPOSE One sentence describing what this screen does. KEY UI ELEMENTS List every visible element — buttons, fields, text, images. PRIMARY USER ACTION The one thing the user must do on this screen. WHAT HAPPENS NEXT The screen or outcome that follows the primary action. EDGE CASES What does the screen show when: there is no data, there is an error, the user is new, the user has completed the action before? COPY NOTES Suggested text for buttons, labels, and any instructional text visible on screen. Format as a build-ready Google Doc. A developer or no-code operator with no other context should be able to build from this document alone. [ATTACH MOCKUP IMAGES HERE]

Checklist

Every screen from Stitch has a corresponding section
Edge cases are documented for every screen
Copy notes exist for all visible text elements
Document is shareable in Google Docs
A stranger could build from this document without asking questions

Output

A build-ready design specification document in Google Docs. This is the primary input for Week 3 (build). Nothing in Week 3 should require a decision that is not already answered here.

Week 3 · Days 15–21

Build the first
working version.

Week 3 is build week. The spec and design document from Weeks 1 and 2 mean that every decision is already made. You are executing against a clear brief — not designing and building simultaneously. Claude handles vibe coding. Google Scripts handles document automation.

Vibe coding — Claude builds the first working version

Claude Days 15–18 · iterative

↓

What to do

Paste your design specification document into Claude. Use the prompt below as your starting point. Vibe coding is iterative — you describe what you want, Claude writes the code, you test it in a browser, you describe what needs to change. No syntax knowledge required. Each iteration takes 5–15 minutes. Build one screen at a time, starting with the core user journey.

Prompt 04 — Claude · Vibe Coding Starter

You are a developer building an MVP for a non-technical founder. Here is the design specification document for the product. Build the first screen of the core user journey as a working HTML file. Requirements: - Clean, functional UI — not polished, not styled heavily - Mobile-responsive - Every element in the spec must be present - Every edge case in the spec must be handled - Include placeholder text where real copy will go - No external dependencies unless absolutely necessary After I test this, I will describe what needs to change. We will iterate until the screen matches the spec. [PASTE DESIGN SPEC SECTION FOR THIS SCREEN]

Prompt 05 — Claude · Iteration Prompt

Here is what I tested and what needs to change: [Describe specifically what is wrong or missing. Be precise.] Keep everything else the same. Only change what I have described. After this change, I will test again and describe the next iteration.

Prompt 06 — Google Scripts · Document Automation

Write a Google Apps Script that does the following: [Describe exactly what the script needs to do — e.g. "When a form is submitted, add a row to a Google Sheet and send a confirmation email to the submitter."] The script should: - Run automatically when [trigger event] - Access [specific Google Workspace tools needed] - Handle errors gracefully and log them - Be readable and commented so I can edit it later Include step-by-step instructions for how to install and test this script in Google Workspace.

Checklist

Core user journey (3 steps) is functional end to end
Every feature in scope appears and works
Edge cases from the spec are handled
Product works on mobile without zooming
A stranger can complete the core journey without guidance

Output

A working MVP — functional, mobile-responsive, covering the full core user journey. Ready for the pre-launch validation test in Stage 7.

Week 4 · Days 22–30

Validate. Read the signal.
Decide what to build next.

Week 4 is not launch week. It is learning week. The goal is to put the MVP in front of real users who do not know you, collect real behaviour data, and use Claude to find the pattern in what they did — not what they said.

Pre-launch validation — Claude plays the user

Claude Days 22–23 · 2–3 hours

↓

What to do

Before any real user sees the product, run a simulated user test with Claude. This is not a quality check — it is a gap-finding exercise. Every gap Claude surfaces as a simulated user is a gap a real user will hit silently by leaving. Fix what you can before launch day.

Prompt 07 — Claude · Simulated User Test

You are playing the role of a [DESCRIBE YOUR SPECIFIC TARGET USER — role, situation, problem they have, level of tech comfort]. You have just discovered this product for the first time. You have no prior knowledge of it and no relationship with the founder. Here is the product description and the user journey: [PASTE YOUR SPEC'S CORE USER JOURNEY] Walk through the product step by step. At each step, tell me: 1. What are you trying to do? 2. What are you confused by or unsure about? 3. What are you looking for that is not there? 4. At what point do you feel friction? 5. At what point would you stop using the product — and why? Be honest. Be critical. Do not be encouraging. Your job is to find every gap before a real user does.

Checklist

Every gap Claude identified has been addressed or consciously accepted
5 real people (not friends/family) have tested the product
You watched them test — you did not explain or guide
You noted where they hesitated, not just what they said
Product is ready for broader launch

Output

A list of gaps found, decisions made, and a product that has been tested by at least 5 real users before launch.

Pattern analysis — Claude reads the early user data

Claude Day 30 · 1–2 hours

↓

What to do

On Day 30, collect everything you have: form submissions, user sessions, feedback notes, support messages, anything users generated. Feed it to Claude for pattern analysis. The goal is one decision: was the hypothesis proved or disproved? What do you build next?

Prompt 08 — Claude · Pattern Analysis

You are a product analyst reviewing early MVP data. Here is the hypothesis this MVP was built to test: [PASTE YOUR HYPOTHESIS SENTENCE] Here is the data collected in the first 30 days: [PASTE: form submissions / user behaviour data / feedback notes / support messages / any user-generated content] Analyse the data and tell me: 1. Was the hypothesis proved or disproved? Be direct. 2. What did users actually do — versus what the hypothesis predicted they would do? 3. What is the strongest positive signal in the data? 4. What is the strongest negative signal? 5. What is the one thing users wanted that the MVP did not give them? 6. Based on this data, what should be built next — and what should be cut? Do not be diplomatic. This data is the most valuable thing the founder has. Interpret it accurately.

Prompt 09 — Claude · Launch Messaging

You are writing launch messaging for an MVP. Product: [DESCRIBE PRODUCT IN ONE SENTENCE] Target user: [SPECIFIC DESCRIPTION] Core outcome: [WHAT THE USER GETS] Unique mechanism: [HOW IT DELIVERS THE OUTCOME] Write: 1. A 10-word headline for the landing page 2. A 2-sentence subheadline 3. A 3-bullet value proposition (outcome-focused, not feature-focused) 4. A CTA button label 5. A 50-word description for WhatsApp / LinkedIn outreach to first users All copy must be in plain language. No jargon. No startup vocabulary. Write as if explaining to someone who has never heard of this product.

Day 30 checklist

Hypothesis is clearly proved or disproved — no ambiguity
The strongest signal (positive or negative) is named
The one thing users wanted that was missing is identified
Next build decision is made: what to add, what to cut
Second hypothesis written for next 30-day cycle

Output

A clear answer to the hypothesis. A decision on what to build next. A new hypothesis for the next 30-day cycle. This is the end of Sprint 1 — and the beginning of Sprint 2.