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
    #### AI Prompt
    #### Biases & Tips
  ### 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.

Write for now, not for the before-times. The reader does not know the pre-AI version of the method and has no point of comparison, so never frame AI in terms of what the work “used to” take or what it “replaced.” State what the method takes today, plainly. Cut before/after framing such as “what once took a team days now takes minutes,” “AI replaced the analyst that used to do this,” or “this used to require a recruited panel.” This creeps in most often in Time Commitment and Resources — give the current time and cost directly. Historical or methodological backstory belongs in References, not the method body.

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.

No invented procedure sections. The template’s headings are the only headings a method page uses. Do not add ad-hoc sections such as ### The "Sell It Back" Step (product-box) or ### Optional: $100 Allocation Follow-Up (card-sorting-features). If the content is a step, fold it into ### Prep, ### Execution, or ### Analysis. If it is really a second method, link to that method’s page in one sentence and stop — don’t embed a mini-version of it. (### Optional: $100 Allocation Follow-Up is just [Buy a Feature]; link to it.)

No subsections under ## Description. The Description is prose only — no ### When to Use, ### What X Is Not, ### What to Build / ### What Not to Build, ### Validation-Phase Only, or similar. These tend to duplicate other slots: “when to use” overlaps Common Use Case (or, for a family variant, the parent’s Choosing-the-Right hub); “what X is not” is differentiation that belongs as one phrase in the Description prose, not a heading. Fold the content into Description prose, Common Use Case, Prep, or the Resources detail as appropriate. yarn lint:methods warns on any heading under a method page that isn’t in the canonical template.

Name tools only in ## Tools, not in the prose. Specific commercial products (Maze, Lookback, Lyssna, UserTesting, Otter.ai, Figma) are listed once in ## Tools with a phrase on what each does for this method. Don’t name them in the Description, the How-to steps, or a prose AI note. The body describes the capability in plain language (“session-transcription and pattern-clustering tools”); the named products live in ## Tools, where they are maintained as the market changes. Naming products inline both dates the page and duplicates the Tools list.

Section-by-Section Notes

Frontmatter fields:

### Tags: Placed at the very top of the page, above the image and In Brief.

Required policy:

• Include at least one data-type tag: Qualitative and/or Quantitative (both are allowed).
• Include at least one channel tag: In-person and/or Remote.
• Include at least one evidence tag: Behavioral, Attitudinal, Observational, and/or Transactional.
• Business-model tags are optional. Add them only when the method is materially constrained to, or especially suited for, a specific model (B2B, B2C, B2G, C2B, C2G, C2C, B2B2C, DTC, G2C, G2B, G2G, two-sided market).
• Use only two-sided market (do not use 2-sided market).
• Do not include taxonomy tags Generative, Evaluative, Market, or Product in ### Tags; section placement already encodes that.
• Do not use Business Model Canvas segments as tags (for example Customer Segments, Value Propositions, Channels, Customer). Those belong only in bmc: frontmatter and ### Business Model Canvas.

If a tag appears on almost every page, remove it from tags and encode it elsewhere (section taxonomy or prose).

## 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.” Keep the In Brief to a single short paragraph — method comparisons, disambiguation (“this is not the same as X”), and extra mechanics or detail belong in the Description, not here. The only thing that may follow the In Brief paragraph is a one-line sibling cross-reference (“For the feature-focused variant, see [Card Sorting]”).

Do not open by announcing the method’s taxonomy (generative, evaluative, qualitative, quantitative). Section placement and the tags already encode it, so “Synthetic persona screening is a generative research method where you…” wastes the most valuable line in the book. Open with what the method is and does. Name the taxonomy only when it earns its place — to draw a contrast or to warn of a misuse (“unlike the evaluative variant, this…”).

In Brief and Description should not be near-duplicates — but they are separate front doors, and each must stand on its own. The In Brief is the scannable 30-second summary; the Description is the fuller treatment a reader gets if they skip straight to it. They will necessarily share the method’s core definition, and that is correct. Achieve separation by keeping the In Brief short, not by gutting either one. If the In Brief has grown as long and detailed as the Description, shorten the In Brief.

### Common Use Case: A concrete, second-person scenario (“You’ve talked to participants 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: Shade the BMC blocks this method speaks to, at one of two strengths, and give each a one-line “why” rationale (rendered as the block’s hover/focus tooltip). The remark-bmc plugin renders a compact SVG in the sidebar card with three shadings: dark (Focus), light (May inform), and unshaded (not addressed).

Use two labelled lists under the heading:

### Business Model Canvas

**Focus:**

