Editorial Style Guide

This guide covers the structural and formatting conventions used across The Real Startup Book. Follow these when writing new method pages, editing existing ones, or contributing chapters.

Above the Fold

Every method page is designed so that a reader can decide whether to keep reading without scrolling past the In Brief section. Tags, a one-paragraph summary, the use case, the questions it answers, the BMC blocks, time commitment, and cost are all visible at the top of the page. If the reader’s situation matches, they scroll down. If not, they move on.

Page Types

The Real Startup Book has four page types. Each follows its own template; the sections below detail each. Don’t mix templates — a method page should not get a “Choosing the Right” hub section; a parent overview should not get Prep / Execution / Analysis subsections; a prose chapter should not have Tags or BMC. Mixing creates pages that match no template, which is what makes the book inconsistent.

Method Page Structure

Every method page follows the same structure. This consistency is what makes the book usable as a reference — readers learn where to look for what they need.

A full template with inline notes is available in appendix/method-template.md (draft, not published).

Required Sections (in order)

# Title
### Tags
![Image]
## In Brief
  ### Common Use Case
  ### Helps Answer
  ### Business Model Canvas
  ### Time Commitment
  ### Resources
## Description
## How to
  ### Prep
    #### AI Prompt
  ### Execution
  ### Analysis
    #### Biases & Tips
    #### AI Prompt
  ### Next Steps
## Case Studies
## Tools
## References

Writing About AI

The Real Startup Book treats AI as a baseline assumption, not a special topic. Every method page should reflect current AI-augmented practice throughout — there is no separate AI section because AI is part of how every method is run today.

When AI changes how a method works, integrate the change into the existing structure. Use this map:

Example. A page about Contextual Inquiry should not have an “AI-Era Update” appendix. Instead: AI transcription tools (Otter.ai, Dovetail, Looppanel) belong in ## Tools; their impact on debrief time belongs in ### Time Commitment; the warning that AI cannot replace physical presence belongs in ## Description; an AI prompt to design the observation protocol belongs as #### AI Prompt under ### Prep. The reader sees AI integrated into the workflow, not bolted on.

Sections That Should Not Exist

No standalone “AI-Era Update” section. Per the Writing About AI guidance above, AI content is integrated throughout the page — never appended as a separate block. Do not create a ## AI-Era Update (or equivalent) heading on a method page. If you encounter one on an existing page, integrate its content into the appropriate sections per the map above, then delete the heading.

Section-by-Section Notes

Frontmatter fields:

### Tags: Placed at the very top of the page, above the image and In Brief. Simple, understandable labels. Always include the RSB matrix dimensions:

• Data type: Quantitative, Qualitative
• Research type: Generative, Evaluative
• Domain: Market, Product
• Business type (if applicable): B2B, B2C, B2G, 2-sided market

## In Brief: Lead with what the method IS and what output it produces. Write for someone scanning — they should know in 30 seconds whether this is the right method. No jargon without explanation. Everything in this section and its subsections should fit “above the fold.”

### Common Use Case: A concrete, second-person scenario (“You’ve talked to customers and they’ve expressed four distinct pain points…”). Describes the entrepreneurial stage and knowledge gap — not a specific industry, product type, or problem domain. The reader should immediately know if this method fits their situation regardless of what they are building. Do NOT invent fake examples tied to a particular vertical (e.g., “meal kit service,” “project management tool,” “freelance invoicing app”) — these make the reader think the method is only for that industry. Rendered in the main column of the In Brief layout.

### Helps Answer: Plain-language questions a founder would actually ask. Start each with a question word (Which, What, How, Is). Avoid academic phrasing. Rendered in the main column.

### Business Model Canvas: List the BMC blocks this method tests. Rendered as a compact SVG diagram in the sidebar card with highlighted blocks and hover tooltips.

### Time Commitment: Rendered as iconographic time indicators (stopwatch, calendar-day, calendar-month) in the sidebar card. The text appears as a tooltip on hover. Give a realistic range in 1-2 sentences.

### Resources: Rendered as iconographic cost indicators (coin, dollar-bill, money-bag) in the sidebar card. The text appears as a tooltip on hover. What you need — money, tools, people. 1-2 sentences. Distinguish method-direct cost from participant compensation. “No financial cost” usually means “no fee for the method itself” but obscures the often-larger cost of compensating participants for their time. If the method involves customers or research subjects, name participant compensation as a separate consideration (“Participants may or may not require payment for their time, typically $25-100 per session for B2C consumers and $100-300 for B2B specialists”).

