Tone of Voice

The Real Startup Book is a reference manual, not a blog post. The voice should feel like a knowledgeable colleague explaining a tool at a whiteboard — clear, direct, and practical. Not academic. Not salesy. Not preachy.

General Principles

Be direct. Say what the method does, when to use it, and what to watch out for. Don’t hedge with “it could potentially perhaps be useful in some scenarios.”

Be neutral. Present methods on their merits. Don’t oversell (“this is the most powerful technique”) or undersell (“this is just a quick hack”). Let readers judge fit for their situation.

Be concrete. Use specific examples over abstract principles. “A shoe company testing whether customers understand ‘plantar fasciitis’” is better than “a company testing messaging comprehension.”

Respect the reader’s intelligence. The audience includes first-time founders, experienced product managers, MBA students, and corporate innovation teams. Write for a smart generalist. Don’t explain what a startup is. Don’t assume everyone knows what a Type II error is — but a parenthetical will do, not a full paragraph.

Use “we” sparingly. “We” is appropriate in framing chapters (preface, index) where the book speaks collectively. In method pages, prefer second person (“you”) or neutral constructions (“the team,” “the interviewer”) to keep the register encyclopedic.

Voice by Section

The book’s voice is not uniform. Different sections serve different purposes and call for different registers.

Preface and Index chapters

Register: Conversational, coach-like. This is the part of the book that has the most personality. It’s where the “why” behind the book lives, and it should feel like a real person explaining their thinking. First person plural (“we”) is fine here.

“Our job as entrepreneurs is to first ask the right questions, and only then can we find the right answers.”

In Brief

Register: Concise, plain-language summary. One to two paragraphs. Lead with what the method IS and what output it produces, then its most common use. Written for someone scanning to decide if this is the right method. No jargon without immediate explanation.

Good: “Closed-ended surveys ask participants to choose between fixed, multi-choice answers such as yes/no or A/B/C/D.”

Weak: “Closed-ended surveys help you converge on what’s relevant in great detail, particularly to customers or prospects.”

Helps Answer

Register: Functional. Plain-language questions a founder would actually ask — not academic phrasing. Short phrases, no prose.

Good: “Which of these options is the priority?”

Weak: “What is the breakdown of client concerns/problems/preferences in terms of percent of all clients in a segment?”

Tags

Register: Functional. Simple, understandable labels. Must be clear to a non-technical user. Always include the RSB matrix dimensions (Generative/Evaluative + Market/Product).

Business Model Canvas / Time Commitment / Resources

Register: Factual and brief. These are metadata sections rendered with visual indicators. One to two sentences of plain description. No filler.

Common Use Case

Register: Concrete and second-person. Describe the entrepreneurial stage and knowledge gap — not a specific industry, product, or fake scenario. The reader should think “that’s my situation” or “not what I need” based on where they are in their journey, not based on whether they happen to be in the same industry as the example.

Good: “You’ve talked to a number of customers and they’ve expressed four distinct pain points you could build a business around. To prioritize which problem to solve, you need to know how big the market for each is.”

Good: “You have identified a pain point for your prospective user, but you aren’t sure about their real behavior and workflows. You visit them in person, watch them act in real situations, and discover behaviors & workarounds they never mentioned in interviews.”

Weak (too abstract): “This method is useful for founders who want to prioritize between multiple possible directions.”

Weak (industry-specific fake example): “You are designing a new meal kit service and want to understand how families decide what to eat each week.” — This makes the reader think the method is only for food/consumer businesses.

Description

Register: Neutral and explanatory. What the method is and what it involves. Include concrete examples (show actual question formats, not just describe them). Keep it tight — this section should not repeat the How-to steps.

How to (Prep / Execution / Analysis)

Register: Pragmatic and neutral. This is the reference-manual core of each page. Clarity over style. Numbered steps for procedures. Imperative mood. No motivational language.

Write as if you are documenting a process for someone who has never done it before but is competent enough to follow clear instructions. Assume they will actually go do this, not just read about it.

Avoid:

• “Simply do X” (if it were simple, they wouldn’t need instructions)
• “Obviously…” (it isn’t, or we wouldn’t be explaining it)
• “Best practice is…” (says who? cite a source or describe a tradeoff instead)

Prefer:

• “Do X. This produces Y, which you will need for step 3.”
• “If the sample size is below 30, the results may not be statistically meaningful.”

Biases & Tips

Register: Direct and actionable. Each entry pairs a named bias with a concrete mitigation. Don’t just list bias names — explain the mechanism and what to do about it in 1-2 sentences.

