Summary  
This chapter teaches how to implement code that generates structured statements using template placeholders to enforce precise specification of key variables.

General domain of usage  
Early-stage startup idea validation

You've done the market scan. You know the landscape. Now comes the hardest part of early validation: turning a vague idea into a specific, testable statement.

Most founders skip this step. They go straight from "I think there's a gap" to "let me build a landing page." The problem is that a vague idea produces vague results – you talk to ten people, get ten different signals, and still don't know what you're actually validating.



## The Hypothesis Format

A good validation hypothesis has three parts:

**We believe that** [specific person] **experiences** [specific problem] **and would pay for** [specific solution] **because** [reason existing options fail them].

That's it. One sentence. But writing it forces you to be precise about four things you might have been fuzzy on.

| Part | What It Forces You to Nail Down |
|---|---|
| Specific person | Not "small businesses" – which ones, what size, what role |
| Specific problem | Not "operations are messy" – what breaks, when, how often |
| Specific solution | Not "software" – what does it actually do that fixes the problem |
| Why existing options fail | Forces you to know the competition before claiming a gap |

Maya's first draft might be: "Bakeries need better software." Her hypothesis after this lab should look something like: "We believe that independent bakery owners with 2–8 employees struggle to track custom cake orders and matching ingredient needs, and would pay $30–60/month for a tool that connects their order book to their pantry – because every existing option is either built for large restaurants or doesn't handle variable-ingredient custom orders."

The difference is everything. The second version tells you exactly who to call, what to ask them, and what a successful conversation looks like.



## Task

Bring your own idea – or use Maya's. Work with Claude to turn it into a tight validation hypothesis. Push back when Claude's version is too vague. Ask it to make the customer more specific, the problem sharper, the solution more concrete.

### Prompt to Try
><b>Help me write a validation hypothesis for my startup idea. Here's the rough concept: [describe your idea, or use Maya's: software for small bakeries and cafés to manage custom orders, ingredients, and staff shifts]. Ask me questions to sharpen it, then write the hypothesis in the format: "We believe that [specific person] experiences [specific problem] and would pay for [specific solution] because [reason existing options fail]."

Then push it:
><b>That customer description is still too broad. Make it more specific – what size operation, what role, what moment in their week does this problem actually hit them?

Master the skills needed to test a startup idea before building anything. You'll research markets, find early adopters, write cold outreach, analyze competitors, and run a two-week validation sprint — all with AI doing the heavy lifting on research and drafting.

Get hands-on experience turning a vague startup idea into a specific, testable hypothesis – backed by real market research and a clear picture of who your first customer actually is.

Discover how to find early adopters, write cold outreach that gets replies, and read competitor signals – all before writing a single line of code or spending a dollar on development.

Master the skills needed to move from promising conversations to real commitments – tracking your interviews, identifying your strongest leads, and building a sprint plan to close your first paying customer.