- Value Propositions — Validates whether the core promise resonates.
- Customer Segments — Identifies who actually has the pain.

**May inform:**

- Channels — May surface where the customer already looks for solutions.

• Focus (dark) = the block(s) the method is built to produce evidence or ideas about — what it validates/invalidates, or (for a generative method) the block it generates data/ideas about. Keep this tight: 1–2 blocks (3 only when the method genuinely produces primary evidence on three, e.g. a smoke test hitting demand + willingness-to-pay + acquisition).
• May inform (light) = secondary information the method may surface as a byproduct. Most blocks a method merely “touches” belong here, not in Focus.
• Not addressed (unshaded) = omit entirely. A block the method takes as an input (e.g. the target segment a competitive analysis is judged against) is not shaded — the method consumes it, it does not validate it.
• Rationale voice: Focus rationales lead with a validation/generation verb (“Validates…”, “Identifies…”, “Surfaces…”, “Measures…”, “Generates…”); May-inform rationales lead with a hedged verb (“May surface…”, “Can reveal…”, “Hints at…”). One sentence, ~80–160 characters, concrete to this method. Separator between block name and rationale is a spaced em-dash ( — ); internal em-dashes are fine. A bullet with no em-dash still shades the block (name-only tooltip).
• Frontmatter bmc: must list the union of all Focus + May-inform blocks (not the unshaded ones). yarn lint:methods errors if the frontmatter set does not exactly match the section’s blocks. A bare single list with no Focus/May-inform labels is still accepted and renders entirely as Focus (dark) — the legacy form.

### Time Commitment: Iconographic time indicators in the sidebar card (timeToRun in frontmatter). First paragraph = the glance: a range-only estimate beside the icons (≤30 characters ideal, 60 hard max; e.g. ~3 days–2 weeks). Show the real estimated range, not a single figure and not a bucket-snapped band (see Estimating time & cost below). Second paragraph (optional) = detail for web hover only (omitted in PDF/EPUB). yarn lint:methods warns above 30 chars and errors above 60 when a detail paragraph is present. State the current time the method takes; do not frame it against what it “used to” take before AI (see Writing About AI).

### Resources: Same pattern as Time Commitment (costEstimate in frontmatter): the glance is a range-only cost estimate (e.g. $0–$350, $300–$6K). Put participant-compensation nuance in the detail paragraph, not the glance line. State the current cost directly — not what AI “replaced” or what the method “used to” cost. When a method family has shared cost-reduction techniques (e.g. “pretend to own” for prototyping), repeat the one relevant to this method here in the detail paragraph rather than only on the parent page — each child must stand alone. Cost figures (the detail paragraph and costEstimate) reflect current market rates for recruiting and compensating participants, which is usually the dominant cost of running a method and is frequently understated; price recruiting honestly rather than optimistically.

UI note: in the At-a-Glance card this renders as Cost, but source markdown heading remains ### Resources.

Estimating time & cost (glance = real range, icon = derived level). The glance shows a genuine ~90%-confidence estimate of the whole-run total (cost = out-of-pocket spend; time = calendar time), assuming AI assistance. Use real numbers — $5–$50, $25–$600, ~2–6 weeks — never a single point and never snapped to bucket edges. Use a $0 low end only when free is genuinely realistic (free tools + own-network/consumer recruiting). The frontmatter timeToRun / costEstimate bucket is derived from the estimate’s median and only drives the 3-level icon: pick the enum whose level matches the median, leaning to the higher level when the range meaningfully crosses the boundary.

The five buckets are coarser than the real range, so a method costing ~$2–$8K (or running ~1–3 months) has no exact bucket — round to the nearest enum by median and let the glance carry the true figure. Participant recruitment/incentives are usually the dominant cost and are easy to understate.

## 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, and do not include a paragraph that previews the Prep / Execution / Analysis stages (“The method has three stages: Prep does X, Execution does Y, Analysis does Z”). That walkthrough is pure redundancy with the How-to section directly below it.

