Content Principles

What This Book Is

The Real Startup Book is a reference manual of methods for testing business model assumptions. Think of it as a Wikipedia for business experiments: a structured, searchable collection of tools that founders, product managers, and innovation teams can reach for when they need to learn something specific about their market or product.

It is organized around a single question: What are you trying to learn?

The book’s own framework — the generative/evaluative and market/product matrix — is a way of organizing a toolbox so you can find the right tool. It is not a prescription for how to build a company.

What This Book Is Not

• Not a methodology. Unlike frameworks that prescribe a specific sequence of steps (do this, then this, then this), this book assumes you already have a question and need help choosing a method to answer it. It does not tell you which question to ask first.

• Not partisan. Lean Startup, Design Thinking, Agile, Design Sprints, Jobs to Be Done — these approaches overlap more than they differ. They come from slightly different perspectives and communities, but the underlying methods are largely the same. This book does not pick sides. A usability test is a usability test whether you call it “Lean UX” or “Human-Centered Design.”

• Not a textbook. There are no exercises, no certification, and no correct order to read the methods. Use the index. Find what you need. Go do it.

• Not a tool recommendation engine. Tools change constantly. The methods behind them do not. When we list tools, it is for practical convenience — not endorsement.

Editorial Principles

1. Methods over methodologies

Each page describes one method: what it is, when to use it, how to do it, what can go wrong, and where to learn more. We do not bundle methods into prescribed sequences. Readers combine methods in whatever order their situation demands.

2. Framework-agnostic, not framework-free

The book has its own organizational framework (the 2x2 matrix, BMC tagging, question-based indexing). That framework exists to help you navigate — the same way a library uses the Dewey Decimal System without claiming that books should be read in numerical order.

We reference specific frameworks (Business Model Canvas, Lean Canvas, Value Proposition Canvas, Jobs to Be Done) where they provide useful context. We do not claim any of them is the “right” one. If a method works equally well in a Design Sprint and a Lean Startup cycle, we say so.

3. Descriptive, not prescriptive

We describe how methods work and what they are good for. We avoid language that implies a method is always the right choice or always the wrong one. Context matters. A landing page smoke test is powerful for testing demand and useless for testing usability. We state that plainly.

“Use this when…” is better than “You should always…“

4. Honest about limitations

Every method has biases, failure modes, and situations where it does not apply. We document these alongside the how-to steps, not buried in footnotes. A method page that only describes the happy path is incomplete.

5. Practical over theoretical

If a concept cannot be tied to a concrete action a founder can take this week, it probably belongs in a reference or footnote rather than the main description. Favor step-by-step procedures, specific examples, and field-tested tips over abstract frameworks.

6. Accessible, not dumbed down

Every method in this book can be run by someone without specialist training — especially with AI tools available. When a method involves statistics, technical analysis, or domain expertise, frame it as “here’s what to ask for and what the answer means” rather than “here’s how to calculate it” or “hire a specialist.” Use inline tooltips for jargon, link to tools that handle the math, and always tell the reader what they can still learn from imperfect or small-sample data. The goal is a reader who feels capable, not overwhelmed.

7. Written for every organization type

The book is called “Real Startup Book,” but the methods work for any organization testing assumptions: corporate innovation teams, non-profits, government agencies, social enterprises, and established companies launching new products. Don’t write as if only venture-backed tech startups will read it. Use “team” or “organization” alongside “company.” Use “customer research” not “startup customer research.” AI prompts should use inclusive framing like “research methodology” rather than “startup research.”

8. Additive, not duplicative

A new method page earns its place by having a materially different procedure, different biases, or different interpretation from existing pages. If the only difference between two methods is what you call them, they belong on the same page with a note about alternate names — not on separate pages.

9. Sources and attribution

Claims about how methods work should be traceable. Link to the original source where possible. When a method was popularized by a specific person or book, credit them. When a “Field Tip” quote comes from a practitioner, attribute it.

10. Open and evolving

This book is open-source and never finished. New methods emerge. Old tools get replaced. Case studies accumulate. The goal is a living reference that stays current, not a static document that was accurate once.