Good: “Social desirability bias — Respondents avoid admitting to unsavory behavior, particularly if results aren’t confidential. Keep surveys anonymous when possible.”

Weak: “Social desirability bias: the tendency to give socially acceptable answers.”

AI Prompt

Register: Functional and instructional. These are copy-pasteable prompts the reader will feed to an AI agent. Write them in second person addressing the AI (“You are an expert in…”). Include bracketed placeholders for the reader to fill in. The prompt should specifically guide the AI to check for biases and common mistakes relevant to this method.

Frame prompts around decisions, not analysis. The AI’s job is to help the reader make a call — not to produce a textbook report. Open with the decision context: “Your job is to help me make a decision based on this data.” Tell the AI to be honest about uncertainty and to distinguish between findings strong enough to act on and those that need more data.

Include a constraints field. Readers operate under real-world limits — small sample sizes, restricted access to respondents, time pressure. Add a [CONSTRAINTS] placeholder so the AI can tailor its advice. Example: “My constraints are: [e.g. ‘I can only reach ~50 people,’ ‘respondents will take this at a trade show booth’].”

Guide for small samples. Many readers won’t have textbook-sized datasets. Prompts should instruct the AI to use Bayesian reasoning when frequentist methods won’t work, and to give directional guidance rather than refusing to answer. “Where sample sizes are too small for statistical significance, estimate the probability that the observed pattern is real.”

No startup-exclusive language. Don’t write “startup customer research” or “founder-focused.” The book is used by product managers, corporate innovation teams, non-profits, and government agencies — not just startups. Use inclusive framing: “survey design and research methodology,” “business customer research,” etc.

Next Steps

Register: Brief and cross-referential. 2-4 bullets suggesting next methods to try depending on results. This keeps the reader inside the reference manual. Link to other method pages.

Case Studies

Register: Factual and brief. What the company did, what method they used, what happened. No editorializing. Let the reader draw conclusions.

Case studies must be actual examples of someone using this method to solve a real business challenge. Articles about how to do the method well belong in References, not here.

Tools

Register: Functional listing. Tool name, link, and a brief phrase describing what it does in the context of this method. No reviews. No “we love this tool.”

References

Register: Academic/bibliographic. Standard citation format. How-to articles and methodology guides go here.

Accessibility and Empowerment

The reader should finish every method page believing they can do this — not that it requires a specialist. Two rules support this:

Explain jargon inline. When a technical term appears (cross-tabulation, statistical significance, p-value), use a linked tooltip on first use. Format: [term](url "one-sentence definition"). Link to a reputable source (Wikipedia is fine). The tooltip gives immediate understanding; the link gives depth for those who want it.

Frame complex analysis as AI-assisted. Don’t write “run a chi-square test” as if the reader should know how. Write “ask an AI to run a chi-square test” and explain when to ask for it and what the result means. The reader’s job is to know which question to ask — the AI handles the math. This keeps the content accessible without dumbing it down.

Link to Kromatic tools where relevant. When a step involves calculation (sample size, experiment design), link to the appropriate tool at kromatic.com rather than describing the math. Example: “Use a sample size calculator to get a precise number.”

Things to Avoid Everywhere

• Absolutes. “You must,” “always,” “never,” “the only way.” Replace with “typically,” “in most cases,” or just describe the tradeoff.
• Methodology tribalism. Don’t position Lean Startup against Design Thinking, or Agile against Waterfall. If a method has roots in multiple traditions, acknowledge them without ranking.
• Hype. Especially around AI. “AI can help with X” is fine. “AI is revolutionizing X” is not — let the reader decide that.
• Marketing language. “Game-changer,” “disruptive,” “best-in-class,” “cutting-edge.” These mean nothing in a reference manual.
• Condescension. Don’t tell founders they’re probably doing it wrong. Describe what works and what doesn’t, and let them compare against their own practice.
• Intimidation. Don’t present statistical methods, technical analysis, or specialist knowledge as barriers. The reader may not have formal training — but with AI tools and clear instructions, they can run rigorous research. Frame complexity as “here’s what to ask for” not “here’s what you need to learn.”
• Startup-exclusive language. The book is titled “Real Startup Book” but its audience includes corporate PMs, innovation teams, non-profits, and government agencies. Don’t write as if only tech startup founders will read it. Avoid “startup customer research” in favor of “customer research.” Use “team” or “organization” alongside “company.”
• Filler. “It’s important to note that…” “It goes without saying that…” “At the end of the day…” Cut these. Start with the point.