For a child page in a method family (a Value Proposition Test smoke-test variant, a Prototyping fidelity variant, etc.), the Description opens with a definition of that specific variant — not a restatement of the family’s definition. Name the variant’s distinguishing trait (e.g. its position on the commitment ladder) and link the family parent in a short phrase. The family’s full definition lives once, on the parent page; it is not re-stated on every child (which reads as boilerplate when the book is read straight through). Put this family pointer in the Description opener (right after the variant’s own definition), not in the In Brief — the In Brief stays a clean, standalone summary of the method itself. (A genuine sibling cross-reference — “for the feature-focused variant, see [Card Sorting - Features]” — may still sit in the In Brief per the cross-reference convention; the parent/family pointer does not.) The Description must be self-contained. A reader who jumps straight here, skipping the In Brief, has to understand what the method is — so the Description opens with a clear, plain definition of the method (“X is a structured … where you …”). Do not strip that opening definition just because the In Brief already gave one, and do not open the Description mid-procedure (“You write the guide…”) assuming the In Brief was read. After the definitional opening, the Description earns its length by adding depth the In Brief doesn’t carry: mechanics, concrete examples, failure modes, when not to use it. Sharing the core definition with the In Brief is expected; the In Brief is just the compressed version.

Don’t open the Description by differentiating from another method. Start with what the method is and does in its own terms. An opener like “The demo pitch differs from a Solution Interview in one way that matters…” forces the reader to understand a second method before the one they are on. State this method’s own definition first; a contrast with a sibling comes after, if it earns its place. (The child-page family pointer above is the one allowed exception, and it still follows the variant’s own definition rather than leading with it.)

Every method page stands alone. A reader must be able to run the method from its own page without first reading the parent. The family pointer is a brief link, not a dependency — so any actionable content the reader needs to run this method (key constraints, cost-reduction techniques) must appear on the child page itself, even when a fuller treatment also lives on the parent. This does not contradict “the family definition lives once on the parent”: the definition is a pointer; actionable detail is repeated where the reader needs it.

## 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. If the method uses a script (an interview guide, intro framing, or prompts), the script’s content is decided here in Prep — including framing such as “there are no right or wrong answers.” The Execution step then uses the script; it does not re-specify what the script should say.

#### 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.

AI-only research must build in a fact-check. When a method’s data comes entirely from AI (synthetic personas, AI-generated market sizing, AI desk research) rather than from real participants, the AI Prompt must include an explicit verification pass: instruct the AI to cite sources, distinguish what it is inferring from what it is reporting, and flag anything it cannot ground in a real source — so hallucinated “findings” don’t read as evidence. For value-proposition tests that collect real money, the prompt also carries the ethics note (see Taxonomy → Value Proposition Test).

## 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. Cover the method’s dominant, well-documented failure modes — not a token one or two; a reader should come away knowing the main ways this method misleads people. For interview- and observation-based methods that means at least leading questions, social-desirability (compliment) bias, confirmation bias, and selection/sampling bias. 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-Ended Survey page and the Pain Point Sorting page show the canonical visual treatment.

Named entries only — no loose quotes or untitled tips. Every bullet must be a - **Named bias or principle** — … entry. Two things that used to leak into this section do not belong: (1) Promotional quotes — aphorisms with an @handle (e.g. - "…" - @TriKro) render as plain bullets, break the pill layout, and are marketing assets, not biases; move them to the page’s promoQuotes: frontmatter (see Promo Quotes below). (2) Untitled tips — a tip with no bias name either gets a principle name and becomes a proper pill entry, or moves into the relevant ### Prep / ### Execution / ### Analysis step. A procedural must-do always belongs in the How-to.

Scope: gotchas and biases, not a recap of the steps. Biases & Tips is for specific problems that are not obvious from the How-to — classic psychological biases that need a guardrail, and gotchas a reader would otherwise walk into. It is not a place to restate actionable steps. Before adding or keeping an entry, check the How-to: if the point is already a numbered step, cut it; if it is genuinely a step, move it there; only if it is a distortion the reader must actively guard against does it earn a named pill. When a tip is really the mitigation for a bias already listed, fold it into that bias’s entry rather than adding a second bullet. The entry must also be specific to this method — a tip that really applies to a different method belongs on that method’s page (or as a Next Steps cross-reference), not here.

Enforcement. yarn lint:methods requires at least one - **Named bias** — entry per section (section.biasesTips.boldLead, error) and flags every bullet without a bold-name lead-in (soft.biasesTips.untitled, warning) so untitled tips and stray quotes surface in the report.

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).

#### Promo Quotes (non-rendering): Marketing pull-quotes live in the page’s promoQuotes: frontmatter, never in the body. Each entry is a text plus an author key that resolves against the shared registry in src/data/authors.yaml (display name + per-platform handles for @-mentioning the source on X, LinkedIn, etc.). Keeping the quote in the method page’s own frontmatter ties it to the page it promotes and survives slug renames; keeping the author handles in one registry means a handle change is a single edit. These do not render in the book — they are a data source for social promotion.

# method page frontmatter
promoQuotes:
    - text: 'Ask about the past. Observe the present. Forget about the future.'
      author: trikro