## Description: What the method is and what it involves. Include concrete examples (show actual question formats, actual interfaces, actual outputs). Keep it tight — don’t repeat the How-to steps.

## How to — Prep: Numbered steps, imperative mood (“Define your learning goal” not “You should define…”). Each step is a concrete action. Prep includes everything you decide before you start collecting data: defining the goal, designing the instrument, choosing the distribution channel, setting target sample sizes, and piloting. If it’s a decision that shapes what you’ll collect, it’s prep.

#### AI Prompt: A copy-pasteable prompt for using AI to help with this phase. Rendered as a popover button (sparkles icon) right-aligned on the parent heading row (Prep or Analysis). Include [BRACKETED PLACEHOLDERS] for the reader to fill in — including a [CONSTRAINTS] field for real-world limits (sample size, access, timeline). Frame the AI’s role around helping make decisions, not producing academic reports. Guide the AI to check for biases relevant to this method. See the Tone of Voice guide’s AI Prompt section for full guidance.

## How to — Execution: What you do once prep is complete. When a method can be run through different channels (online, in-person, phone, etc.), provide separate guidance for each — the biases and practical tips differ. Include anti-bias instructions for the person running the method (e.g., “don’t react to responses,” “read questions verbatim”).

## How to — Analysis: How to interpret results. Numbered steps of analytical actions. Frame statistical methods as AI-assisted: tell the reader when to ask for a specific test and what the result means, not how to calculate it. Include guidance for small sample sizes — the reader should know what they can still learn from limited data, not just be told they need more.

#### Biases & Tips: Each entry pairs a named bias with an actionable tip. Bias names render as yellow pill badges in a two-column layout. Format the section as a bulleted list — each item begins with - **Bias name** — explanation and mitigation. The bullet and the bold-name pattern are required for the remark plugin to detect each entry; plain paragraphs are skipped and won’t render as pills. The em-dash separator is stripped at render time, so - **Bias name** explanation (no separator) also works. Reference rendering: both the Closed-End Survey page and the Card Sorting - Pain Points page show the canonical visual treatment.

Mitigations that MUST precede the main run go in Setup, not here. If a step is a procedural prerequisite — pilot the deck, validate the script, recruit a representative sample — it belongs as a numbered step in ### Prep, not as a Common Pitfalls bullet. Common Pitfalls is for biases the reader watches for during and after execution. A reader who sees a “must-do-first” item in Common Pitfalls has already missed the window. Use named, established bias terminology (Wikipedia / Kahneman lineage) rather than ad-hoc names (“set composition bias” → “coverage bias”; “order effects” → “anchoring and order effects” with the mechanism named).

### Next Steps: 2-4 bullets with arrow icons. Cross-reference other methods in the book depending on what the results show. Prefer forward-experiments to parallel methods. Next Steps should suggest what the reader does with what they learned — typically the next experiment in the validation pipeline (a generative method’s Next Steps point to evaluative experiments; an evaluative method’s Next Steps point to scaling, segmentation, or follow-up validation). Parallel or sibling methods (e.g., “for the feature variant, see Card Sorting - Features”) belong in the page’s related: frontmatter and the inline cross-reference at the top of ## In Brief, not in Next Steps.

## Case Studies: Actual examples of someone using this method to solve a business challenge. NOT articles about how to do the method — those go in References. Format: **Company** — description. [Read more](url). Rendered as expandable items with briefcase icons.

## Tools: Format as a linked list with brief context:

- [Tool Name](https://url) — what it does for this specific method

Note when a tool has been sunset or acquired.

## References: Books, articles, papers, how-to guides. Format:

- [Author/Title — Source](url)

Heading Levels

• # — Page title only. One per page.
• ## — Major sections (In Brief, Description, How to, Case Studies, Tools, References)
• ### — Tags (at top), subsections within In Brief (Common Use Case, Helps Answer, BMC, Time, Resources), and within How to (Prep, Execution, Analysis, Next Steps)
• #### — AI Prompt, Biases & Tips

Visual Features

Several heading patterns trigger automatic visual rendering via remark plugins:

These plugins transform the markdown at build time. Writers just use the heading patterns — no special syntax needed.

Formatting Conventions

Bold for emphasis of key terms on first use in a section. Don’t bold the same term repeatedly.

Italics for book titles, framework names on first mention, and terms being defined.

Code formatting only for actual code, URLs in running text, or frontmatter field names.

Lists: Use bullet lists for unordered items (tags, tools, tips). Use numbered lists for sequential procedures (how-to steps). Don’t number items that have no meaningful order.

Images: Each method page has a header illustration. Format:

![Alt text description](/assets/book/filename.png)

Write meaningful alt text that describes the illustration content.

Cross-references

When one method page references another, link to it by its slug:

See [Customer Discovery Interviews](/3-generative-market-research/customer-discovery-interviews) for a generative alternative.

Note: the site’s base path (/realstartupbook/) is added automatically at build time. Do not include it in markdown links.

Internal-link affordance

Every markdown link whose href starts with / (a link to another page in this book) renders automatically as a blue chip with a page icon. This is the same affordance used for parent-page method bullets — readers learn it once and recognize it everywhere. Authors don’t need to do anything special; write internal links the normal way and the styling kicks in.

The chip applies to body content inside .book-content only — sidebar navigation has its own consistent style. External links (https://, mailto:, #anchor) and the tag row at the top of method pages (.method-tag) are intentionally NOT styled as chips so they remain visually distinct.

Two pill sizes exist for different contexts:

• Block pill (.method-pill, fixed width) — used inside parent-page Choosing-the-Right family lists, where every entry is [pill] — description. Generated by the remark plugin from the **[link]** strong-with-link pattern.
• Inline chip (default) — applied automatically by CSS to every other internal link, sized to the link text. Flows in prose, lists, and tables without breaking layout.

When to Create a New Method Page

A new method earns its own page when it differs from existing methods in at least two of these three dimensions:

1. Procedure — the steps you follow are materially different
2. Biases — the failure modes and distortions are different
3. Interpretation — what the results tell you is different

If a “new method” shares the same procedure, biases, and interpretation as an existing one but has a different name, it belongs as a note or alias on the existing page — not a new page.

Method vs. Technique vs. Scope Variation

Not everything that looks like a method deserves its own page. Distinguish between:

• Method — what you do with customers. Has its own procedure, biases, and interpretation. Gets its own page.
• Execution technique — how you deliver or instrument a method (e.g., link tracking, A/B variant serving). Does not get its own page; mention it within the method it supports.
• Scope variation — a fidelity or scale variant of an existing method (e.g., clickable prototype vs. paper prototype vs. life-sized prototype). Gets a child page under a parent grouping, not a standalone top-level entry.

Taxonomy Classification Rules

Value Proposition Test (VPT): Any method where you present a value proposition and ask the participant to give you something — money, time, data, or actions — in return. The signal is commitment to a promise, not interaction with a working product. Examples: landing page, mock sale, crowdfunding, online ad, flyer, pop-up store, referral program. Crowdfunding tests demand for a promise, not a product — it belongs in Evaluative Market Experiments, not Product Experiment.

Prioritization Games: Structured exercises that force participants to make trade-offs, revealing their true priorities. The family includes card sorting (features), buy a feature, product box, and speed boat. Group these under a parent “Prioritization Games” page in Generative Product Research.

Product Prototyping: Methods that put something in front of the customer to observe their interaction. Different fidelity levels (paper, clickable, 3D print, life-sized, mash-up, single feature MVP) are scope variations of the same core method. Group under a parent “Product Prototyping” page in Evaluative Product Experiments.

Data Mining: Methods that extract insights from existing data sources rather than generating new data through customer interaction. Sub-methods (customer support analysis, search trend analysis, web traffic analysis) are grouped under a parent “Data Mining” page in Generative Market Research.

Aliases

Use the aliases frontmatter field to list alternate names practitioners may know a method by. Aliases must be unique across the entire collection — no two pages may share the same alias, and no alias may duplicate another page’s title. Aliases should be surfaced in the UI (e.g., “Also known as” line) and indexed for search.

Framework and Methodology References

When referencing frameworks (Business Model Canvas, Lean Canvas, Value Proposition Canvas, JTBD, etc.):

• Name the framework and its creator on first reference in a page
• Don’t argue for or against any framework
• If a method is associated with a specific framework (e.g., “Problem Interview” comes from Ash Maurya’s Running Lean), note the origin but present the method in framework-neutral terms
• Use BMC block names in frontmatter for navigational tagging — this is a practical indexing choice, not an endorsement of BMC over alternatives

AI Voice Check

Run a voice pass on every method page before it ships. Drafts that came through an LLM (whether for first pass, expansion, or polish) tend to leave fingerprints. Scan for and remove:

• Filler verbs and metaphors. “Delve into”, “navigate the complexities of”, “unpack”, “tapestry”, “landscape”, “in the realm of”, “at the intersection of”. Cut them or replace with the concrete verb the sentence actually needs.
• Academic openers. “It’s important to note that”, “It’s worth mentioning that”, “One thing to keep in mind is”. Drop the opener and start with the point.
• Hedge stacking. “You may want to consider perhaps”, “it could potentially be useful to maybe”. Pick one hedge or none.
• Em-dash padding. Em-dashes used as a stylistic substitute for a comma or colon mid-sentence — especially two or three per paragraph. Use an em-dash when the aside genuinely interrupts the sentence; otherwise use a comma, a colon, or a period.
• Parallel-structure bullet lists. Bullet lists where every item starts with the same verb tense or the same sentence shape (“Identify the…”, “Define the…”, “Determine the…”). Vary the structure or collapse the list into prose if the items don’t actually have a shared shape.
• Smart-sounding throat-clearing. “In today’s fast-paced world”, “Now more than ever”, “In an era of”. Cut.

The book’s voice is direct, second-person, and instructional. If a sentence sounds like it was written for a LinkedIn post, rewrite it.

Calibration of absolute claims

LLM drafts routinely overreach with absolutes. The voice check should also catch and downgrade unhedged claims about how methods consistently, always, or reliably produce a specific outcome. Replace with calibrated language unless the source explicitly supports the absolute.

• “consistently surfaces…” → “often surfaces…” or “tends to surface…”
• “is critical” / “is essential” → “is a common practice” or “is recommended”
• “are among the most valuable” → “are sometimes the most valuable”
• “reveals true priorities” → “elicits stated priorities under a forced-choice constraint”
• “always produces…” → “typically produces…”

The corrected language is more honest and more useful: a reader trying to decide whether a method fits their situation needs to know that some sessions yield rich data and some don’t, not that the method “consistently” works. Calibration is a category of accuracy.

Fact-Check Rigor

Every claim on a method page must hold up. Before publishing or re-publishing a page:

• Case studies must be real, current, and on-method. Each case study refers to an actual, still-operating company or product (or, if the company is defunct, that’s stated explicitly and the lesson still holds). The case must illustrate the specific method the page describes, not an adjacent technique. Card sorting for problem prioritization is not the same method as card sorting for information architecture; surveys are not interviews; A/B testing is not Wizard of Oz. A case that uses an adjacent technique muddies the page’s primary teaching even when the company is real. Stub or hypothetical examples do not belong in Case Studies — move them to Description if they’re illustrative, or cut them.
• Run a basic web search before declaring “no case studies available.” Before leaving a **TKTK** placeholder, search for the page’s specific method name (not the parent technique) — first 1-2 pages of results — for founder writeups, product-team retrospectives, and primary-source case studies. Search queries should name the variant precisely (e.g., "problem prioritization" "stack ranking" founder case study, not "card sorting" case study). If the first two pages of results turn up nothing on-method, then a TKTK is appropriate; if results turn up adjacent-technique cases, those go in Description as illustrative comparisons, not in Case Studies.
• Tools list coverage minimums. A Tools section should span the realistic option space, not just the SaaS surface area: at minimum (1) a physical / scrappy option for in-person or solo use, (2) one or two collaborative whiteboards for remote use, (3) one specialized / dedicated platform for the method when one exists. Listing only enterprise SaaS tools tells the reader the method requires a budget that it doesn’t.
• Source links must resolve. Every URL in References, Tools, and Case Studies must still load. If a tool has been sunset or acquired, note it inline. If a source has moved, update the link. Dead links get fixed or removed, not left in.
• Framing must match the source. When citing a book, paper, or article, the page’s framing must accurately represent that source’s actual argument. Don’t paraphrase a source into a position it didn’t take.
• Statistical and quote claims need a source. Every “X% of startups…”, every named-person quote, every cited study, and every method-specific sample-size guidance (“5-10 customers”, “200 responses”) must have a resolvable reference, or it gets framed as a rule of thumb. No unsourced statistics. No invented attributions.
• Method lineage credits. When a technique has a documented inventor or a named lineage in research methodology, credit it inline at first use. The “$100 test” / “Buy a Feature” goes back to Luke Hohmann’s Innovation Games and constant-sum scaling in marketing research; affinity mapping goes back to Jiro Kawakita’s KJ method. Don’t write technique descriptions as if invented for this page.

If a claim cannot be sourced, the claim leaves the page. Better a tighter page than a confidently wrong one.

Parent Method Page Structure

A parent method page is the orientation hub for a family of related methods. Its job is to help the reader understand what the family is and pick the right child method — not to teach a procedure. The procedure lives on each child page.

Examples: Value Proposition Test (17 children, grouped by commitment type), Data Mining (3 children, single group), Prioritization Games (4 children, single group), Product Prototyping (6 children, grouped by fidelity).

Required Sections (in order)

# Title
### Tags
![Image]
## In Brief
  ### Common Use Case
  ### Helps Answer
  ### Business Model Canvas
  ### Time Commitment
  ### Resources
## Description
## Choosing the Right [Family Name]
  #### AI Prompt
  ### [Group Label]
    - **[Method Name](/path)** — Sentence describing the method. Best used [when / to / for] [situation].
    - ...

Sections that do NOT belong on a parent page

Parent overview pages are explicitly exempt from the procedural method-page sections:

• No ## How to — the procedure lives on each child page.
• No ### Prep / ### Execution / ### Analysis / ### Next Steps — same reason.
• No #### Biases & Tips — biases are method-specific; they belong on each child.
• No ## Case Studies — a case study belongs on the specific child that ran the method, not on the family overview. (A Landing Page case study goes on landing-page-smoke-test, not on the VPT parent.)
• No ## References — for the same reason: references are tied to specific methods.
• No ## Tools — tool selection is implementation detail and belongs on each child. Tools that apply to multiple children should be listed on each child where they apply, not promoted to the parent. (E.g. Figma applies to several Product Prototyping children — list it on each child it fits, not on the parent.)

The Choosing-the-Right section

The hub section that replaces the procedural body. It has three parts:

1. Intro paragraph — a one-line directive about how to pick (e.g. “Pick the lowest-commitment method that produces evidence strong enough for your next decision.”).
2. #### AI Prompt — a tailored selection prompt that asks the reader for their situation (constraints, budget, audience) and recommends 1–2 methods. Same [BRACKETED PLACEHOLDERS] + [CONSTRAINTS] shape as method-page AI Prompts.
3. One or more ### Group Label H3s, each followed by a bulleted method list.

For families with a strong organizing axis (commitment level for VPT, fidelity for Product Prototyping), use multiple H3 groups. For small families (≤4 children), a single H3 group is enough. Common single-group labels: ### Available Data Sources, ### Available Games, ### Methods.

The method-pill bullet pattern

Each bullet has the same shape:

- **[Method Name](/path)** — Sentence describing the method in plain language. Best used [when / to / for / in] [a specific situation].

The **[link](url)** strong-with-link prefix is what triggers the blue method-pill rendering (see Visual Features). Two rules for the prose:

• Plain language in the first sentence. Describe what the method does without jargon (avoid “resonance”, “category demand”, “commitment proxy”, and similar terms a non-practitioner wouldn’t recognize).
• Clear situation in the second sentence. Open with Best used so the reader can scan for the match. Two flowing sentences — do not use a separated **Best when:** bold label, which produces a four-column visual rhythm that reads as fragments rather than guidance.

Section Page Structure

A section page is the landing page for a numbered section (e.g. /4-evaluative-market-experiments/). It introduces the section’s theme and lets readers navigate into individual methods via the sidebar.

Required content:

• YAML frontmatter (title, order, section, sectionTitle, description).
• # Title.
• One or two paragraphs of context — what this section covers, when readers come to it, what they should expect to learn.

Section pages do NOT include In Brief, BMC, Tags, Time Commitment, Resources, or any procedural content. Those belong on individual method pages.

Prose Chapter Structure

Prose chapters cover narrative, conceptual, or reference content — preface chapters, the index pages, foreword, afterword, appendix entries.

Required content:

• YAML frontmatter (title, order, section, sectionTitle, description).
• # Title.
• Prose organized with ## and ### headings as the content needs.
• Voice follows the register for that section type (see Tone of Voice guide).

Prose chapters do NOT include method-page sections (Tags, In Brief, BMC, How to, Biases, Case Studies, References as a footer block). An appendix chapter MAY include a References section if the chapter itself cites sources, but there is no required template — let the content’s needs decide the headings.