# Case Studies: Jobs-Style Reviews in Action

Documented episodes from Apple history, each read as a design-review lesson: what the situation was, what standard was applied, and what a reviewer should extract for their own products.

## Contents

- [How to use these cases](#how-to-use-these-cases)
- [The 1997 product line massacre — focus](#the-1997-product-line-massacre--focus)
- [The original iMac — opinionated subtraction](#the-original-imac--opinionated-subtraction)
- [The original Mac's circuit board — back of the fence](#the-original-macs-circuit-board--back-of-the-fence)
- [iDVD and the Burn button — simplicity as spec](#idvd-and-the-burn-button--simplicity-as-spec)
- [The iPod — steps-to-value and the missing switch](#the-ipod--steps-to-value-and-the-missing-switch)
- [The iPhone keyboard — demos discover the real product](#the-iphone-keyboard--demos-discover-the-real-product)
- [Apple Stores — owning a touchpoint everyone outsourced](#apple-stores--owning-a-touchpoint-everyone-outsourced)
- [MobileMe — the failure review](#mobileme--the-failure-review)
- [Antenna-gate — when the standard meets reality](#antenna-gate--when-the-standard-meets-reality)
- [The cautionary side of the legend](#the-cautionary-side-of-the-legend)
- [Pattern summary for reviewers](#pattern-summary-for-reviewers)

## How to use these cases

In a review, cases function as precedents: when a team resists a verdict ("we can't cut that," "users will learn it," "nobody sees that screen"), the right case shows the standard applied under harsher stakes than theirs. Quote the case, then return to their product. Don't let the discussion stay in Apple nostalgia — every case below ends with the transferable question to ask about *your* product.

## The 1997 product line massacre — focus

**What happened.** Jobs returned to an Apple weeks from bankruptcy, selling dozens of overlapping Macs (Performa 5200, 6200, 6300…), printers, the Newton. Reviewing the product roadmap, he found that even insiders couldn't explain which computer a friend should buy. He killed roughly 70% of the line and replaced the catalog with a 2×2 grid: consumer/pro × desktop/portable. Four great products. Apple returned to profitability within a year, and the focus freed the engineering talent that built the iMac and, later, the iPod.

**The review standard.** A product catalog is itself a design that must pass the one-sentence test. Confusion at the catalog level can't be fixed at the product level.

**Transferable question.** *Could a team member tell a friend, in one sentence each, which of your products/plans/tiers to choose? If not, the review's first fix list item is the lineup, not the UI.*

## The original iMac — opinionated subtraction

**What happened.** The 1998 iMac shipped without a floppy drive — universal at the time — betting on the internet and CDs. It dropped legacy ports for USB only. The industry called it reckless; customers called it the easiest computer to set up, and the translucent all-in-one design re-established Apple as a consumer brand. The pattern repeated for two decades: optical drives, Flash, headphone jacks — Apple's reviews treated *removal of the dying-but-comfortable* as a product feature.

**The review standard.** Subtraction is allowed to be ahead of user requests. Users ask for compatibility with their present; great reviews judge against the product's future. The bet must be on something genuinely replacing the removed thing — the iMac removed the floppy *because* networks and CDs could carry the load.

**Transferable question.** *What is your product still carrying because removal feels scary rather than because the need persists? What's the floppy drive in this UI?*

## The original Mac's circuit board — back of the fence

**What happened.** During the original Macintosh's development, Jobs reviewed the printed circuit board — a component no customer would ever see — and objected to how the lines and chips were laid out: "That part's really pretty… But look at the memory chips. That's ugly." When an engineer protested that nobody would see it, Jobs replied that *he* would see it, and invoked his father's standard: a great carpenter doesn't use plywood on the back of a cabinet. The team also signed their names on the inside of the case, "because real artists sign their work."

The standard came from Paul Jobs' fence: building it as a boy, Steve asked why the back had to be as well-made as the front, and his father said the back mattered even if no one saw it — *you* would know. Jobs retold this story for decades as the root of his quality doctrine.

**The review standard.** Quality is a property of the whole artifact, not of its visible surfaces. Teams that allow plywood where "nobody looks" are training themselves in corner-cutting that inevitably migrates to visible surfaces. And someone always looks: engineers, integrators, auditors, the next maintainer.

**Transferable question.** *What's your circuit board — the codebase, the API responses, the admin tools, the log messages? Open one in the review. Would the team sign it?*

## iDVD and the Burn button — simplicity as spec

**What happened.** Mike Evangelist, preparing to pitch DVD-burning software to Jobs, built pages of careful mockups for the planned interface. Jobs walked in, ignored the deck, drew a single window on the whiteboard and said: *"Here's the new application. It's got one window. You drag your video into the window. Then you click the button that says 'Burn.' That's it. That's what we're going to make."*

**The review standard.** The simplest articulation of the product *is* the spec; complexity must justify itself against that baseline, not the other way around. Most products are designed forward from capabilities ("what can we expose?"); Jobs designed backward from the user's sentence ("I want this video on a DVD").

**Transferable question.** *Write the whiteboard version of your feature — one window, one verb. Now list every element in the actual design that the whiteboard version lacks. Each one defends itself, or dies.*

## The iPod — steps-to-value and the missing switch

**What happened.** The iPod's defining review constraint was navigational: Jobs demanded users reach any song in about three presses, which forced the scroll wheel + menu hierarchy that defined the product. The device also shipped with no on/off switch — sleep and instant wake made the need disappear. The marketing sentence ("1,000 songs in your pocket") matched the product's actual one-thing with unusual honesty. Meanwhile the engineering reality (a Toshiba drive, a PortalPlayer platform) was invisible — customers experienced only the conquered complexity.

Two review moments are worth keeping: Jobs testing volume and song-access latency obsessively, and the (likely embellished, but instructive) tale of executives demanding a smaller prototype by dropping it in a fish tank and pointing at the escaping air bubbles. The durable truth under the legend: the review pressure was always on *experienced* size, speed, and steps — never on the component list.

**The review standard.** Set numeric experience constraints in the review (three presses, one second, one screen) and let them force the design. Constraints are generative: the scroll wheel exists because "three presses to any of 1,000 songs" is impossible with buttons.

**Transferable question.** *What are your product's three-press constraints? If the review hasn't set any, the design has nothing to push against.*

## The iPhone keyboard — demos discover the real product

**What happened.** Typing on glass was the iPhone's scariest open problem. Instead of a spec, the team ran a derby: every engineer built a complete working keyboard, leadership typed on all of them, and Ken Kocienda's design won — multi-letter keys backed by a dictionary algorithm that guessed the intended word. Iteration later returned the layout to familiar single letters, but kept the derby's real discovery: the autocorrect engine. The visible thing everyone argued about (key layout) turned out to be secondary to an invisible thing only working demos could surface (correction quality). Full story and derby rules: [demo-culture.md](demo-culture.md).

**The review standard.** When argument stalls, stop reviewing opinions and start reviewing artifacts. And expect the demo to relocate the problem — the artifact knows things the debate doesn't.

**Transferable question.** *What's your team's longest-running design argument? What would a one-week, two-entry demo derby cost compared to another month of that meeting?*

## Apple Stores — owning a touchpoint everyone outsourced

**What happened.** In 2000, computers were sold through big-box retailers: commission-driven, indifferent, brutal to a premium brand's story. Rather than accept the industry's seam, Apple designed the touchpoint itself: stores conceived like products, with a full-size prototype store built in secret for iteration (and famously reorganized late, when Ron Johnson convinced Jobs the layout should follow what people *do* — music, photos, movies — rather than what Apple sells). The Genius Bar redesigned the support touchpoint the same way: a named, designed, human face on failure. Analysts predicted the stores would die in two years; they became the highest revenue-per-square-foot retail in the world.

**The review standard.** The end-to-end audit ([end-to-end-experience.md](end-to-end-experience.md)) is allowed to conclude: *this touchpoint is too important to leave to whoever owns it now.* Sometimes the fix list item is "take ownership of the channel," not "polish our part of it." Note also the meta-lesson: the store itself went through demo culture — a prototype built, reviewed, and substantially reworked before launch.

**Transferable question.** *Which touchpoint in your journey is currently rented out to someone whose incentives aren't your customer's experience — an app store page, a reseller, an outsourced support desk, a third-party checkout? What would owning it look like?*

## MobileMe — the failure review

**What happened.** MobileMe, Apple's 2008 cloud sync service, launched broken: lost emails, failed syncs, weeks of public embarrassment. Jobs assembled the team in a town hall and asked: *"Can anyone tell me what MobileMe is supposed to do?"* When someone gave the right answer, he replied: *"So why the f— doesn't it do that?"* He told the team they had tarnished Apple's reputation and "should hate each other for having let each other down," and replaced the group's leadership on the spot, putting Eddy Cue in charge.

**The review standard.** Three parts. First, the reviewing logic: products are judged against their own public promise — state the promise, test it, the gap is the review. Second, launch reviews exist precisely to run this test *before* customers do; MobileMe is what skipping the cold-run launch review costs. Third, accountability is real: a failed launch review has consequences, or the standard is theater.

**The boundary.** The public shaming is the part *not* to import. The promise-gap logic works delivered with respect; the humiliation is separable and corrosive (see [The cautionary side](#the-cautionary-side-of-the-legend)).

**Transferable question.** *Take your marketing page's top three claims. Run each one, today, as a new customer. Do you pass your own MobileMe question?*

## Antenna-gate — when the standard meets reality

**What happened.** The iPhone 4's beautiful stainless-steel band doubled as the antenna — an integration triumph that attenuated signal when gripped at a corner. The design review had, by external accounts, favored form in a tradeoff that physics ultimately surfaced for everyone. Apple's response mixed defensiveness ("you're holding it wrong" became the public caricature of Jobs' initial framing) with a competent recovery: data-driven press conference, free bumper cases.

**The review standard.** This case is the check on the others: "design is how it works" outranks "design is how it looks" *even when the looks are extraordinary*. A review culture strong enough to override the founder's aesthetic preference would have weighed the attenuation finding more heavily. Reviews need a mechanism for bad news to beat beautiful work.

**Transferable question.** *In your last contentious review, did the inconvenient measurement lose to the beautiful artifact? Who in the room is structurally empowered to make the measurement win?*

## The cautionary side of the legend

Honesty about the source material keeps this skill usable. The documented record also shows: public berating, credit appropriation, binary people-sorting ("geniuses" and "bozos") that wrote off recoverable work, and review brutality that some teams metabolized and others were damaged by. Several practices worked *despite* these behaviors, not because of them — Kocienda's account is notable for showing the demo loop functioning with deciders (Lamiraux, Forstall) who were demanding without being cruel.

For reviewers, the separation is clean:

- **Import:** the customer-first cold run, the promise test, binary verdicts, specificity, subtraction pressure, back-of-fence standards, demo-or-nothing, one decider.
- **Leave behind:** humiliation, people-grading, verdicts about worth rather than work. Not for niceness — because fear suppresses early demos and honest bad news, which are the raw inputs the whole loop runs on.

## Pattern summary for reviewers

| Case | Principle | One-line reviewer takeaway |
|---|---|---|
| 1997 line cut | Focus | Review the catalog before the products |
| iMac (no floppy) | Subtraction | Removal can lead users, if a replacement is real |
| Mac circuit board | Back of the fence | Open an invisible surface in every review |
| iDVD "Burn" | Simplicity as spec | The whiteboard sentence is the baseline; complexity defends itself |
| iPod three presses | Constraints | Set numeric experience budgets; they generate design |
| iPhone keyboard | Demo culture | Stalled arguments become derbies; artifacts relocate problems |
| Apple Stores | Whole experience | A fix list may say "own the touchpoint" |
| MobileMe | Promise test | Run the marketing page against the product before customers do |
| Antenna-gate | How it works > looks | Bad news needs structural power over beautiful work |

# Demo Culture: Creative Selection and the Demo-Driven Review

How Apple's software was actually decided — working demos shown to a decisive reviewer, iterated until great — and how to install that loop in any team or agent workflow.

## Contents

- [Where this comes from](#where-this-comes-from)
- [The creative selection loop](#the-creative-selection-loop)
- [Why demos beat documents](#why-demos-beat-documents)
- [What counts as a demo](#what-counts-as-a-demo)
- [The decider](#the-decider)
- [The demo derby](#the-demo-derby)
- [The keyboard derby story](#the-keyboard-derby-story)
- [Honest-demo rules](#honest-demo-rules)
- [Demo review mechanics](#demo-review-mechanics)
- [Prototyping the riskiest moment first](#prototyping-the-riskiest-moment-first)
- [Real artists ship](#real-artists-ship)
- [Installing demo culture](#installing-demo-culture)
- [Demo culture for AI agents](#demo-culture-for-ai-agents)

## Where this comes from

Ken Kocienda spent fifteen years as an Apple engineer — Safari, the original iPhone keyboard, iPad autocorrect — and wrote *Creative Selection* to document how the sausage was actually made. His answer is striking for what's absent: no grand design phase, no thick specs, no consensus workshops. Instead:

> A small team builds a **demo**, shows it to a **decision-maker**, receives **specific feedback**, and builds the next demo. Repeat until insanely great or killed.

He calls the process "creative selection" — variation and selection, like evolution, except the selection pressure is a person with taste and authority reacting to a concrete artifact. Jobs sat at the top of a demo pyramid: work was demoed up through layers (team lead → Henri Lamiraux/Scott Forstall → Jobs), getting selected and refined at each level before reaching him.

## The creative selection loop

```
make a demo → show the decider → get concrete feedback → decide (pursue / change / kill) → next demo
```

Properties that make the loop work:

- **Cadence over ceremony.** Demos happen weekly or faster. The loop's value is its iteration count, not any single review's brilliance.
- **Concrete over abstract.** Discussion is about the thing on the screen — this animation, this key layout — never about hypothetical users or imagined architecture.
- **Selection over accumulation.** Each round explicitly kills options. The output of a demo review is a *decision*, not a list of considerations.
- **Small teams, named authors.** A demo has an author who owns it and can change it by tomorrow — at Apple this crystallized as the DRI, the Directly Responsible Individual.

## Why demos beat documents

A spec is a promise about a product; a demo *is* the product, in miniature. The differences that matter in review:

| | Spec / slide review | Demo review |
|---|---|---|
| What each person approves | Their own imagined product | The same artifact |
| Hard problems | Deferred ("implementation detail") | Exposed immediately |
| Feel, latency, awkwardness | Invisible | The first thing everyone notices |
| Feedback | Abstract ("consider the user journey") | Specific ("that key is too small") |
| Politics | Rewards good writers/presenters | Rewards good products |
| Convergence | Endless comment rounds | A decision per session |

Documents still have a job — analysis, constraints, API contracts. But the *decision* about whether something is good must be made against an artifact someone can touch. Jobs' allergy to slideware made the general point: "People who know what they're talking about don't need PowerPoint."

## What counts as a demo

A demo is anything a reviewer can directly experience that honestly represents the decision being made:

- Clickable prototype with realistic content (for flow decisions)
- A real build behind a flag, on the target device (for feel/latency decisions)
- A single working screen with hardcoded everything *except* the thing being decided
- For an algorithm: the real algorithm on real data, even with a throwaway UI
- For copy/voice: the actual screens with the actual words, read aloud in context

What does *not* count: static mockups for an interaction decision, lorem ipsum for a content-density decision, a video recorded on the one path that works (unless labeled as such), "imagine that this button…" — if the reviewer must imagine it, it isn't a demo.

Match fidelity to the decision: deciding navigation feel needs animation and latency; deciding information hierarchy needs real content; deciding visual direction can be a flat image. The sin is fidelity *below* the decision, not low fidelity per se.

## The decider

Creative selection requires someone empowered to say "this one, not that one" and make it stick. Without a decider, demo reviews degrade into feedback-collection sessions where all options survive.

What the role demands:

- **Taste** — a developed, articulable sense of what great looks like in this domain (taste is trainable: exposure to great work + the habit of articulating *why* it's great)
- **Consistency** — the team can predict the standard well enough to pre-filter their own work
- **Decisiveness** — every demo session ends with pursue / change-this-specific-thing / kill
- **Presence** — the decider attends; delegated verdicts via notes kill the loop's bandwidth

Wide input, narrow decision: anyone can speak in the review; one person owns the verdict. This is the antidote to design-by-committee, which Jobs treated as the default failure mode of large companies.

## The demo derby

When a problem has several plausible approaches and argument isn't resolving it, stop arguing and run a derby: multiple authors (or one author, multiple approaches) each build a working demo of their answer; the decider experiences all of them side by side and picks one.

Rules that keep derbies healthy:

1. Same brief, same constraints, same deadline for all entrants.
2. Working demos only — the derby judges products, not pitches.
3. One winner. The verdict may graft an idea from a loser onto the winner, but you ship *one* approach, not a compromise blend of all of them.
4. Losing is normal and cheap. The point of the derby is to make killing ideas feel like process, not punishment.

Derbies cost duplicate effort by design — that's the price of replacing weeks of abstract argument with an afternoon of evidence.

## The keyboard derby story

The canonical derby, from *Creative Selection*: typing on glass was the iPhone project's scariest unsolved problem — keys far smaller than fingertips, no tactile feedback. Rather than spec the answer, the team held a derby. Every engineer on the project built a complete working keyboard — zoomed keys, multi-letter keys with word disambiguation, gesture schemes — and the leadership typed on each one.

Kocienda's entry, with keys carrying multiple letters and a dictionary-backed algorithm guessing the intended word, won. He became DRI for the keyboard, and the multi-letter layout was later simplified back to single letters — but the *autocorrect engine* the derby had selected became the thing that made glass typing work at all.

What reviewers should take from the story: the derby surfaced that the real product wasn't the key layout (the visible thing everyone argued about) but the correction algorithm (the invisible thing only working demos could reveal). Specs argue about layouts; demos discover algorithms.

## Honest-demo rules

Demo culture has a known failure mode: the staged demo that hides the truth. Guard rails:

- **Declare the seams.** Author states upfront what's real, what's hardcoded, what's faked. Faking the *undecided* part voids the demo.
- **Real data scale.** Three tidy rows lie about three thousand. Demo with realistic volume, lengths, and ugliness (long names, empty fields, slow networks).
- **Target device, target conditions.** A phone UI on a projector, a latency-sensitive flow on localhost — both lie.
- **Let the reviewer drive.** A driven demo follows the rehearsed path; handing over the input device is the honesty test. The reviewer will immediately tap the thing that doesn't work — that's the data.
- **Known breakage is disclosed, not discovered.** Finding out later that the demo's "minor caveat" was load-bearing destroys the trust the loop runs on.

## Demo review mechanics

The weekly demo review, concretely:

- 30 minutes, standing decider, working artifacts only; anything without a demo waits a week.
- Author gives one sentence of intent ("this demo decides whether inline editing feels better than modal editing"), then hands over the controls.
- Feedback follows the candor rules ([review-protocol.md](review-protocol.md)): about the work, specific, with direction.
- Session ends with a verdict per demo: **pursue** (next demo refines), **redirect** (next demo changes X), or **kill** (write one line about why, so the lesson persists).
- Keep a demo log — date, demo, verdict, reason. The log *is* the design history; specs go stale, the log doesn't.

## Prototyping the riskiest moment first

A demo of the easy 80% proves nothing and burns the team's credibility on polish. Sequence demos by risk:

1. Name the assumption that, if false, kills the project (glass typing can work; sync can be conflict-free; the AI's latency is tolerable).
2. Demo *that* first, ugly everywhere else.
3. Only after the scary demo passes does polish enter the loop.

This is also the right read of Jobs' product instincts: the iPhone bet was decided by whether multitouch scrolling could feel right — the demo that made executives' jaws drop — not by renders of the industrial design.

## Real artists ship

The Macintosh team's 1983 motto — "Real artists ship" — is demo culture's deadline clause. The loop iterates *toward a date*, and the decider's job includes calling "done." Signs the loop is being abused as procrastination: demos refine the same decided thing for weeks; verdicts are all "pursue" with no kills; the riskiest assumption still has no demo while the easy parts gleam. Iteration is a tool for converging, not a license to avoid the verdict.

(The companion motto — shipping junk is also not artistry — is the binary verdict in [review-protocol.md](review-protocol.md).)

## Installing demo culture

Adoption order for a team that currently reviews documents:

1. Declare one recurring 30-minute demo slot. Working artifacts only; no slides allowed in the room.
2. Name the decider (per product area). Announce that demo sessions end in verdicts.
3. Convert the next contested design debate into a derby instead of a meeting series.
4. Start the demo log.
5. Add honest-demo rules to the team's definition of "ready for review."

Expect two weeks of discomfort: demos feel exposing, verdicts feel harsh, and the first kills sting. The compensation is that arguments end, and the product — not the deck — becomes the unit of progress.

## Demo culture for AI agents

When an agent builds or reviews software, the same physics apply:

- **As builder:** produce the running artifact early (screenshot, preview URL, executed test) and review your own work against it — never declare a UI change done from code alone. The demo is the verification.
- **As reviewer:** refuse to verdict from descriptions. Run the app, drive the flow, screenshot the states, *then* apply the review protocol.
- **As derby runner:** when approaches genuinely compete, build both cheaply, compare the artifacts, pick one — and say which and why, rather than presenting both to the user as a menu.

# Own the Whole Experience: The End-to-End Audit

How to review a product as customers actually experience it — one continuous journey from first hearing about it to leaving it — and hold every touchpoint to the same bar as the hero screen.

## Contents

- [The whole widget](#the-whole-widget)
- [Why seams are where quality dies](#why-seams-are-where-quality-dies)
- [The touchpoint map](#the-touchpoint-map)
- [Stage 1: Discovery and promise](#stage-1-discovery-and-promise)
- [Stage 2: The threshold — buying and starting](#stage-2-the-threshold--buying-and-starting)
- [Stage 3: First run is your unboxing](#stage-3-first-run-is-your-unboxing)
- [Stage 4: Daily use](#stage-4-daily-use)
- [Stage 5: Failure and support](#stage-5-failure-and-support)
- [Stage 6: Money surfaces](#stage-6-money-surfaces)
- [Stage 7: Leaving](#stage-7-leaving)
- [Running the end-to-end audit](#running-the-end-to-end-audit)
- [The worst-touchpoint rule](#the-worst-touchpoint-rule)
- [Organizational causes of seams](#organizational-causes-of-seams)

## The whole widget

Jobs insisted Apple control "the whole widget" — hardware, software, and services designed as one thing. The strategic argument (integration beats modularity when the experience isn't yet good enough) matters less for reviewers than the design consequence: **Apple treated surfaces other companies considered someone else's job as product surfaces.**

- Packaging got its own design effort — Apple maintained dedicated packaging design space where designers iterated on the unboxing sequence like a product, because the box is the customer's first physical impression. Jony Ive, in Isaacson's biography: "Packaging can be theater, it can create a story."
- Retail became the Apple Store because Jobs refused to let a commission-driven big-box clerk be the face of the product.
- Support became the Genius Bar — a designed experience with a name, a place, and a tone, instead of a phone tree.

The reviewer's translation: your product is not the app. It is the ad, the pricing page, the signup form, the first run, the daily loop, the error message, the support reply, the invoice, and the cancellation flow. The customer experiences all of it as one thing and remembers it by its worst part.

## Why seams are where quality dies

Inside a company, the journey is split across teams: marketing owns the promise, growth owns signup, product owns the app, finance owns billing, support owns failure. Each may individually be good. The customer experiences the *seams*:

- The ad promises "set up in minutes"; onboarding asks for an org chart.
- The product is elegant; the invoice looks like a fax from 1996.
- The app's voice is warm; the dunning email threatens.
- Signup is one click; cancellation is a support ticket.

Nobody designed these contradictions — that's the point. Seams are unowned by default, and unowned surfaces decay to plywood. The end-to-end review exists to put an owner and a verdict on every seam.

## The touchpoint map

Build the map before judging anything. Columns:

| Touchpoint | Owner | Designed? (deliberately, by anyone) | Promise consistency | Quality vs. hero bar |
|---|---|---|---|---|

Enumerate honestly — typical SaaS journey: ad/post → landing page → pricing → signup → verification email → empty workspace → onboarding → first value → invite/share → daily entry point → notification stream → error states → support contact → status page → invoice/receipt → renewal/dunning → plan change → export → cancellation → win-back email.

The first finding is usually the map itself: a third of the touchpoints have "Designed? = no" and "Owner = nobody."

## Stage 1: Discovery and promise

The review starts at the marketing surface because that's where the promise is made — and the MobileMe pattern (see [review-protocol.md](review-protocol.md)) judges the product against its promise.

Checks:

- Read the landing page claims aloud, then test each one in the product, literally. Every claim the product can't cash within minutes is a defect logged against *the product or the page* — the review doesn't care which team moves.
- Screenshot honesty: do marketing screenshots show real UI at real data scale, or an idealized mock the product never resembles?
- Tone continuity: the voice that sold ("simple, human, fast") must be the voice that onboards and the voice that errors.

## Stage 2: The threshold — buying and starting

Every step between intent and value is threshold friction (count it: [simplicity-and-focus.md](simplicity-and-focus.md), steps-to-value).

Checks: Can a user experience value before creating an account? Before paying? Before a sales call? Each gate needs a defense. Card-before-value is a conversion decision that the review prices in trust. Does the signup ask questions whose answers change nothing? ("What's your role?" → same product either way → cut or defer.)

## Stage 3: First run is your unboxing

Apple rehearsed the out-of-box experience: lid resistance, the order in which items present themselves, the device pre-charged so the first moment is power-on, not a cable hunt. Your first run deserves the same theater — it is the only moment you have a user's full attention and zero habits.

Checks:

- **Minute zero:** what exactly fills the screen on first entry? An empty table with a toolbar is plywood. Design the empty state as the product's opening scene: show what good looks like, offer one obvious first action.
- **Pre-charged equivalent:** can you pre-populate with a sample project, demo data, or an import so the user starts *inside* value rather than outside it?
- **One path:** first run offers exactly one suggested action, not a tour of eight features. The product should feel like it knows why you came.
- **Time-to-first-win:** measure it in the cold run; track it like a vital sign.

## Stage 4: Daily use

The unboxing happens once; the 100th use is the actual product.

Checks: What's the daily entry point (notification, bookmark, email digest) and is *it* designed? Does the core loop get faster with familiarity (shortcuts, recents, defaults that learn)? Where are the repeated paper cuts — the dialog confirmed every day, the list re-sorted every visit, the setting that doesn't stick? Paper cuts compound into churn that no onboarding fix can offset. Latency budget: where does the user wait on the daily path, and what happens during the wait?

## Stage 5: Failure and support

Failure is a designed experience or a brand catastrophe; there is no neutral.

Checks:

- **Error copy:** read every error aloud. Each must say what happened, what it means for the user's stuff, and what to do next — in human language. "An error occurred (code 500)" fails all three.
- **Data dignity:** does failure ever lose user work? Autosave, drafts, retry queues are not features; they're the floor.
- **The support path:** how many clicks from "something's wrong" to a human or real answer? Is support's tone continuous with the product's voice? Does support *know* what the user already tried (context handoff), or does the user repeat everything?
- **Status honesty:** when you're down, does the status page say so before Twitter does?

## Stage 6: Money surfaces

Invoices, receipts, dunning emails, plan-change screens, renewal notices — the most neglected surfaces in software, and the ones with the highest emotional stakes (it's the user's money).

Checks: Does the receipt look like it came from the same company as the product? Does dunning escalate with grace (helpful → urgent), or open hostile? Is the upgrade path obvious *in the moment of need* (hitting a limit) rather than a marketing interrupt? Can a user predict their bill? Surprise invoices are trust defects, not billing edge cases.

## Stage 7: Leaving

Cancellation is the last scene of the play, and the one the audience retells.

Checks:

- Cancellation is findable, takes one or two screens, and works without a sales conversation. Retention flows may make *one* honest counteroffer; mazes, guilt screens, and "call to cancel" are dark patterns and fail the review by definition.
- Export: users leave with their data in a usable format, without begging.
- The goodbye: a graceful exit email leaves the door open; the best churned-user marketing is the dignity of the exit.
- Offboarding tells the truth about what gets deleted and when.

A polished entrance with a hostile exit reveals the company's actual values — and users know it.

## Running the end-to-end audit

1. Build the touchpoint map (owner / designed? / consistency / quality per touchpoint).
2. Cold-walk the *entire journey* as a new customer, including buying with a real card and later cancelling. Note every seam.
3. Grade each touchpoint against the hero bar — the quality of your best screen. Not "fine for an invoice"; one bar.
4. For each below-bar touchpoint: assign an owner, add to the fix list with specificity (what, where, why, fix direction).
5. Re-run quarterly; the map is never done because the journey keeps growing new surfaces.

Output feeds the standard review artifact (see [review-protocol.md](review-protocol.md)), with the touchpoint map attached.

## The worst-touchpoint rule

Score the journey by its minimum, not its mean. A 9/10 product with a 3/10 cancellation flow is a 3/10 experience to the person cancelling — and they're the ones writing reviews. This is why averaging hides exactly what matters: teams celebrate the dashboard redesign while the dunning email does brand damage daily.

In the review artifact, always report: *weakest touchpoint, score, owner, fix.* That line moves more than any other.

## Organizational causes of seams

Seams trace to org charts (Conway's law applied to experience). Durable fixes are organizational:

- **One experience owner** with authority across marketing/product/support surfaces — someone who can fail an invoice the way a design lead can fail a screen.
- **Journey reviews, not surface reviews:** review "becoming a paying customer" or "having a bad day with the product," not "the settings page."
- **Voice guide enforced everywhere** — error copy and dunning emails get the same editorial pass as the homepage.
- **Support in the review room:** the people who hear failure daily hold the map of where the product actually breaks. (Case studies of end-to-end ownership working and failing: [case-studies.md](case-studies.md).)

# The Jobs-Style Review Protocol

A complete, repeatable structure for running design and product reviews to Steve Jobs' standard: customer experience first, working demos only, brutal specificity, binary verdicts.

## Contents

- [Why a protocol at all](#why-a-protocol-at-all)
- [Before the review: experience it cold](#before-the-review-experience-it-cold)
- [The agenda](#the-agenda)
- [Step 1: State the promise](#step-1-state-the-promise)
- [Step 2: The cold walkthrough](#step-2-the-cold-walkthrough)
- [Step 3: The principle audit](#step-3-the-principle-audit)
- [Step 4: The cut list](#step-4-the-cut-list)
- [Step 5: The verdict](#step-5-the-verdict)
- [The output format](#the-output-format)
- [Candor rules](#candor-rules)
- [The MobileMe pattern: reviewing against the promise](#the-mobileme-pattern-reviewing-against-the-promise)
- [Saying-no rituals](#saying-no-rituals)
- [Review cadence](#review-cadence)
- [Anti-patterns](#anti-patterns)
- [Adapting the protocol](#adapting-the-protocol)

## Why a protocol at all

Jobs' reviews looked improvised — he'd pick up the device, poke at it, and react. But underneath the theater was a stable pattern: he experienced products as a customer, judged them against their stated promise, demanded working artifacts, gave feedback so specific it doubled as a fix list, and ended with an unambiguous verdict. Most teams' reviews fail on exactly the dimensions his pattern enforced: they review intentions instead of artifacts, soften feedback into vagueness, and end without a decision.

The protocol below makes that pattern repeatable without requiring a Jobs in the room. Any reviewer — including an AI agent reviewing a design, a PR with UI changes, or a product spec — can run it.

## Before the review: experience it cold

The single highest-leverage act: **use the product before anyone explains it to you.** Jobs famously took products home over weekends and returned with reactions formed as a user, not as an executive who'd been walked through the roadmap.

Rules for the cold run:

- No guided tour, no demo script, no "let me just show you where that is." First impressions are unrepeatable; a walkthrough destroys the data.
- Start where a real customer starts: the ad, the App Store page, the signup form, the unboxing — not the feature in question.
- Use real data at realistic scale. An inbox demo with three tidy emails lies about an inbox with three thousand.
- Note every moment of hesitation, every time you had to think, every time you felt stupid. Those notes are the review.
- Time yourself reaching the core value. Write the number down; you'll need it for the steps-to-value audit.

If the product cannot be experienced cold — because it doesn't run, or requires an engineer standing by — that itself is the review finding: there is no demo, so there is nothing to review. Reschedule. (See [demo-culture.md](demo-culture.md).)

## The agenda

A full review runs five steps, in order, typically 30–60 minutes:

1. **State the promise** (2 min) — what does this claim to do?
2. **Cold walkthrough findings** (10 min) — the reviewer's unguided experience
3. **Principle audit** (15–25 min) — simplicity, focus, how-it-works, whole experience, back of the fence
4. **Cut list** (10 min) — what gets removed
5. **Verdict** (5 min) — binary, with ranked fixes

The order matters. Teams instinctively want to open by presenting context, constraints, and effort invested. Don't allow it — context biases the review toward sympathy for the team rather than the customer's reality. Context gets airtime in step 5, when deciding what to do about the findings, not before.

## Step 1: State the promise

Ask the team for one sentence: *"What is this supposed to do?"* Write it down verbatim. Everything else in the review tests that sentence.

If the team can't produce the sentence — if they offer three sentences, or a paragraph with "and also" in it — the review has already found its first defect: the product lacks a One Thing, and no amount of polish fixes a product that doesn't know what it's for. Pause and resolve focus before reviewing execution (see [simplicity-and-focus.md](simplicity-and-focus.md)).

## Step 2: The cold walkthrough

The reviewer presents their unguided experience, chronologically: what they expected, what happened, where they hesitated, what they never found. The team's job in this step is to listen and take notes — not to explain, justify, or troubleshoot.

Every "oh, that's because…" from the team gets the same response: *the customer won't have you standing next to them.* An explanation that's necessary in the room is a redesign requirement in the product.

## Step 3: The principle audit

Walk the five quality lenses in order. For each, the questions to ask:

**Simplicity.** How many steps from entry to core value? What's on this screen that isn't serving its single intent? Which settings should be defaults? What requires explanation? ("If you must explain it, redesign it.")

**Focus.** Does every visible feature serve the promise from step 1? What's here because a stakeholder asked, rather than because the customer needs it? What would we cut if we could only keep three things?

**How it works.** Show the failure states: offline, error, empty, slow. Where does the user wait, and what happens while they wait? How does this feel on the 100th use? Does anything require a manual?

**Whole experience.** Walk the seams: the email that brought them here, the loading screen, the invoice, the support path, the cancellation. Who designed each? "Nobody" is a finding. (Full touchpoint method: [end-to-end-experience.md](end-to-end-experience.md).)

**Back of the fence.** Open the screens nobody demos — 404s, error toasts, settings, account pages. Read the copy aloud. Would the team sign their names inside this? (Case examples: [case-studies.md](case-studies.md).)

## Step 4: The cut list

Before any discussion of fixes or additions, force subtraction: *"What are we removing?"*

A review that ends with only additions has made the product worse — more scope, same deadline, no increase in focus. Healthy reviews remove something nearly every cycle: a redundant option, a low-traffic feature, a tier, a screen. If genuinely nothing can be cut, the team must defend each survivor in one sentence against the promise.

## Step 5: The verdict

End binary. The two allowed verdicts:

- **INSANELY GREAT** — ship-worthy as is. Rare by design; saying it when untrue devalues the standard.
- **NOT DONE** — accompanied by a ranked fix list, each item specific enough to act on without interpretation.

Banned verdicts: "good enough," "ship it and iterate" (without a named iteration), "just needs polish" (polish what, exactly?), and any verdict by vote. One decider owns the call; everyone else informed it.

## The output format

ALWAYS produce this artifact (whether the review is run by a person or an agent):

```
# Design Review: [Product/Feature]
**Verdict:** INSANELY GREAT / NOT DONE (score X/10)
**The One Thing:** [the promise, verbatim from step 1]
**Keeps its promise?** [yes/no + the evidence from the cold run]
**Steps to value:** [count, with the step list]
**Cut list:** [what to remove, why]
**Fix list:** [ranked; each item = what, where, why it fails, fix direction]
**Back of the fence:** [unseen surfaces below the bar]
**Next review:** [date + what must be demoable by then]
```

The fix list is the heart. Each item must pass the specificity test: could a team member start working on it without asking a clarifying question? "The onboarding is confusing" fails. "Step 3 asks for a credit card before showing any value; move payment after the first successful export" passes.

## Candor rules

Jobs' feedback was famously harsh — "this is shit" is the documented phrasing. What made it function was not the harshness but two properties that traveled with it: it was **about the work**, and it was **immediately specific**. Teams could act on it the same afternoon.

Adopt the function, not the cruelty:

- Say "this fails" freely; never say "you failed."
- Every harsh judgment must arrive with its reason and a fix direction in the same breath.
- No sandwiching, no softening into ambiguity — diluted feedback wastes everyone's time and ships mediocrity.
- Praise must be as specific as criticism, and rarer than the team would like. "Be a yardstick of quality. Some people aren't used to an environment where excellence is expected."
- If people leave reviews afraid to demo unfinished work, the review has broken its own feedback loop. Fear is a process defect.

## The MobileMe pattern: reviewing against the promise

When MobileMe launched broken in 2008, Jobs gathered the team and asked one question: *"Can anyone tell me what MobileMe is supposed to do?"* Someone answered correctly. His response: *"So why the f— doesn't it do that?"*

That exchange is the entire review method in two lines. The product was not judged against a spec, a sprint goal, or effort invested — it was judged against its own public promise. The accountability that followed (leadership was replaced on the spot) was severe, but the reviewing logic is universally applicable and kind to no one's ego:

1. State what the product promises.
2. Test whether it does that.
3. The gap is the review.

Use this pattern especially for launch readiness reviews and post-launch quality audits: read the marketing page, then test exactly what it claims, sentence by sentence.

## Saying-no rituals

Focus decays without ritual. Two to institutionalize:

**The top-3 cut.** Jobs' annual "Top 100" retreat ended with the group's ten best ideas on a whiteboard — and Jobs crossing out the bottom seven: "We can only do three." Run the same ritual quarterly: rank everything, draw the line at three, and treat everything below the line as explicitly *not happening*, not "later."

**The add-requires-kill rule.** Any feature added inside a cycle must name the feature, option, or screen it kills. This keeps total complexity flat and forces every addition to argue it's worth more than something that already exists.

## Review cadence

- **Weekly demo review** (30 min): working artifacts only, decider present, verdicts on the spot. This is the creative-selection loop (see [demo-culture.md](demo-culture.md)).
- **Milestone review** (60 min): full five-step protocol, cold run mandatory.
- **Launch readiness**: MobileMe pattern against the marketing copy, plus full back-of-fence audit.
- **Post-launch** (2–4 weeks after): re-run the cold walkthrough on the shipped product; compare against the launch review's promise.

## Anti-patterns

| Anti-pattern | What it looks like | Why it kills the review |
|---|---|---|
| The guided tour | Team drives, reviewer watches | First-impression data destroyed; demos hide what authors avoid |
| Context first | "Before you look, some background…" | Sympathy replaces customer reality |
| Spec review | Slides, mocks, docs — no artifact | Everyone approves a different imagined product |
| Consensus verdict | "Are we all comfortable shipping?" | Averages opinions into mush; nobody owns quality |
| The polish verdict | "Just needs a little polish" | Unactionable; "polish" hides unranked, unnamed defects |
| Effort empathy | "The team worked so hard on this" | Customers don't grade on effort |
| Fear theater | Reviewer performs anger | People stop demoing early work; the loop dies |

## Adapting the protocol

- **Solo founder / agent self-review:** run all five steps against your own work, but do the cold walkthrough after a real break (or have someone uninvolved do it). Write the output artifact anyway — the discipline of the binary verdict is the point.
- **Code review with UI changes:** require a running build or recording, never screenshots alone; apply steps 1–3 to the changed flow; the verdict gates merge.
- **Agency/client reviews:** the promise in step 1 comes from the client's brief; the MobileMe pattern keeps both sides honest about whether the brief was met.
- **AI agent as reviewer:** follow the protocol literally — state the promise, walk the artifact, audit the five lenses, output the artifact format. Never soften the verdict to be agreeable; the user asked for Jobs, not for applause.

# Simplicity and Focus: The Subtraction Disciplines

How to audit a product for simplicity the way Jobs did, and how to enforce focus with the no list, the 2×2 matrix, and steps-to-value measurement.

## Contents

- [Simplicity is conquered complexity](#simplicity-is-conquered-complexity)
- [The simplicity audit](#the-simplicity-audit)
- [Steps-to-value: the core metric](#steps-to-value-the-core-metric)
- [The defaults discipline](#the-defaults-discipline)
- [Deep simplicity vs. surface simplicity](#deep-simplicity-vs-surface-simplicity)
- [The Simple Stick](#the-simple-stick)
- [Focus: the 1997 lesson](#focus-the-1997-lesson)
- [The 2×2 product matrix](#the-22-product-matrix)
- [The no list](#the-no-list)
- [Killing shipped features](#killing-shipped-features)
- [Focus failure modes](#focus-failure-modes)
- [Applying subtraction to common surfaces](#applying-subtraction-to-common-surfaces)

## Simplicity is conquered complexity

Apple's first marketing brochure (1977) carried the line "Simplicity is the ultimate sophistication." Jobs' mature articulation, from the Isaacson biography, is more precise about the cost:

> "Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains."

And the operational version:

> "It takes a lot of hard work to make something simple, to truly understand the underlying challenges and come up with elegant solutions."

The key word is *underlying*. Simplicity that comes from understanding the problem deeply produces products that need no manual. Simplicity that comes from hiding complexity produces products that feel broken the moment a user steps off the happy path. A reviewer's job is to tell these apart.

## The simplicity audit

Run these checks against any screen, flow, or product:

1. **The one-sentence test.** Can the team state what this screen/feature/product does in one sentence? If the sentence contains "and also," it's two things wearing one UI.
2. **The element census.** List every element a user can see or interact with. For each: which intent does it serve? Elements serving no intent get cut; elements serving a *different* intent move elsewhere.
3. **The explanation test.** What requires a tooltip, a tutorial, an onboarding coachmark, or a docs link? Each is an apology for a design decision. Some are unavoidable (genuinely novel interactions); most are deferrable complexity that leaked to the user.
4. **The decision count.** How many decisions must a user make before getting value? Every modal, option, and "choose your plan" gate is a decision tax. (See [The defaults discipline](#the-defaults-discipline).)
5. **The deletion pass.** For each element, ask: if we removed this, what breaks? "Nothing" — cut it. "An edge case for 2% of users" — consider cutting it and solving the edge case elsewhere. Only "the core promise breaks" earns a place.

The audit's spirit is the famous iPod constraint: it shipped without an on/off switch. Not because the button was hidden, but because deep understanding (the device sleeps and wakes instantly) made the need itself disappear. The best subtraction removes the *need*, not the control.

## Steps-to-value: the core metric

Jobs gave the original iPod team a hard constraint: any song, reachable in three presses. The iDVD pitch was the same instinct — Mike Evangelist prepared detailed feature mockups, and Jobs walked to the whiteboard, drew a single window, and said: *"Here's the new application. It's got one window. You drag your video into the window. Then you click the button that says 'Burn.' That's it."*

Measure it literally in every review:

1. Define "value": the moment the user has the thing they came for (song playing, file exported, invoice sent — not "dashboard viewed").
2. Count every step from entry: each click, field, screen, decision, and wait counts as one.
3. Record the count in the review artifact, and track it across reviews like a performance budget.

Reduction tactics, in order of preference: remove the step entirely → make it a default → defer it until after first value → combine it with another step. Reordering steps is cosmetic; the count is what matters.

Typical findings: registration before value (defer it), plan selection before product experience (default to trial), configuration screens on first run (opinionated defaults), confirmation dialogs guarding recoverable actions (make actions undoable instead).

## The defaults discipline

Every setting is a decision the team failed to make. Settings feel generous — "let users choose!" — but each one:

- Moves a design decision onto someone with less context than the team
- Doubles the QA surface (every option × every other option)
- Becomes a place where bugs hide and back-of-fence neglect accumulates

The review questions: *Which of these settings would we remove if we had to defend each one? What's the right answer for 95% of users — and why isn't that just the behavior?* A setting earns its place only when user contexts genuinely diverge (timezone, language, accessibility) — not when the team couldn't agree.

## Deep simplicity vs. surface simplicity

Ken Segall's distinction, sharpened for reviews:

| | Surface simplicity | Deep simplicity |
|---|---|---|
| Method | Hide controls in menus, "advanced" panels | Remove the underlying need |
| First impression | Clean | Clean |
| 100th use | Frustrating — everything is two levels deep | Still effortless |
| Failure states | Confusing — hidden complexity erupts | Graceful — complexity was actually solved |
| Example | Burying sync conflicts in a settings pane | Sync that resolves conflicts correctly without asking |

Surface simplicity is how teams game a simplicity review. Catch it by auditing the 100th-use experience and the failure states, not the first-run screenshots — minimalism is how it looks; simplicity is how it works.

## The Simple Stick

Inside Apple's marketing org, Segall reports, people described being "hit with the Simple Stick" — Jobs rejecting work for being too complicated: too many words, too many ideas, too many products in one ad. The Simple Stick applies one idea per artifact:

- One message per ad, one idea per slide, one intent per screen, one primary action per view
- Naming: products got names a person can say aloud ("iMac", not "MacMan 3000 Pro DX")
- Copy: if a sentence can lose a word, it loses it

In reviews, the Simple Stick is the moment the reviewer says: "This is three ideas. Pick one." It is the most common and most resisted verdict — every idea has an internal advocate — which is exactly why the review must deliver it.

## Focus: the 1997 lesson

When Jobs returned in 1997, Apple sold dozens of overlapping products — multiple Performa lines, Quadras, printers, the Newton — and was weeks from insolvency. His diagnosis, delivered to the product teams, was that he couldn't tell his friends which Mac to buy; his fix was to cancel ~70% of the product line. Thousands of engineers' work, killed — not because it was bad, but because it was *unfocused*.

The documented principle, from WWDC 1997:

> "Focusing is about saying no."

And later, expanded:

> "People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things."

The review insight: focus problems never look like focus problems from inside. They look like "serving more customer segments," "competitive parity," and "quick wins." The reviewer's job is to ask what the hundred good ideas currently in the product are costing the three great ones.

## The 2×2 product matrix

Jobs' replacement for Apple's sprawl was a grid on a whiteboard:

| | Consumer | Pro |
|---|---|---|
| **Desktop** | iMac | Power Mac |
| **Portable** | iBook | PowerBook |

Four products. Every project mapped to a cell or died.

Generalize it in reviews of product lines, pricing tiers, and plan structures:

1. Find the two axes that actually distinguish your customers (not the ones that distinguish your teams).
2. Draw the grid. Place every product/tier/SKU in a cell.
3. Two things in one cell → merge or kill one. A thing in no cell → kill it. An empty cell → that's the roadmap.

If the team needs more than four cells, make them defend each axis. Usually one "axis" is an internal org boundary leaking into the catalog.

## The no list

Focus is invisible unless you write it down. Maintain a **no list**: things the product deliberately does not do, with one-line reasons. Review it alongside the roadmap.

- "We don't do per-seat permissions — we serve small teams who trust each other."
- "We don't have an API — we are the integration, not the platform."
- "No dark mode until the core flow is 10/10."

The no list converts saying no from a per-meeting fight into standing policy. New requests get checked against it; changing it requires a deliberate decision, not attrition. In reviews, ask to see the no list. A team that can't produce one isn't focused — it just hasn't been asked for everything yet.

The companion ritual is the **top-3 cut** from Jobs' "Top 100" retreats: rank the ten best ideas, then cross out seven. Three priorities is a strategy; ten is a wish list. (Session mechanics: [review-protocol.md](review-protocol.md).)

## Killing shipped features

The hardest subtraction is retroactive. Shipped features have users, internal advocates, and sunk-cost gravity. But a product that only adds becomes the complexity it once disrupted.

Review questions for every existing feature, annually: What % of users touched this in 90 days? What does it cost (code, QA, UI surface, support, onboarding attention)? Would we build it today? If "no" — schedule the deprecation, communicate honestly, and take the one-time pain over the permanent tax.

Jobs' versions were famously abrupt — killing the floppy drive (iMac, 1998), the optical drive, Flash support, and eventually whole product lines like the iPod mini at its sales peak, to make room for the nano. The lesson isn't the abruptness; it's that he treated removal as a *product feature* that buys simplicity, speed, and room for the next thing.

## Focus failure modes

| Failure mode | Symptom | Subtraction fix |
|---|---|---|
| Stakeholder accretion | Features traceable to internal requests, not user jobs | Every feature names the customer job it serves, or dies |
| Competitive checklist | Roadmap mirrors competitor's feature page | Compete on the One Thing, not on parity |
| Segment greed | "Enterprise needs X, prosumers need Y, students need Z" | Pick the 2×2; serve cells you can win |
| Quick-win addiction | Many small ships, core flow unchanged for quarters | Cap quick wins; reserve majority capacity for the One Thing |
| Roadmap as archive | Nothing has been cut in living memory | Quarterly top-3 cut; visible kill log |

## Applying subtraction to common surfaces

- **Landing page:** one message, one CTA. Every additional section must defend itself against scroll-depth data.
- **Onboarding:** defer every question that can be answered with a default. Aim: value before account where legally possible.
- **Navigation:** if it needs a "More" overflow, the IA has failed the one-sentence test per section.
- **Pricing:** tiers map to the 2×2; if customers need a comparison table with 30 rows to choose, the structure is the problem.
- **Settings page:** treat as a defect backlog — each entry is a decision to revisit, not a feature.
- **Feature flags / experiments:** expiry dates mandatory; flags older than two quarters are unmade decisions compounding.