### 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”) 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. A pivot, founding, or origin story counts only if the team actually ran this method to get the insight — a famous company anecdote that really illustrates a different method (a smoke-test MVP, a growth hack, a lucky pivot) does not belong here just because the company is well known; match the case to the page’s method or cut it. Vendor or tool write-ups and how-to guides are not case studies — put tools in ## Tools and guides 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.

Bold bullet labels are short. When a bullet leads with a bold label (- **Ethics** — …, - **Social desirability bias** — …), the bold span is just the label — a word or short noun phrase — followed by an em-dash and the explanation. Don’t fold a whole clause into the bold (- **Ethics — you are deceiving the buyer.**). The separator is an em-dash, not a hyphen; SmartyPants renders it and the Biases plugin strips it. yarn lint:methods warns when a bold lead-in runs long or contains a full sentence.

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.

Quotes and apostrophes: Type straight quotes and apostrophes in source (' and "). The build’s SmartyPants pass renders them as curly typographic marks on web, PDF, and EPUB — all three targets inherit the same Astro-rendered HTML, so straight source is both correct and the easiest to type. Don’t paste curly characters into source. One caveat: SmartyPants does not convert inside backtick code spans, so never rely on smart-quoting inside code, and reserve backticks strictly for code, paths, and frontmatter field names — never as quotation marks or apostrophes.

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.

Image roles

The image’s layout role is declared with the markdown image title (the quoted text after the URL). The default — no marker — is an inline figure; add a marker only when you need a different role:

• Default (no marker): ![alt](/assets/book/x.png) → Inline figure, centered at full text measure.
• ![alt](/assets/book/x.png "inset") → Inset spot, floats top-right with the body text wrapping around it (front-matter openers, small spot art).
• ![alt](/assets/book/x.png "divider") → Section divider (rarely needed by hand — section index pages get this automatically).
• ![alt](/assets/book/x.png "inline") → force Inline figure; use this when an image shares a paragraph with text. The bare default only auto-centers images that are the sole content of their paragraph, so an image inline with prose needs the explicit "inline" marker.

See docs/print-edition-design-intent.md Step 6 for the full image taxonomy (roles, sizes per render target, and aspect ratios).

Terminology and Plain Language

Default to “participant,” not “customer.” In a method’s procedure, the person running the exercise is a participant — they have not necessarily bought anything. Reserve customer for cases where it is specifically warranted:

• the person has definitely purchased something (e.g. a post-sale or churn study);
• a Business Model Canvas term of art (Customer Segments, customer discovery, customer relationships);
• a case study that is genuinely about a company’s paying customers;
• an AI prompt where “customer” simply reads more clearly.

Everywhere else — a method’s steps, biases, and analysis — write participant. Watch for partial conversions: when you change “customer” to “participant” in a page, change every instance, not just the first few, or the page reads as half-edited.

Avoid unexplained jargon. Write for a first-time founder with no research background. If a term isn’t self-explanatory, replace it with plain language or define it on first use — “ordered list,” not “rank vector” or “vector map”; “group similar reasons together,” not “affinity diagramming” with no gloss. Technical precision the reader can’t decode is just noise.

Don’t assume a web product. If a method can be run for a physical product or an in-person service, the prose shouldn’t speak only in “visitors,” “clicks,” and “page views.” Use language that covers both (“participants,” “people who responded,” “sign-ups or sales”), and reach for web metrics as one example among several. The exception is an inherently online method — a landing-page smoke test legitimately measures clicks and conversion, and should. The test: could a reader selling a physical product or a service run this? If yes, the default language must include them.

Cross-references

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

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

Link on first mention. Any method named in body prose links to its page the first time it appears, so readers can navigate to it. Don’t restate the referenced method’s procedure inline — link and move on.

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 participants. 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.

Real-money VPTs carry an ethics note. When a value-proposition test collects real money (mock sale, pre-sale, crowdfunding, fake checkout), the page includes a short, explicit ethical warning — that a real person believes they are completing a real purchase — in both the prose (Description or Biases & Tips) and the #### AI Prompt. One or two sentences; the point is that the reader, and the AI helping design the test, both account for the deception that produces the strong signal.

Prioritization: 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” page in Generative Product Research.

Prototyping: Methods that put something in front of the participant 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 “Prototyping” page in Evaluative Product Experiments.

Data Mining: Methods that extract insights from existing data sources rather than generating new data through participant 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 — the method’s “also known as” names. 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.

Alternate names render only from the aliases field — never from prose. Set each alternate name once, in aliases, and nowhere else. From there it renders automatically as the method’s “also known as” line: on method pages, an “Other names” labeled text row at the bottom of the At-a-Glance card (web and PDF); in the EPUB, an “Other names:” line. The same field also feeds search and page metadata. Do not write alternate names into the Description, In Brief, or any other body prose (“also called X,” “sometimes known as Y”) — the aliases field is the single source, and any prose mention duplicates the “Other names” line that already carries it.

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.
• One canonical home per point. A claim, payoff, or caveat belongs in exactly one section. If the same point (the method’s core tradeoff, its biggest payoff, a sample-size caveat) recurs across In Brief, Description, a How-to step, and Next Steps, keep only the strongest placement and cut the echoes. Section-local tightening (“don’t repeat the How-to”) is not enough — apply this across the whole page. Exception — #### AI Prompt blocks are self-contained. A prompt is a copy-paste artifact: the reader lifts one prompt and runs it in isolation, so each must carry every instruction it needs on its own. When the Prep, Execution, and Analysis prompts share machinery (a fact-check / source-verification routine, a schema, a constraint), repeat it in full in each prompt — do not de-duplicate it by replacing the shared block with a “see the Analysis prompt below” pointer. The de-duplication rule above governs the user-facing prose (In Brief, Description, Time Commitment, Biases, Next Steps); it does not govern the prompts, where deliberate repetition across the three blocks is correct.
• Clever, idiomatic, or self-referential phrasing. Method pages use plain, neutral, instructional language — not the stylized, voice-forward register of the prose chapters. Cut writerly flourishes and meta-claims about the method itself: “the hour is genuinely the whole clock,” “this step is load-bearing,” “the strongest claim the method can responsibly carry,” “it pays for itself by sharpening the questions you ask real humans.” State the plain fact instead (“Recruiting is the main time cost”). If a phrase reads as a turn of phrase rather than an instruction, cut it.
• No meta-commentary on a step’s importance, ease, or history. “This step is critical”, “The mechanism is simple”, “This became viable in 2023–2024”. Don’t announce that a step matters, reassure the reader it’s easy, or narrate the technology’s backstory — give the instruction. A reference manual instructs; it does not editorialize about itself.

The book’s voice is direct, second-person, and instructional. If a sentence sounds like it was written for a LinkedIn post, rewrite it. Method pages in particular stay neutral and plain; the stylized, voice-forward writing belongs to the prose chapters (foreword, preface, introduction), not to method procedures.

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…”
• “works best with several hundred users” / “best with 100+ users” → “enough responses for the comparison to be meaningful”

A blanket sample-size claim silently disqualifies B2B, niche, and low-baseline-rate contexts where the method is still valid. State the constraint that actually matters, and give a hard number only when it is sourced or when statistical significance is genuinely impossible below it (say so, and why).

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 participants”, “200 responses”) must have a resolvable reference in the References section, or it gets framed as a rule of thumb. No unsourced statistics. No invented attributions.
• Citations live in References, not the method body. Keep source citations out of the procedure and the Description. Studies, books, named lineages, and sample-size sources belong in the ## References section (follow-up reading), not parenthetically inline. A claim in the body that needs support gets a reference entry — not an inline “(Author, Year).”
• Method lineage credits go in References. When a technique has a documented inventor or a named lineage in research methodology, credit it in ## References, not inline in the steps. 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. Record those credits in References so the body stays clean, and don’t write technique descriptions as if invented for this page. If the technique is itself a method in this book, link to its page in the prose and let that page carry the lineage. Exception — load-bearing attribution stays in the prose. When a method is substantially derived from one originator’s named work — the Prioritization family is Luke Hohmann’s Innovation Games — naming that source in the prose is an integrity requirement, not optional further reading, and it lives on the family/parent page so children inherit it by link. A tangential mention (the pivot types from The Lean Startup) is not owned by the method and goes in References, not the body. Rule of thumb: name it in-prose only if removing the name would misrepresent whose method it is.
• Time and cost estimates reflect current rates. Participant recruitment and compensation is usually the dominant cost of a method and is frequently understated. Cost lines and the costEstimate frontmatter should reflect current market rates for recruiting and incentivizing participants — panel/recruiter fees and incentive amounts — not a stale or optimistic figure. When AI removes the analysis cost, recruiting becomes the binding cost and time constraint; price it honestly.

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 (16 children, grouped by commitment type), Data Mining (3 children, single group), Prioritization (4 children, single group), 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]
  ### [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 #### AI Prompt — parent pages are selection hubs; readers choose by scanning At-a-Glance and the method bullets.
• 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 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 two 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. 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 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. /2-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.