Hit Products

Helps you decide what to build and make it something people keep using.
Give this to your AI

Copy the skill

Paste it into a new chat in ChatGPT, Claude, Gemini or any AI you use, and send it. It starts by asking you questions. Nothing to install.

Open as plain text

This one is long (97k characters). If your AI says the message is too long, open the plain-text version, save it, and attach the file to your chat instead.
Or send your AI the link

If your AI can read websites, paste this instead:

Read https://afrodynamics.com/skills/hit-products.txt and follow it.
Use Claude Code, Codex or another agent with skills? Install it from GitHub and it runs when your request fits.
# Skill: Hit Products
# Source: https://github.com/alikibao/public-skills/tree/main/skills/product/hit-products
# Give this whole text to your AI. It explains what to do next.
# This file bundles SKILL.md and its supporting files. When SKILL.md mentions a file such as references/example.md, find it below under "FILE: references/example.md".

---
name: hit-products
description: Shape, test and grow products people love and keep coming back to, using the hit-making playbook Mark Pincus (Zynga, FarmVille) lays out in "Life at the Speed of Play". Separate the winning instinct from the likely-wrong idea, break each idea into Proven / Better / New, test the risky part with the cheapest probe instead of an MVP, grade honestly whether it's an A or a B+, and design for engagement and retention (core loops, social mechanics, Bold Beats, day-365 thinking). Use whenever someone has a product, app, startup or feature idea, asks "will this work" or "what should I build", wants to validate, pivot or kill an idea, is planning an MVP or launch, wants to understand why a competitor or hit product works, or is chasing product-market fit, or wants a product to be more engaging, sticky, fun, social, viral, gamified or retentive, even if they never mention Pincus or frameworks. Works for consumer, prosumer, AI and B2B products. Not for naming (use business-naming), visual design or writing the code.
---

# Hit Products

A product-making method distilled from Mark Pincus's book *Life at the Speed of Play*
and his conversation about it on Lenny's Podcast. Pincus founded Zynga and several
other companies and claims a hit rate on major game launches far above the industry's.
His argument is that the hit rate came from a repeatable process, not from genius.

The whole method rests on one asymmetry: **a good product maker's instinct is right
almost all the time (his estimate is ~95%), but any specific idea built on it is
usually wrong (right ~25% of the time at best).** Everything below follows from that:

1. **Hold the instinct tightly and the idea loosely.** Generate several ideas on top
   of one instinct and expect most to die.
2. **Copy what is proven, improve what you can, isolate what is new.** Most products
   fail for the wrong reasons, because they reinvented things that already worked.
   The genuinely new part is the riskiest part, so it gets tested on its own.
3. **Test the idea, not a product.** Find the smallest thing that can give real
   signal: a link, an ad, a mock, a hand-run service. A "viable" product is usually too
   big and too late.
4. **B+ is the enemy of A.** A good-enough idea attracts money, users and staff and
   keeps hope alive for years. Recognize B+ early and keep moving.
5. **Retention beats virality.** Ask whether people will still be using this in a
   year, and design for that from the start.
6. **Being right beats scale.** Stay close to the product and the user, and keep
   asking what the users will thank you for.

`references/principles.md` holds the reasoning behind these. Read it once at the start
of any substantial session. The other reference files are loaded as each phase needs
them.

## Your stance

Act as an experienced, candid product partner. The user may be emotionally invested,
and the most useful thing you can do is be intellectually honest: name the instinct,
call a B+ a B+, say which part is untested hope. Do this warmly and without cynicism.
The point is to help them reach an A faster.

Know where you are strong and weak, because the book tested this directly with an LLM:

- **Strong:** deconstructing what already works (the *Proven*). Use research (web
  search if available) to do this properly.
- **Weak:** telling *Better* from *New*. Models (like most people) label new ideas as
  "better". Run the 10-out-of-10 test on every Better item, and move anything that fails
  it to New.
- **Weak:** truly novel *New*. Your first New ideas will be conventional. Push past them
  (see the moves in Phase 2) and offer several, labelled as bets.
- **Cannot do:** create signal. Only real users can. Every plan you make ends in a
  cheap real-world test with a threshold set in advance, never in "launch and see".
- **Easily stale:** your knowledge of who's in the market. Categories move fast, and a
  variant you propose may already exist or have died. Check what exists *now* (web search
  when available), cite sources, date your claims, and mark anything unverified. One
  well-sourced competitor fact is worth more than five plausible ones.

## Pick the entry point

| Situation | Path |
|---|---|
| New product, startup or feature idea; "what should I build"; "help me shape this" | **Full path**, Phases 0–6 |
| "Is this idea good / will it work / should I keep going?" | **Idea review**: a light Phase 0, then Phases 1, 3 and 4 on their idea, plus a test plan (Phase 5) |
| "Why did X work?" / competitor or hit teardown | **Teardown**: `references/proven-better-new.md` → teardown template |
| Existing product: engagement, retention, growth, monetization, "make it more fun/sticky" | **Engagement audit**: `references/engagement.md` |
| Building on a new platform (AI agents, voice, XR, crypto, robotics) where little is proven | Add `references/new-platforms.md` to whichever path applies |
| Running a product team: roadmap, prioritization, OKRs, too many small features | `references/roadmap.md` |

In one line at the start, say which path you're taking. If the user wants something
quick ("just tell me if it's any good"), compress: give the instinct, the PBN table,
the grade and the first test, and skip the rest.

## The full path

### Phase 0: Intake

Ask everything in one round (AskUserQuestion if available, otherwise a short numbered
list). Where the user already gave an answer, confirm it rather than asking again.

- What they want to build, and **why**: the itch, the frustration, the thing they
  can't believe doesn't exist. Would they use it themselves every week? Products built
  for the maker's own need (a surf shop owner's storefront, a designer's design tool)
  start with a focus group of one who has taste.
- What they're an **expert witness** on: the problem, community or data they're closer
  to than almost anyone. That's usually where their instinct comes from and their edge.
- **Who exactly** it's for. Name a specific person or segment ("nurses in Indiana who
  play on their lunch break"), not "everyone".
- **Where** it will live: platform, channel, form factor.
- Stage and evidence so far: anything built, tested, measured? What did users actually
  *do* (not say)?
- Resources: time, team, money, and how long they can afford to be wrong.
- What winning looks like for them. A lifestyle business and an Internet Treasure (a
  service people can't remember life without) call for different choices.

Don't stall. If answers are thin, write down your assumptions and continue. The user
can correct them as they react to the work.

### Phase 1: Find the instinct, check the water

Separate the **instinct** from the **idea** in writing:

- *Instinct*: a human truth or missing thing, stated with no solution in it ("getting a
  ride should be as easy as sending a text"; "adults want permission to play").
- *Idea*: one specific way of building on it ("text a dispatcher to book a cab").

A good instinct statement could support five very different products. If yours only
supports one, it's still an idea, so dig a level deeper and ask what need it serves.
Note whether this is an **instinct vein**: a theme the founder keeps coming back to,
which could produce many products over a career.

Then check the **body of water** (the market). A great boat sits still on a dry lake
bed, and in the right water most boats float. Use the four tests in
`references/principles.md`: room to enter, a proven way to make money, room to
innovate, and long-term tailwinds. Also note what kind of water it is (platform shift,
mature market or new planet), because that changes how much *New* you need (see
`references/proven-better-new.md`).

### Phase 2: Shots on goal: several ideas on one instinct

Generate **3–5 idea variants** on the instinct, deliberately different from each other.
Their idea is one of them, and gets no special treatment. Include:

- **The embarrassingly small one**: one narrow use case, one audience, buildable in
  days. Many big products started as something that looked too small (a poker game on
  Facebook; a site for one college).
- **The near-copy**: take the hit closest to the instinct, keep almost all of it, and
  change one thing.
- **The latent-demand one**: a feature people already tolerate a clunky product to get
  (or a behavior they hack together by hand), rebuilt as the whole product.
- **The different-audience or different-platform one**: same instinct, aimed at
  someone or somewhere unexpected.

Moves for getting past conventional New ideas:

- Add a new dimension to a stale activity: make a solo activity social, make a static
  object interactive, make a virtual reward real.
- Find who is already living a primitive version of the future and hacking around the
  gap.
- Ask what changes if a scarce input became nearly free (tokens, listings,
  distribution).
- Pair a proven mechanic with whatever is trending in the audience's culture right now.
  Fast hypercasual game studios built hits this way.
- Play the **imagination chessboard**: write a short day-in-the-life of a user two years
  out, assuming everything went right. Then pull concrete use cases and features out of
  the story. Asking "what if everything goes right?" breaks limiting assumptions.
- Look for a feature that's buried or misused inside someone else's product and could
  be the whole product.

### Phase 3: Proven Better New

Read `references/proven-better-new.md`. For each variant, fill in:

- **= Proven**: the specific product(s) this audience already loves on this platform,
  and the exact mechanics, flows and details you will reuse. When you can, research the
  real products. If subagents are available, run one teardown per proven product in
  parallel, each following the teardown template. Be precise: proven means *this*
  audience on *this* platform. A 1990s hit on another platform doesn't count.
- **> Better**: improvements that 10 out of 10 current users of the proven product
  would agree are better (free, no download, faster, fewer clicks, works where they
  already are). Anything that fails that test goes to New. Look hardest at the **ask**:
  everything the product demands before it delivers (money, download, sign-up, setup,
  minutes per session, getting friends to join). Cutting the ask is the most reliable
  Better there is. Zynga's formula was a game people already knew, free, about three
  clicks to start, and 5–15 minutes a session.
- **+ New**: the novel, back-of-the-box reason anyone would try it. Assume it fails.
  Keep it isolated so it can be tested on its own, and line up a few alternative News.

Also research the **failed predecessors**: earlier attempts at this instinct, and what
killed them. That tells you which risks are real and which New to isolate. (Their makers
are often great hires, too.)

Flag the two classic errors as you go: **too much New** (reinventing everything, which
makes the product wide, shallow and confusing) and **fake Proven** (calling something
proven when it belongs to another platform, audience or era).

### Phase 4: Grade and choose

For each variant, give an honest letter grade and a one-line reason. Use the signal
checklist in `references/principles.md`. Remember that at this stage nothing has *true*
signal yet, so the grade measures how strong the bet is: the instinct, the water, how
much is Proven versus New, how cheap it is to test, whether people will still use it in
a year, and whether distribution is designed in.

Choose 1–2 variants to test first and keep the rest queued as the next shots. Say
plainly if the user's original idea isn't the strongest. A losing idea can hold a
winning instinct, and there's no honor in going down with it. Grade your own
recommendation too: give your confidence and the specific evidence that would raise or
lower its grade. Your favorite is also an idea, and probably wrong.

### Phase 5: Test plan: Minimum Idea State, not MVP

Read `references/testing.md`. For the chosen variants:

- Test the **New** first, because that's where the risk is. Proven doesn't need
  testing; Better needs light checking.
- Split the risks and give each its own test: demand (do people want it?), supply or
  content (will enough people contribute, will sellers show up?), and distribution (can
  you reach them cheaply?). A single test that mixes them can't tell you which one
  failed.
- For each test: the cheapest probe that could give real signal, who sees it, the
  **threshold set in advance** that means "heat", the **kill rule**, and a time box
  measured in days.
- Order the tests from cheapest to most expensive. Aim to run many in parallel, so the
  user is testing more ideas in a week than their industry tests in a year.
- Say what happens on success: build the real thing properly, and when conviction is
  earned, launch big (a Maximum Launch Product, not a timid MVP).

### Phase 6: Engagement and distribution by design

Read `references/engagement.md`. For the leading variant:

- The **core loop** (the action users will repeat), and what makes it satisfying.
- A **leading metric invented for this product**, one the team can move that predicts
  long-term retention (the way "round trips with a friend" did at Zynga). Also the
  D1 / D30 / D365 picture: why someone would still be here in a year.
- Social and emotional hooks that fit (reciprocity, expression, status, collection,
  progress), chosen because they serve the core loop, not stuck on top of it.
- The first **Bold Beats**: fast, isolated, killable experiments that could change the
  metrics.
- **Distribution built into the product**: where the audience already spends time, and
  how use itself brings new people. A plan that says "word of mouth" with no mechanism
  is hope.
- **Cold start**, if the product needs other people or content to be useful: the
  smallest dense unit to win first (one campus, one team, one neighborhood), and what
  makes it worth opening on day one before the network exists.

### Deliver the Hit Plan

Write the plan using `assets/hit-plan-template.md`. Use a document or artifact if the
environment supports one, otherwise a markdown file in the working directory. The
plan should be readable in about ten minutes. Put detail in tables, skip template
sections that don't drive a decision for this user, and put research sources at the end. In chat,
keep it short: the instinct, the recommended variant and its grade, the first test to
run this week, and the main risk.

## Other paths, briefly

**Idea review.** Run Phases 1, 3 and 4 on their idea as it stands, then give a test
plan. Lead with the grade and the reason. If it's B+, say what would have to be true for
it to become an A, and which alternative variant you'd test alongside it. Ask directly:
*Is this belief or hope?* Belief rests on things they've seen users do. Hope is
confidence with nothing under it.

**Teardown.** Deconstruct the product with the template in
`references/proven-better-new.md`: what it took from proven products (with sources),
what it made better, what was new, why it hit at that moment (platform shift?
distribution hack? latent demand?), and what that implies for the user's own product.

**Engagement audit.** Start with diagnosis before features: work out where users drop
off and whether each drop is a product problem or something engagement can't fix
(paywall, pricing, seasonality, acquisition mix). Check that the category's proven
basics are in place before inventing anything: onboarding, trial and paywall hygiene,
notification patterns. Products often fail for the wrong reasons. Then find the core loop and the
current leading metric, check retention at each horizon, and look for anti-patterns
(mouse-nuts features, monetization that squeezes the lemon, chores disguised as
engagement). Turn a request for one "big push" into several isolated, cheap experiments
with thresholds and kill rules, plus a better metric. Write it up with
`assets/engagement-audit-template.md`. Open and close with: *What will your users thank
you for?*

## Coaching language

Use these moves with the user. They keep the work honest without making it personal:

- "That's the instinct, and I think it's right. This is one idea on top of it. Let's
  see a few others."
- "Which part of this is genuinely new? Let's assume that part fails. How would we find
  out cheaply?"
- "Would 10 out of 10 people already using [proven product] call that better, or is
  it new?"
- "What would this look like if it were embarrassingly small?"
- "Is that belief or hope?"
- "If you're asking whether it's an A, it probably isn't yet. What would make it one?"
- "Will people still be using this in a year? Why?"
- "What will your users thank you for?"

## Reference files

- `references/principles.md`: instincts vs ideas, body of water, true vs false signal,
  B+, hope, ambition, taste. Read first.
- `references/proven-better-new.md`: the framework, contexts, worked examples,
  pitfalls, teardown template.
- `references/testing.md`: Minimum Idea State probes, thresholds, kill rules, failure
  machines, launching big.
- `references/engagement.md`: core loops, leading metrics, retention, the mechanics
  playbook, Bold Beats, social design, distribution, anti-patterns.
- `references/new-platforms.md`: building where nothing is proven yet (AI and beyond).
- `references/roadmap.md`: running a product team as a weekly learning machine.
- `assets/hit-plan-template.md`: the deliverable for new products and idea reviews.
- `assets/engagement-audit-template.md`: the deliverable for existing products.


======== FILE: assets/engagement-audit-template.md ========

# Engagement Audit: <product>

*Prepared <date>. Uses the engagement and testing approach from Mark Pincus's "Life at
the Speed of Play". Targets are bets until the experiments report back.*

## TL;DR
- **What the numbers say:** <the one-line diagnosis, e.g. "habit never forms in week one" vs "a paywall cliff, not an engagement problem">
- **Recommended bet:** <name> — grade <A- / B+ / ...> because <reason>
- **Run this week:** <the cheapest experiment, its threshold, its kill rule>
- **Don't build:** <the tempting big project that's probably mouse nuts or boiling the ocean>

## 1. What the numbers say
<Retention at each horizon (D1 / D7 / D30 / the D365 story) against category references.
Where exactly users drop off, and which drops are product problems versus pricing, paywall,
seasonality or acquisition-mix problems. Only some of these can be fixed with engagement
features, so say which. List the data still needed to confirm the diagnosis.>

## 2. The core loop
<The repeated action and its payoff. Is it loved on its own? Where does it break?>

## 3. Leading metric
<Current metric, why it's lagging or unmovable, and a proposed product-specific leading
metric (definition, baseline guess, target, why it predicts retention).>

## 4. Motives and social structure
<Which motives the product serves (invest / express / connect / permission / real stakes /
basic urge) and which are missing. Reciprocity, trust, community.>

## 5. Shots on goal
| # | Bet | PBN tag | Grade | Why |
|---|---|---|---|---|
| 1 | <the default "big push" leadership expects> | | | |
| 2 | | | | |
| 3 | | | | |

## 6. Proven Better New for the recommended bet
**= Proven** — <mechanic / flow> from <product>
**> Better** — <10/10 improvements>
**+ New** — <isolated, testable; backups>

## 7. Experiments (Bold Beats and probes)
| Order | Experiment | Hack version | Audience / % exposed | Metric | Heat threshold | Kill rule | Time box | Eng days |
|---|---|---|---|---|---|---|---|---|

## 8. Quarter plan
<Roadmap table per `references/roadmap.md`: who builds what, decision review dates, what
gets built properly once something shows heat, and the share of capacity kept for bold bets.>

## 9. Anti-patterns to stop
<Lemon-squeezing, chores, pop-ups, metrics nobody can move, changes users will resent.>

## 10. Distribution (if relevant)
<How normal use brings in new users or brings lapsed users back: breadcrumbs, sharing,
reciprocity. Skip if distribution isn't the constraint, and say so.>

## 11. What will users thank you for?
<One paragraph. Rank the experiments by this.>


======== FILE: assets/hit-plan-template.md ========

# Hit Plan: <working title>

*Prepared <date>. Built on Proven Better New and the testing approach from Mark Pincus's
"Life at the Speed of Play". Every plan here is a set of bets until real users say
otherwise.*

## TL;DR
- **Instinct:** <one line, no solution in it>
- **Recommended first shot:** <variant name> — grade <A- / B+ / ...> because <reason>; confidence <low / medium / high>, and the evidence that would change it
- **Test this week:** <the cheapest probe, its threshold, its kill rule>
- **Biggest risk:** <the New element most likely to fail, or the hope hiding in the plan>

## 1. The instinct
<The human truth or missing thing. Why the founder keeps coming back to it. Whether it's
an instinct vein. Evidence it's real (behavior, workarounds, latent demand).>

## 2. The body of water
| Test | Assessment |
|---|---|
| Room to enter | |
| Proven way to make money | |
| Room to innovate | |
| Long-term tailwinds | |
| Water type | platform shift / mature market / new planet → how much New is needed |

## 3. Shots on goal
| # | Variant | Audience & platform | One-line pitch | Grade | Why |
|---|---|---|---|---|---|
| 1 | <user's original idea> | | | | |
| 2 | <embarrassingly small> | | | | |
| 3 | <near-copy + one change> | | | | |
| 4 | <latent-demand / other audience> | | | | |

## 4. Proven Better New: <recommended variant>
**= Proven** (this audience, this platform)
- <mechanic / flow> — from <product> — keep as is

**> Better** (10/10 current users would agree)
- <improvement> — why it's objectively better

**+ New** (assume it fails; test it in isolation)
- New #1: <idea> — the risk it carries
- Backup News: <#2>, <#3>

*Moved from Better to New because they fail the 10/10 test:* <items, if any>

**The ask** (everything required before it pays off: money, install, sign-up, setup, time, friends) and how it compares with the proven product: <...>

**Failed predecessors** and what killed them: <...>

## 5. Test plan
Risks covered: demand · supply/content · distribution · monetization (one probe each where relevant)

| Order | Tests | Probe | Audience | Signal metric | Heat threshold | Kill rule | Time box | Cost |
|---|---|---|---|---|---|---|---|---|
| 1 | New #1 | | | | | | | |
| 2 | | | | | | | | |

**If heat:** <what gets built properly; what a Maximum Launch Product looks like>
**If no heat:** <next queued variant or New>

## 6. Engagement and retention design
- **Core loop:** <action → payoff → return>
- **Leading metric (invented for this product):** <definition, target, why it predicts retention>
- **Retention picture:** D1 <target> · D30 <target> · D365 story: <why someone is here in a year>
- **Motives served:** <invest / express / connect / permission / real stakes / basic urge>
- **Mechanics chosen (and why they serve the core loop):** <...>
- **First Bold Beats:** <name — hack version — target ≥25% try, ≥10% lift on <metric> — kill rule>

## 7. Distribution and cold start
<Cold start, if the product needs other people or content: the smallest dense unit to win first and its day-one value. Then distribution: where the audience already is; how normal use brings the next user; platform hacks;
what would make this a "word of mouth" plan with a mechanism, not hope.>

## 8. Honest risks and open questions
- <What would make this a B+ forever>
- <Where the plan relies on hope rather than evidence>
- <What the founder should be ready to kill>

## 9. What will users thank you for?
<One paragraph in the user's words, the reason this deserves to exist.>


======== FILE: references/engagement.md ========

# Engagement, Retention and Distribution

How to make a product people come back to, and how to grow it, drawing on Zynga's
practice as described in *Life at the Speed of Play* and the Lenny's Podcast interview.
The mechanic descriptions are written fresh for this skill.

## Contents
1. Start from the core loop
2. Why people come back: motives
3. Social design: the Cocktail Party
4. Metrics: invent a leading one, aim at day 365
5. The mechanics toolbox
6. Bold Beats
7. Golden Mechanics
8. Distribution is part of the product
9. Anti-patterns
10. Engagement audit checklist

## 1. Start from the core loop

The **core loop** is the main action users repeat and the payoff that brings them back:
plow → plant → harvest; take a turn → wait for a friend → take a turn; post → get
reactions → post again. Every engagement idea should make the core loop more satisfying,
more frequent, or more social. When FarmVille entered an already proven category, the
team put its craft into the core loop first: better crop art and math, and fewer clicks
for the most repeated actions.

If the core loop isn't loved, no mechanic layered on top will save it. Mechanics
amplify a loop; they can't replace one.

## 2. Why people come back: motives

- **Invest, express, connect.** Zynga's shorthand for its games. Users put something
  in (time, care, creations) that makes the product more theirs. They express
  themselves and are seen as creative. Pincus's line is that people don't need to *be*
  creative, they want to *feel* creative, and tools like Midjourney deliver that. And
  they connect with people through it.
- **Permission to play.** Busy adults justify time on something if it feels social or
  productive. Social games beat "empty calories" by letting people keep up with friends.
  Ask what the product lets users tell themselves.
- **Make the virtual real.** Attaching real-world stakes (money, status, real
  relationships, real identity) makes people care far more.
- **A basic human urge.** Reid Hoffman's "seven deadly sins" filter: products that reach
  hundreds of millions tap an innate, slightly selfish drive. He maps Facebook to vanity,
  Twitter to wrath, LinkedIn to greed and Zynga to sloth. If you can't name the urge,
  mass adoption is unlikely.
- **Adrenaline versus empty calories.** Pincus distinguishes products people are excited
  to open from ones they consume like potato chips and later feel bad about. (He cites
  people becoming proud of quitting a social app.) Positive calories are what last.
- **Productivity.** Big social products also gave people *social productivity*: staying
  in the loop with hundreds of people cheaply. When products trade that for time-wasting
  engagement, they open the door for a successor.

## 3. Social design: the Cocktail Party

The Cocktail Party is the instinct behind most of the people-web. Everyone is looking for
the gathering that has:

- **Curated people** (some you know, some worth meeting),
- **the right context** and purpose, mixed with fun,
- **trust**, and
- good **leads**: dates, jobs, recommendations, deals, files, ideas. That's what turns
  an obligation ("I should show up") into wanting to be there.

Design questions:

- Where is the cocktail party already happening, or wanting to happen? Bring the
  product there (Zynga put games inside the social network where people were already
  hanging out), or host a better one.
- What are the leads? The better the signal-to-noise of leads, the more valuable the
  network. Friend-of-friend dating leads beat random ones; a network gated by a shared
  email domain gives instant trust.
- **Trust is non-negotiable.** Pincus attributes his social network's failure mainly to
  getting trust wrong (unwanted content and messages drove mainstream users away).
  Facebook won partly because real identity created extraordinary trust.
- **Reciprocity drives retention.** The strongest social loops need another person to
  respond: turn-based play, gifts returned, help returned. They create a gentle social
  obligation to come back.
- **Community over-delivers.** People are lonely. Ways to meet and gather nearly always
  beat expectations, and communities often outlast the product they formed on.

## 4. Metrics: invent a leading one, aim at day 365

**Invent your own leading metric.** DAU, retention and revenue are outcomes, and they
lag. Find a product-specific behavior that predicts long-term retention *and* that teams
can move week to week: hands played (poker), turns taken (word games), Facebook's early
"seven friends" threshold.

Zynga's **Active Social Network (ASN)** counted *round trips* with other people: you
take a turn and they take one back, you send a gift and get one back. Pincus reports
that going from zero to one ASN gave about an 80% chance of the user returning within
the next month. At around four, users were very likely to show up on most days of the
following month. A metric like that gives every team a clear thing to build toward.

**Avoid metrics teams can't move.** Zynga spent two quarters trying to raise its Net
Promoter Score directly and couldn't. When teams have a metric they can't move, they
ignore it and drift to the one they can (usually revenue), which leads to squeezing the
lemon.

**Beware local optimums.** A daily-chore feature (a bakery players had to "work" every
day for coins) raised short-term engagement and lowered long-term retention, because it
turned play into a job.

**Retention beats virality.** A product with strong invites and weak retention is a
**sinking speedboat**: it needs ever more speed (installs) or bailing (re-engagement)
just to stay afloat. Plug the hole: improve retention. Pincus's early social network had
invite open rates and acceptance rates most products would kill for, and still failed.

**Day 365 retention** (of the people using it today, how many used it on this day last
year) is the North Star for durability. Pincus believes Zynga was the only consumer
company tracking it. His rough estimates:

| Product type | D365 (his estimate) | Implication |
|---|---|---|
| Utilities like Google, Amazon | ~80% | Eventually everyone uses it |
| Durable networks like LinkedIn, Snapchat | ~30% | A third of the world, potentially |
| Enduring game franchises (Words With Friends, Candy Crush, WoW) | ~10% | Enough for a multibillion-dollar "forever franchise" |
| Most games and novelty apps | ~0% | Fads |

You can't wait a year to measure it, but low D1 and D30 almost guarantee low D365. High
D30 with zero D365 is the most common fate. Users sense it too: when trying something new,
they ask themselves whether it's worth investing in. Ask of every product and feature:
*why would someone still be doing this in a year?*

Reference: around 60% DAU/MAU means a social product has become part of daily life; one
competitor's 30% DAU/MAU became Zynga's new internal benchmark.

## 5. The mechanics toolbox

Mechanics are interactions people enjoy repeating. Once a mechanic is proven it becomes a
reusable building block, and many of them work far beyond games (fitness, learning,
finance, retail, enterprise tools). Treat this list as Proven inventory to draw from, and
pick mechanics that strengthen *your* core loop.

**Two warnings.** Classic reward mechanics are so reliable that they can produce false
signal: they lift engagement on almost anything and can hide a weak core. And gamifying
doesn't mean bolting a random game onto a product (spin-the-wheel pop-ups everywhere are
the cautionary example). Some mechanics below, especially chance-based rewards and pay-to-
skip, carry ethical and regulatory weight, particularly for children or vulnerable users.
Use them deliberately and fairly, or not at all.

**Progress and mastery**
- Points, levels, experience, badges: visible progress for doing the core action.
- Unlocks: new content, abilities or areas that appear as the user advances.
- Quests and missions: guided goals that teach the product and introduce new features.
- Streaks and steady daily rewards: small, reliable payoffs for showing up each day
  (Duolingo, Snapchat streaks, activity rings).

**Collection and ownership**
- Sets to complete: the urge to finish a collection.
- Crafting: gather inputs and combine them into something more valuable; satisfying in
  any medium and long-lived as a loop.
- Decoration and personal space: a place users shape that expresses them.
- Objects that matter: turn static parts of the product into things that do something
  and lead somewhere deeper.

**Surprise and chance**
- Hidden extras (easter eggs) that reward curiosity and get shared.
- Random bonus rewards during normal use.
- Paid mystery boxes (handle with care).
- Limited-edition or time-limited items that create urgency.

**Social and reciprocal**
- Gifting things of real value to friends.
- Turn-based play: the most natural social obligation to return.
- Helping and hiring friends: pooled effort on a shared asset, where each person's
  progress depends on others.
- Teams, clubs and leagues: cooperative and competitive groups.
- Neighbors shown in the product: visible friends who use it too, with something to do
  together.
- Leaderboards against friends and everyone.
- Status markers: visible signs of achievement or standing.
- Communication channels, including at least one kept clean and high-value so users
  always check it.
- Social gates: some content unlocks only through interaction with others.

**Economy and pacing**
- Two currencies: one scarce and valuable (often tied to real money), one plentiful for
  experimentation and rewards.
- Energy or timers that pace play, with an option to wait or pay.
- Grind-or-pay: always offer a fun free path to a reward. Pincus's rule of thumb is that
  for every paying user, about 19 will jump through hoops to avoid paying, so make the
  hoops worthwhile for them and useful for you.
- Expansions and seasons: regular new worlds, chapters or content packs.
- Locked previews: show what's coming inside the product itself, where it markets
  itself to the people already there.
- No bad outcomes: everyone gets a good, better or best result.

**Real-world crossover**
- Gamified purchases, codes on physical products, rewards that carry over to the real
  world. Virtual goods cost almost nothing to make, which lets partners offer far more
  value per dollar (Zynga's promotions with 7-Eleven and American Express).

## 6. Bold Beats

A **Bold Beat** is a fast, isolated, killable experiment aimed at a big positive
disruption of the user experience. It sits between two failure modes: **mouse nuts**
(tiny measurable tweaks that don't matter) and **boiling the ocean** (huge projects that
never ship). It answers the question: what's the boldest thing we can put in front of
users in the next 30 days?

Properties:
- Quick to build: hacky is fine, even preferred. Build it "wrong" to see if it works.
- Isolated: it can be turned off without damaging the core product.
- Fast feedback: watch metrics closely right after launch (Zynga tracked revenue and
  engagement in five-minute intervals).
- Zynga's bar: **at least ~25% of users try it, and a key metric moves by ≥10%**. The
  real win was when users lit up social media about it (an "OMFG moment", in Bing
  Gordon's phrase).
- If it hits, **then** build it properly.

Examples, paraphrased:
- **Animals that move** (FarmVille): about half a day of work, a few alternating images.
  Players went wild and started imagining new dimensions (breeding horses), which opened
  years of new content.
- **A mystery crane across the river** (CityVille): one unexplained image set off
  community speculation; the later bridge unlocked a whole new waterfront area.
- **The lonely cow** (FarmVille): a feed story saying a friend's cow had wandered off and
  needed help getting home. It was silly and emotional, and brought roughly a million
  more players the next day. It became a pattern across games: re-engagement via
  **social breadcrumbs** that invite people back to help someone.
- **Expansion cities** (Mafia Wars): a travel menu listed possible new cities to see
  which got clicks. Chicago won, and expansions became quarterly events.
- **Duolingo Stories**: short character-driven narratives that made practice emotional.
- **Lost's hatch**: a single mystery that added a whole dimension and kept an audience
  for seasons.

Bold Beats work outside games and outside consumer: a fun-first debit card, a gamified
retail promotion, even compliance training with a leaderboard. Pincus's view is that
the more boring the category, the more room there is to delight.

Make Bold Beats a standing quota (for example, every team ships at least one per
quarter, written into its goals). Teams that are either crushing it or in crisis
otherwise never try anything new (the Penguin Effect; see `roadmap.md`).

### Forever franchises

For a product people already love, improving it is often worth more than launching
something new. Zynga's turnaround rested on the economics of **forever franchises**:
long-lived products run as live services, with steady Bold Beats, seasons and
expansions. They were judged on loyalty (a D365 around 10% or better) rather than launch
spikes. The same turnaround showed what happens when a team swaps a loved franchise's
proven core for an all-new version, or bets on expensive new launches instead of the
franchise. Protect the core, and innovate at the edges in isolation.

## 7. Golden Mechanics

When a Bold Beat clearly works, promote it to a **Golden Mechanic**: a proven building
block every future product and team reuses. Zynga's included gifting, crafting,
expansions, neighbors, helping and hiring friends, and turn-based social play. Keep a
written playbook of your own Golden Mechanics with the evidence for each. It's your
private Proven inventory, and nobody objects to copying their own team.

## 8. Distribution is part of the product

"Build it and they will come" is a hope strategy. Design distribution in from day one:

- **Go where people already are.** Casual games on a social network were like comics in
  the newspaper: nobody goes to a comic shop, but people read the strip they trip over
  every morning. Put the product in the daily path.
- **Hack an existing platform's distribution.** Many big consumer services started on
  someone else's surface (YouTube embeds on MySpace; Zynga on Facebook's newly opened
  platform and feed). Pincus also points to under-used channels: big mature platforms
  everyone has stopped trying, and optimizing for AI answer engines (generative engine
  optimization).
- **Make usage do the inviting**: turn-based requests, help requests, shareable
  artifacts (tbh's screenshot-worthy poll results), reciprocity, an imported graph so
  the product isn't empty on day one.
- **Breadcrumbs and reminders that people welcome**: social, emotional, useful. Not
  spam. Being too viral can make non-users resent you.
- **Buy mindshare early on new platforms**, when attention is cheap.
- **When consumer distribution is broken** (app discovery is close to dead; Pincus notes
  average new app installs per user per month are near zero), start with prosumers and
  power users who care enough to find the product and pay for it.
- **Use marketing as a product test**: locked teasers and ad variants tell you what has
  heat before you build.
- **Platform risk is real.** Building on someone else's platform gives distribution but
  makes you a guest who can be cut off. Zynga lost about a third of its traffic quickly
  when its host changed the rules. Keep control where you can.

### Cold start

If the product is empty without other people or content (ratings, listings, a social
graph), plan for the empty room:

- **Win the smallest dense unit first**: one campus, one team, one neighborhood, one
  event. Facebook went school by school. A network gated by a shared email domain gives
  instant trust and density.
- **Be worth opening before the network exists**: some single-player value (menus,
  tools, personal tracking), an imported graph, or content the founders seed by hand.
- **Make the empty state do work.** FarmVille's empty friends bar looked like friction,
  but it drove invitations.
- **Use structure to raise density**: content that repeats (dishes, venues, routes) can
  build up ratings over time rather than resetting daily.

## 9. Anti-patterns

- **Mouse nuts**: many small, measurable features that move nothing and slowly make the
  product worse.
- **Squeezing the lemon**: optimizing monetization with pop-ups, harder-to-find close
  buttons and longer unskippable ads, instead of fixing complaints or adding bold value.
- **Chores disguised as engagement**: daily obligations that aren't fun.
- **Changing what users rely on** without testing (Poker 2.0's revolt).
- **High-fidelity traps**: expensive rebuilds (Pincus singles out 3D in games) that are
  slow, so you can't find the fun quickly.
- **Novelty without retention**: a viral spike from a mechanic that fades.
- **Metrics nobody can move**, which teams quietly ignore.

## 10. Engagement audit checklist

0. **Diagnose before building.** Where exactly do users drop, and is each drop
   something engagement can fix? Paywalls, trial endings, pricing, seasonality and a
   changing acquisition mix all look like engagement problems in a retention curve.
   Then check the category's **proven basics** are in place (onboarding best practice,
   trial and paywall hygiene, notification patterns). Even Sid Meier's social game
   failed on a clumsy first-time experience. Fix those failures before inventing.
1. What is the core loop, and is it loved on its own? (Talk to or watch real users.)
2. What leading metric predicts retention here? Is it product-specific and movable? If
   not, propose one (a round-trip or depth-of-investment measure).
3. D1 / D7 / D30 numbers and the D365 story: why would someone be here in a year?
4. Which motives does it serve (invest, express, connect, permission, real stakes, a
   basic urge)? Which are missing?
5. Social structure: is there reciprocity? Trust? Good leads?
6. Which proven mechanics would strengthen the core loop? Which existing ones are just
   lemon-squeezing?
7. A Bold Beats backlog: 3–5 ideas, each with the hack version, isolation, the target
   (≥25% try, ≥10% lift on a named metric) and the kill rule.
8. Distribution: what in normal use brings in the next user?
9. Close with: *what will our users thank us for?* Rank the backlog by that.


======== FILE: references/new-platforms.md ========

# New Platforms: Building Where Nothing Is Proven Yet

Pincus calls emerging platforms "new planets": AI, robotics, space, crypto, and the
blurring of virtual and real. They break Proven Better New because nothing is proven
for this audience on this platform yet. Don't throw the framework away. Adapt it.

## Contents
1. Two waves
2. Fuzzy Proven
3. Get native
4. Permission to be too early
5. Curious edges and surface area
6. True signal still means behavior
7. Three pioneer styles
8. Instincts Pincus is chasing in AI (raw material, not proven)
9. What to do this week

## 1. Two waves

Every platform shift has a **first wave** everyone predicts: the obvious port of
existing businesses (e-commerce replacing catalogs; online versions of offline
institutions). These are often overfunded before they make sense. Then comes a
**second wave** that nobody can imagine until they've lived on the planet for a while:
eBay and Craigslist on the early web; Uber and Airbnb in the social/mobile era, which
depended on a new kind of trust between strangers.

Second waves often follow the **Jevons paradox**: when something becomes nearly free
(listing an item, publishing, a ride request, now intelligence via tokens), demand
explodes in ways nobody predicted. Ask: what is becoming nearly free, and what will
people suddenly do far more of?

## 2. Fuzzy Proven

When nothing is proven on the new platform, find the **atomic unit** of proven
*behavior* and make it native.

- Get to the right level of abstraction. "Taxis" was the wrong proven unit (it leads to
  booking a cab by text). "A paid ride from A to B" was the right one, and it left room
  for a phone-native experience and a radical New (anyone can drive).
- Keep the proven nuance while adapting. Many teams treated mobile as a license to
  reinvent everything and failed. Supercell kept FarmVille's proven elements and
  changed only what touch and mobile sessions demanded.
- Look for the proven behavior hiding in another context, often another country or
  platform. Pincus suggests a Chinese companion chatbot with a huge user base was the
  first real proven signal for conversational AI as a consumer product, years before
  ChatGPT.
- Expect fuzzy-proven attempts to fail more often. Their value is also that they make
  the team native fast. (Pincus's own quick AI chat app failed before launch because
  the proven competitor's answers were simply better than his team's. That was a
  lesson in what was actually proven.)

## 3. Get native

You can't design the second wave from outside. Live on the planet before it's worth it:

- **Use the technology daily** for real tasks, even when it's clumsy. Reid Hoffman
  learned more in five minutes of driving an electric car than from understanding
  the idea intellectually.
- **Be a hobbyist and a hacker.** Early hacky versions (a crash-prone first product, a
  barely useful early code assistant) show people the future and often lead to owning
  the market. Engineers tend to dismiss small early innovations because they're easy to
  build. Then nobody builds them.
- **Endure the friction on purpose.** Each painful workaround builds muscle memory, so
  you'll be first to recognize when someone finally solves it.
- **Make the team native.** For example, the Shopify CEO's rule that teams must show why
  AI can't do the work before asking for more headcount.

## 4. Permission to be too early

You'll almost never time a shift perfectly, so being too early is the better mistake.
Being early has advantages: less competition, forgiving early users, hobbyist
communities hungry for new things, room to experiment cheaply. Give yourself permission
to "waste" time on small, narrow, interesting products. Established companies should
consider reserving a fixed share of resources for the next platform each year, even
though it trades dollars for pennies at first. (Zynga's real mobile mistake, by Pincus's
account, wasn't missing it. It was not committing hard enough, including not buying the
mobile leader when it could.)

## 5. Curious edges and surface area

- **Curious edges**: where the user's own life meets an emerging technology, often
  disguised as a personal problem (a family member's rare condition and gene editing; a
  spouse's illness that became a precision-medicine company). Genuine motivation keeps
  you exploring when it's hard and doesn't yet pay.
- **Increase surface area**: get out of the office and meet people already building on
  the planet. A chance demo (a writer's AI voice bot that phones people to collect their
  stories) can open a new instinct vein (voice as an interface).

## 6. True signal still means behavior

New platforms produce a lot of false signal. Pincus's case is Web3: billions invested,
little consumer traction beyond trading. Games were the expected first use case, but
nobody plays a game because it's on a blockchain. That might help monetization, but it
doesn't make the game fun. Watch out for "drinking the Kool-Aid" evidence (a startup
whose main customer is itself). True signal looks like millions of people doing the
thing within months, and founders scrambling for more servers.

## 7. Three pioneer styles

From Pincus's interviews:

- **Reid Hoffman: people, people, people.** Everything starts from what people care
  about most, which is other people. He builds networks years ahead so they bring back
  signal, filters ideas by the basic human urge they serve, and prefers bits to atoms for
  speed of iteration (except for deliberate impact bets).
- **Cyan Banister: pursue the weird.** She schedules unproductive time, follows odd
  coincidences, funds ideas others call insane or mistimed, and gets native by doing
  (she tried manufacturing a simple product herself to understand the supply gap).
- **Neal Stephenson: find your Comic-Con.** Find the community already living a
  primitive version of the future, spending money and vacation time on it. Build
  infrastructure that lets many people experiment, rather than predicting the one right
  answer. Ask: what do you believe that others don't?

## 8. Instincts Pincus is chasing in AI (raw material, not proven)

Offer these as instinct prompts when the user is exploring AI products. Label them as
one founder's hunches, not evidence. Each still needs Proven-Better-New thinking and
cheap tests.

- **Make the AI cocktail party rowdy.** People now spend hours with AI assistants, but
  alone. It's a quiet, lonely party, like the web before social networks. Who makes it
  social, and socially productive?
- **Agents as social brokers.** An agent that knows both people's context could broker
  plans, introductions, dating and job leads while revealing less than it knows. Think
  of a trust membrane that adjusts how much attention to ask of each person, handling
  the awkward asymmetries (one person keen, the other busy).
- **A social productivity step-function.** Early social networks made keeping up with
  hundreds of people cheap. Agents could do that again, without wasting people's time.
- **Services that never made economic sense**, now viable at near-zero marginal cost:
  his favorite example is a 24/7 personal travel agent that knows your context and
  rebooks you mid-trip when things go wrong.
- **Design for free tokens** (an idea he credits to Garry Tan): imagine today's token
  costs as essentially free within a year or two, and design consumer products for that
  world. Unlike a dot-com business selling goods at a loss, the cost curve is actually
  falling.
- **Distribution is the open question.** In Pincus's view (at the time of the
  interview), AI chat isn't yet a true platform for third-party apps, and app discovery
  is close to dead, so consumer AI launches face terrible odds. That favors prosumer and
  power-user wedges, and baking distribution into the product.

### Open veins Pincus points to from earlier eras

Also from the book, as instinct prompts:

- **Online dating is always broken.** Every generation tolerates bad leads. Curated and
  trust-gated networks (human-curated apps, campus-only matching) keep finding room.
- **A Napster for live music.** Fans record every show and the recordings go nowhere.
  A cocktail party for each fan community is still missing.
- **Gamified commerce.** Codes on products, fun-first cards and virtual rewards cost
  almost nothing to produce, and most retailers still haven't tried them.

**Experiment now.** Pincus's warning on the podcast: while distribution is broken,
experiments are cheap. Once a channel opens, a flood of competitors makes the same test
far more expensive.

## 9. What to do this week

- Pick one curious edge and use the new technology on it daily.
- Meet three people already building on the planet.
- Ship one fuzzy-proven experiment in days: proven behavior, native form, isolated New.
- Write down what you believe that others don't, and one cheap way to test it.


======== FILE: references/principles.md ========

# Principles

The mindset behind every phase. These ideas come from Mark Pincus's *Life at the Speed
of Play* and his Lenny's Podcast interview; the wording and structure here are a
distillation, not his text.

## Contents
1. Instincts versus ideas
2. Instinct veins
3. The body of water
4. True signal, false signal, hope
5. B+ is the enemy of A
6. Start smaller than feels dignified
7. Taste and staying close to the metal
8. Being right beats scale
9. Ambition, defined through the user's eyes

## 1. Instincts versus ideas

An **instinct** is a gut-level feeling about people: something is missing, too hard, or
could be far better. An **idea** is one particular way of acting on it.

When people see a hit and say "I had that idea," they usually had the instinct. Plenty
of people sensed that phones and computers would merge; the iPhone was one specific,
very hard-to-get-right idea. Pincus sensed in the early 2000s that hailing a cab
should be as easy as texting, and registered a domain for booking taxis by SMS. The
instinct was right. The idea, ordering a conventional taxi, wasn't. Uber became
possible years later when GPS phones, maps and trust in strangers on the internet made a
different idea work.

His rule of thumb: a seasoned founder's instincts are right around 95% of the time;
their ideas are right maybe 25% of the time, often less. If you believe that, you
behave differently:

- You expect the current idea to be wrong and plan the next three.
- You stay emotionally attached to the instinct, not to the implementation.
- You read a failed idea as information about the idea, not a verdict on the instinct.
- You notice when someone else ships the right idea on *your* instinct. That is the
  strongest validation you'll ever get. Switch, copy, or invest; don't compete with it
  out of pride.

Founders often find the winning idea only once money is about to run out, because that
is when they finally kill ideas quickly. The goal is to act that way before it's forced
on you.

## 2. Instinct veins

Some instincts are deep enough to mine for a career. Pincus names two of his:

- **"It just works"**: technology is too hard for normal people; remove the friction.
  It produced an offline-browsing product, help-desk automation software, and (for his
  cofounder) a spam-filtering company.
- **The Cocktail Party**: everyone is looking for the gathering with the right people,
  the right context, fun with purpose and trust, where the best "leads" come from
  (dates, jobs, ideas, deals). It produced an early social network, Zynga's social games,
  and early investments in Facebook and Twitter.

Ask the user what themes keep coming back for them. A vein that recurs across years and
projects is a stronger foundation than a clever idea from last week.

The book also notes that deep instincts often form in the **Abyss**: the open,
unstructured stretch between projects. It is uncomfortable but useful. That is where
people sample widely, notice patterns, and calibrate taste. Don't rush someone out of it
into the first available B+ idea.

## 3. The body of water

Pick the market before the boat. In the right body of water most boats float; in the
wrong one, even a great boat sits on a dry lake bed. (Pincus's example: in 1995, "retail
software" looked like the big market and "free internet services" looked tiny; within a
decade the first had shrunk and the second had become too big to call one industry.)

Four quick tests:

1. **Room to enter.** Can a newcomer get noticed, or is it so crowded and hot that
   standing out is impossible?
2. **A proven way to make money.** Is there a clear line of sight to revenue and
   sustainable margins in this market?
3. **Room to innovate.** Favorite pattern: a mature market that is quietly a growth
   market waiting for someone to innovate on its core value (search before Google,
   games before social games).
4. **Long-term tailwinds.** Does it ride macro trends the founder believes in?

The right water is often contrarian. It isn't what's fashionable to fund this quarter.

## 4. True signal, false signal, hope

**True signal** is unmistakable. Everything comes back positive at once:

- The maker can't stop using it, despite the flaws.
- Friends and target users love it without being asked to be polite, and show it to
  others.
- People do the core action again and again, and come back without being reminded.
- Growth is organic, and the problem is keeping up (servers, supply, support).
- Benchmarks: for a social product, around 60% of monthly users active on a given day is
  a sign it has become part of daily life. Early Facebook reportedly took a fifth of a
  campus in week one and most of the rest in week two.
- Depth beats breadth early. A product that 20 people truly love is a stronger signal
  than one a million people find okay (a point Pincus credits to Emmett Shear). Look for
  the small group that would be genuinely upset if it disappeared.

**False signals** feel encouraging but don't predict a hit:

- Investors, big partners or press are interested. (Smart money is not user signal.)
- Novelty virality without retention: invites get opened, people try it once, and the
  boat is sinking faster than you can fill it.
- "Viable": people *can* use it, so it might work.
- Positive feedback on things that were copied from a proven product, while the new
  part is weak.
- Engagement bought with mechanics (rewards, streaks, gambling-style loops) that would
  lift any product and hide whether the core is loved.
- Your own team using it because they have to.

**Hope** is confidence with no basis in what users have done. **Belief** rests on
evidence from real behavior. **Conviction** is belief strong enough to bet heavily on.
*Kill hope before hope kills you*: every plan should replace hope with a test. Pincus
describes the best makers as collecting winnings rather than placing bets. By launch day
they already know they have a hit, because they built the evidence first.

## 5. B+ is the enemy of A

A B+ idea is the most dangerous kind. It's good enough to raise money, win some
customers, hire people and get a little traction. It is never good enough to become
great. A clearly bad idea dies quickly; a B+ can absorb years.

Tests for intellectual honesty:

- **If you're asking whether it's an A, it isn't.** With the right one, the way with the
  right partner, you don't wonder.
- Would your smartest friends put their own money in?
- Are you pursuing it out of desperation, for example to escape the Abyss?
- Are you torn between two directions? Then often neither is right.
- Does the excitement come from users or from you?

Being truly ambitious means: ruthless objectivity about ideas, willingness to kill them
often, no attachment to a specific implementation, and testing several variants instead
of going all in on one. When something is graded B+, the honest next step is one of:
use it to learn (what part had heat?), look for something nearby that's proven, or stop
and start the next shot. Pincus says that killing his own long-running project after
four years brought the most creative stretch he'd had in years.

## 6. Start smaller than feels dignified

The more ambitious you are, the humbler the starting point should be. Big hits usually
start embarrassingly small: a poker game on Facebook, a site for one campus, an internal
chat tool at a failing game studio. Pincus's failed social network tried to be social,
professional, groups and classifieds at once. It was wide and shallow, and it lost to
narrower products. His comeback, Zynga, started with one engineer and one deliberately
unambitious game.

Successful repeat founders are especially at risk. Money and recruiting come easily, so
they can chase a big vision before finding product-market fit. A newcomer who starts
narrow can have the advantage. Small companies can follow flaky threads that giants
can't justify, and those threads are often where big ideas come from.

## 7. Taste and staying close to the metal

Great product makers have a point of view, the way a good chef has opinions about their
own cooking. Taste is built through:

1. Deep immersion in the category (use everything, including the failures).
2. Constant experimentation and refinement.
3. Regular contact with user reactions.
4. Holding high standards when it's inconvenient.

Taste can also mislead. The maker's idea of magic may not match what users think about
at the moment they need the product. Airbnb's team called one version of this the
"Pincus Problem": he pointed out that celebrity-hosted experiences were delightful, but
not what a typical traveler wants when planning a surf trip. Check the magic against the
user's real moment of use.

Treat your own reactions as data. If you lose interest in something you thought would be
huge, notice it. If you keep using something despite its flaws, notice that too. A
**focus group of one** (the maker, or one person who perfectly represents the audience)
often gives clearer signal than a survey. Tell them a short story of the product and
watch for adrenaline: do they start imagining what happens next? Then check, quickly and
for real, that your taste generalizes to millions.

**Staying close to the metal** means the leader stays in the details: the product, the
users, the code, the data. People who are in the trenches are closest to the right
answer. When decisions drift away from them, culture turns cynical and products lose
their emotional center.

**You don't have to be first.** Zynga's mantra was best to market, not first to market.
A sharp number two that learns from the leader's mistakes can win. Pincus's first
company was a distant number two in its category and still sold for a good price, while
the hyped leader ended at zero.

## 8. Being right beats scale

The first job of a founder is to be right about the product. Scale is a consequence of
quality, not the goal. A company can do many things wrong with the right product, and
almost nothing saves the wrong one. (Pincus borrows the pilot's order of priorities:
aviate, navigate, communicate. Get the product flying before you worry about investors,
press or org charts.)

The question that brought Zynga back during its turnaround: **"What will our players
thank us for?"** Use it on every roadmap, review and feature list. It cuts through
revenue squeezing, vanity metrics and internal politics.

## 9. Ambition, defined through the user's eyes

"Burn your résumé." If you define ambition by your peers' respect, you'll avoid copying,
chase novelty and build for awards. If you define it by what your actual users love, you
take good ideas wherever they come from and make the experience one inch better for
them. The best version of this goes unnoticed. Users just feel the product is right.

The ultimate target is an **Internet Treasure**: a service people can't remember life
before and can't imagine life without. It is rare, and it is reached through many cheap
shots on goal, not one heroic bet.


======== FILE: references/proven-better-new.md ========

# Proven Better New

Pincus's central framework, the "religion" of Zynga's product management. Wording and
examples here are a distillation, not quotes.

## Contents
1. The three parts
2. Why it works, and why people resist it
3. How to do Proven properly
4. How to test Better
5. How to handle New
6. How much New you need depends on the water
7. Worked examples
8. Pitfalls
9. Teardown template

## 1. The three parts

- **= Proven.** An experience the target audience already loves, *on this platform*,
  broken down to the specific mechanics, flows and details (down to the pixel). You
  reuse it, legally and with taste, so the product doesn't fail for the wrong reasons.
- **> Better.** Improvements to the proven experience that 10 out of 10 of its current
  users would enthusiastically call better. It's objective, not your opinion: free
  instead of paid, no download, half the price, fewer steps, works where they already
  are, polish on the core loop. Better is usually small, and rarely wins alone except
  during a platform shift.
- **+ New.** The novel idea that has never been tried with this product and audience.
  It's the reason to try the product and talk about it, and it's the most likely part to
  fail. Pincus's maxim was that "all New fails". That isn't meant to discourage
  invention. It means isolating it, testing it, and having other News ready.

The trap that catches almost everyone: **what the maker thinks is Better is actually
New.** If you can't honestly say every existing user would agree, it's New, and it
needs to be tested.

## 2. Why it works, and why people resist it

Consumer success is close to unpredictable. Starting from something with proven heat
changes the odds. When you rebuild the proven experience faithfully, you avoid the
false negatives that come from getting basic things wrong. One story from the book: a
legendary game designer launched a social game whose first-time experience took too
many clicks, so almost nobody ever reached the brilliant design underneath. Junior
product managers who had studied the proven onboarding spotted it within minutes.

Isolating New also gives clean signal. If you change ten things and it fails, you learn
nothing. If you copy the proven base and change one thing, the result tells you about
that one thing.

People resist because of a **moral arbitrage**. Copying feels like cheating, and makers
want to be innovators, respected by peers. Junior teams spend real effort trying *not*
to look like a copy. That reluctance is exactly why the opportunity stays open for
people with less ego involved. Masters copy well: they can see excellence, understand
that changing it would make it worse, and save their originality for where it counts.
Users don't care whether you were original. They care whether it's one inch better for
them. The best copies are done with enough taste that nobody notices what they came from.

Copying alone gives users no reason to switch, which is why Better and New exist.

## 3. How to do Proven properly

**Get a PhD in the proven before you earn the right to innovate.** Before changing the
camera, onboarding or feed, become the world's leading expert on the best existing
versions.

- **Be precise about "proven".** It means: on this platform, for this audience, for this
  experience. A game that was popular in the 1990s on PC is not proven for mobile
  casual players today. A behavior inside Roblox is only fuzzily proven on the web.
  Founders often misuse the word to justify an idea they already have.
- **Deconstruct to the atomic unit.** List every mechanic, step, screen, default and
  piece of copy in the proven product. A useful mental model is the slot machine: it's an
  interface plus tuning, and an identical copy should produce the identical response.
  If you can't rebuild it and expect the same reaction, you haven't understood it yet.
- **Don't change what you don't understand.** At Zynga, a designer removed what looked
  like pointless friction from a farm game: an empty friends bar that pushed players to
  send invitations. The team kept it, because nobody yet understood why it worked. It
  turned out to drive invitations, virality and reminders to come back. Change proven
  details later, behind a test.
- **Measure heat.** Nikita Bier (tbh, Gas, later head of product at X) frames heat as
  *frequency × intensity*: how often people do it and how much they care each time.
  Snapchat turned photos into something people did dozens of times a day.
- **Hunt latent demand.** The most valuable proven thing is often a feature that's
  generating so much heat that users put up with a bad product to get it: an app with
  a store page in the wrong language that still tops the charts, or a ritual people run
  by hand through screenshots. Build the product those users actually want.
- **Copy proven pieces from anywhere for everything that isn't your New**: onboarding
  from whoever converts best, contact sync from the incumbents, notification patterns
  from the stickiest apps. Keep a running inventory of best-of-breed flows.
- **Benchmark the ecosystem continuously.** Being first matters less than being best:
  Zynga's mantra was best to market, not first to market. Whenever a competitor gets
  better growth or engagement, take apart which mechanics did it, match them, then
  innovate on top (FarmVille launched as Proven + Better against the leading farm game,
  then out-innovated it within weeks).
- **Copy yourself.** Inside a company, a mechanic that works in one product should
  spread to the others within days. Nobody minds copying their own team.

## 4. How to test Better

For each proposed Better item, ask:

1. Who are the current users of the proven product? (Not you, not your team.)
2. Would every one of them say yes, that's better, without needing an explanation?
3. Can you show it statistically, or is it a matter of taste?

Start with the **ask**: everything the product requires before it pays off. That means
money, a download, an account, setup, minutes per session, learning new rules, and
getting friends to join. Pincus found that requiring a download loses most of an
audience. His recipe for making games mass-market was a game people already knew,
free, about three clicks to start, and 5–15 minutes a session, placed where people
would stumble on it. Every cut to the ask is a genuine Better.

Typical genuine Betters: price (free, cheaper), access (no download, instant play,
works inside the platform they already use), speed, fewer clicks on the core loop, a
cleaner and less noisy interface, a faster first-time experience, mobile or touch polish,
importing an existing graph so the product isn't empty on day one.

Typical fake Betters, which are really New: "more social", "AI-powered", a new
organizing concept, a different feed algorithm, a redesigned navigation, a faster or
shorter version of the core activity. (Zynga once spent six months building a faster
version of a word game. Its core audience loved the unhurried, turn-based pace and
never adopted it.)

Users also feel ownership of products they rely on. They move fast through them by
habit and get angry at change, even change for the better. A master like Craigslist's
founder reportedly took around two years to add photos to listings, because he cared
about not breaking what people relied on. When the proven base is already loved,
Better should be cautious polish.

## 5. How to handle New

- **Expect it to fail**, and prosecute it like a scientist: isolate it, give it a
  clean test, judge it on a threshold you set beforehand (see `testing.md`).
- **Keep it narrow.** The best New is often one thing. Zynga Poker's only New was
  showing real people with their real profile photos at the table, which made it a
  live cocktail party instead of a game with creepy avatars.
- **Have more than one ready.** If you go in assuming New #1 fails and New #2–#5 are
  lined up, you run the work differently and much faster.
- **New gets people to try; Proven and Better keep them.** New is the back-of-the-box
  line, the thing that makes someone download it or talk about it.
- **Sources of good New:** a new dimension added to a tired activity (social identity on
  poker; a cultural lens on a soap-opera format); a feature that's buried in someone
  else's product, pulled out and made the whole product; a new platform capability; a
  piece of trust or identity infrastructure that suddenly exists.
- **The best case needs no New at all.** If Proven + Better is enough (it often is on a
  new platform), take the win. People don't like change.

## 6. How much New you need depends on the water

| Context | What works | Why |
|---|---|---|
| **Platform shift** (web → social → mobile → AI) | Proven + Better, little or no New. **The platform is the New.** | Users are in discovery mode, acquisition is cheap or viral, and incumbents are slow to move. FarmVille-style games moved to mobile; Call of Duty overtook its rival on a new console generation; AI-native startups reach large revenue in sleepy verticals. |
| **Mature market** (red ocean) | A lot of New, an "OMFG" level reason to switch | Everyone is committed to existing services and nobody is in discovery mode. But mature markets are also where incumbents stopped innovating. Reinventing the core value can turn an "over" market back into a growth market (search before Google, games before social games). |
| **New planet** (nothing proven on this platform yet) | **Fuzzy Proven**: the atomic behavior that's proven elsewhere, made native | See `new-platforms.md`. Uber kept the atomic unit "a paid ride from A to B", made booking and status Better through the phone and map, and the New was that anyone could be the driver. |

Risk/return view (Pincus's two-by-two for his students): pure New with no Proven is
**wildcat drilling**. It's high-risk, and the occasional gusher (a studio's 45th
completely different attempt finally hitting) isn't repeatable. Relying on licensed
proven IP is low-risk but the IP owner takes the margin. Proven Better New is the
quadrant with high odds *and* high margin.

## 7. Worked examples

Brief, paraphrased summaries of cases from the book and interview:

| Product | Proven | Better | New |
|---|---|---|---|
| **Zynga Poker** (2007) | Standard online poker table layout and rules | Free, instant play in the browser, no download (downloads lose most of an audience) | Real people, often friends, with real profile photos at the table |
| **FarmVille** (2009) | The viral farm-game formula already working on Facebook (free-form plot, avatar, friends bar) | Better crop art and economy, fewer clicks (tool attached to the cursor), first game to use the newly opened news feed | Effectively none at launch. Novel features (moving animals, buildings with gameplay) came weeks later as tests |
| **Hay Day** (Supercell) | FarmVille, faithfully, down to the driveway, mailbox and pickup truck | Rebuilt for mobile: shorter crop timers, simpler menus, tactile touch farming | Little: a masterclass in Proven + Better on a new platform |
| **Slack** | HipChat-style team chat used by engineers | Friendlier, more fun interface that end users loved | Hardly any at first. Spread through teams, not IT departments |
| **tbh** (Nikita Bier) | Teens' viral demand for positive anonymous feedback (a top-charting app with a clunky interface; compliment screenshots shared on Snapchat) | A clean, English-language form factor; contact sync and onboarding copied from the best converters | Pre-written positive polls plus a hint about who voted ("a 9th-grade girl"), which made results screenshot-worthy and drove the viral loop |
| **Threads** (AI-assisted teardown in the book) | Twitter-style feed, replies, reposts; Instagram profile and stories layout | Instant onboarding by importing an Instagram identity and follows; cleaner feed with no ads at first | Piggybacking an existing social graph into a new app at scale; cross-app notification loops |
| **Words With Friends** | Scrabble | Polished for mobile, asynchronous, free | Friends from your social graph already there to play |
| **Empire** (TV) | The soap-opera family power-struggle format | Contemporary music-industry setting | A cultural lens: centered on Black protagonists, an audience underserved by the format |
| **Draw Something** (OMGPOP) | Pictionary, plus Words With Friends' turn-based social system copied exactly | Mobile-native | The drawing-and-guessing twist on the turn-based format. The studio had already failed with something entirely new; this time it went proven-first out of desperation and reached #1 |

Contrast: **Zynga Poker 2.0** (2014) was all New with no Proven. Loyal players revolted,
a distant competitor doubled its users, and Zynga restored the classic version, which
then outperformed the new one.

## 8. Pitfalls

- **Fake Proven**: proven somewhere else, for someone else, at another time.
- **Better that is really New**, so untested risk hides inside the "safe" column.
- **Too much New**: reinventing everything makes the product wide, shallow and
  confusing, and when it fails you don't know why.
- **Changing the proven base** before understanding why it works.
- **PBN as a crutch**: copying a successful base produces decent early numbers, so a
  weak New can coast to a B+ and never become an A. Judge the New on its own signal.
- **AI homogenization**: a model can produce a competent PBN analysis in seconds, and
  the result will tend toward the average. In the book's own test, the model did well on
  Proven, mislabelled New ideas as Better, and produced conventional New ideas. Use AI to
  deconstruct and to generate options. Real users decide.
- **Magic the user didn't ask for**: delightful to the maker, irrelevant at the user's
  moment of need (see the "Pincus Problem" in `principles.md`).
- **Magic still matters.** Sometimes a team should build something purely for quality
  and delight (Airbnb's one-off "Icons" stays are the book's example). Treat it as R&D,
  and know you're doing it.

## 9. Teardown template

Use this for a hit, a competitor, or the proven product a new idea builds on.

```
## Teardown: <product>

Audience and platform: <who exactly, where, when it launched>
Context: <platform shift / mature market / new planet>, and why the timing worked

Core loop: <the repeated action and its payoff>
Heat: frequency <how often> × intensity <how much users care>; evidence: <metrics, rankings, reviews, behavior>

= Proven (what it reused, and from where)
- <mechanic / flow / detail> — from <source product>
...

> Better (what it improved that 10/10 users of the source would agree on)
- <improvement> — why it's objectively better
...

+ New (what was novel for this audience and platform)
- <novel element> — the risk it took; how it could have been tested cheaply

Distribution: <how it reached people: platform hack, graph import, viral loop, breadcrumbs>
Retention engine: <why people return; the leading metric you'd guess they watch>
What didn't work / what changed later: <...>

Lessons for <user's product>: <what to copy exactly, what to make better, where to put your New>
```

When researching, cite sources and separate facts you verified from inferences.


======== FILE: references/roadmap.md ========

# Roadmapping: The Product Team's Operating System

How Pincus ran Zynga's product teams so that the method above happened every week, not
just in a kickoff. Useful when the user leads a team, owns a roadmap, or complains about
slow learning, scattered priorities or too many small features.

## Contents
1. The roadmap as operating system
2. The roadmap line item
3. The weekly review
4. Goals and OKRs
5. Mouse nuts, boiling the ocean, and the Rule of Four
6. Altitude and the Penguin Effect
7. Spreading what works
8. Keeping leaders close to the product
9. Roadmap template

## 1. The roadmap as operating system

A roadmap is where strategy meets execution: which hills the team is taking, what
outcome each project should produce, and what it costs in engineering time. Pair it with
a standing weekly meeting that Pincus called the most important hour of his week, his
real board meeting. It works as both a report card and a diagnostic: are engineers
building things users actually want, and is the team learning fast enough?

His claim: with a good roadmap discipline, around **80% of engineering days are real
shots on goal** (features users might actually want), versus maybe 20% at a typical
competitor. That's a multiple on effective capacity.

Teams will try to cancel the meeting when they have nothing to show. That's exactly when
it matters most.

## 2. The roadmap line item

The atomic unit is usually a feature or experiment. Each line has:

- **Hypothesis**: what we believe and which objective it serves.
- **PBN tag**: Proven (copy), Better (polish) or New (experiment), so risk is visible.
- **Expected outcome (EO)**: a number on a named metric (e.g. +X daily installs, +Y%
  D7 retention, +Z turns per user).
- **Cost** in engineering days, so you get *expected outcome per engineering day*.
- **Owner**, ship date, kill rule.
- After launch: **actual vs expected**, and the lesson.

Tracking estimated against actual engineering days also makes the team better at
estimating over time.

## 3. The weekly review

Every team arrives with:

1. The hypothesis it tested, tied to its objective.
2. Expected outcomes per engineering day.
3. Actual metrics against expected.
4. What it learned and how that changes next week's bets.

Pincus's three aims for each review: is the product on track for its goals, is the team
creatively productive and efficient, and are new product leaders getting better? If a
team doesn't know its numbers or isn't signing up for growth, the meeting reconvenes
later in the week. Weeks of only tiny features are a warning sign: teams without big
ideas drown in small ones.

Operate on compressed time: a day is like a week, a week like a month. Elon Musk's
question applies: what did you get done last week?

## 4. Goals and OKRs

- One clear objective (the hill), a few measurable key results.
- Set ambitious targets (Zynga typically started from ~30% quarter-over-quarter growth)
  so teams can't simply repeat last quarter's tactics.
- Ground ambition in what's demonstrably possible: what the best competitor has achieved,
  or what's within the laws of physics, not wishful round numbers.
- **Don't change OKRs mid-quarter.** As the gap shows, teams must rethink and take
  *more* risk, the opposite of the usual drift toward safe, small features.
- Write Bold Beats into each team's quarterly goals.
- Reserve capacity for the future. Zynga's maxim: you're redlining if less than ~25% of
  engineering days go to future growth.
- Caveat from Pincus himself: OKRs suit decentralized teams running live products with
  their own P&L. They're often overhead for a single team going from zero to one, and
  can turn into corporate theater if done badly. Try them for one quarter.

**Stop time.** When the market shifts or new evidence lands, call a deliberate pause:
stop business as usual, re-check whether the path still makes sense, decide on any pivot,
then sprint at the clearer goal. Pincus did this early at Zynga, pulling the team off a
scatter of small apps to double down on the one game with traction. Some people will
resist. If the call is right, the team comes back more committed.

**Don't promise revenue from New.** Because most New fails, avoid committing projections
(to a board or the market) that depend on unlaunched products. Zynga's later slate of
heavily forecast new games is the cautionary tale.

## 5. Mouse nuts, boiling the ocean, and the Rule of Four

- **Mouse nuts**: tiny incremental features. They're measurable, safe and pointless.
- **Boiling the ocean**: projects so big they never ship and everyone forgets why they
  started.
- **Rule of Four**: everything costs twice as much and takes twice as long as planned.
  Spend that on mouse nuts and you've lost the quarter.
- The answer between the two is the Bold Beat (see `engagement.md`).

## 6. Altitude and the Penguin Effect

- **Say what altitude you're at.** 5,000 feet: features, UX, execution. 25,000 feet:
  how the pieces fit. 50,000 feet: vision and mission. Leaders who jump between
  altitudes without saying so look like they change their mind every week.
- **The Penguin Effect** (a term from Zynga's CTO Cadir Lee): teams that are either
  crushing it or in crisis won't step off the cliff to try something new. The moment one
  team tries something and it works, everyone copies it within the hour. So make the
  first jump cheap, visible and celebrated.
- The longer a team goes without shipping, the more pressure it feels and the more
  incremental it gets. Shipping small bold things often keeps that pressure from
  building.

## 7. Spreading what works

- **One shared roadmap and analytics system** across teams. Zynga's teams initially kept
  a private roadmap and a version "for Mark". Things changed when one team's viral
  breakthrough was visible to all and copied immediately.
- **Teaching hospital**: run product reviews with other team members and new hires
  watching around the room, so judgment spreads by observation.
- When a team wins, it **teaches** how it found the opportunity, estimated cost, chose
  metrics and iterated. Every winning feature becomes a case study and, if it holds, a
  Golden Mechanic.
- Teams that hit their numbers earn more resources. Reward outcomes, don't dictate the
  method.

## 8. Keeping leaders close to the product

Pincus's management principles, framed around one goal: get people to do the right thing
when you're not in the room.

- **Be in the room as long as you can.** Micromanaging is fine while you're the best
  player at the position. He ran daily stand-ups personally until about 50 people.
- **Founders approve what users touch.** Discord's founders reclaimed final say over
  every user-facing feature after realizing the most important UX calls had drifted to
  the most junior people.
- **Guard product time.** Aim for at least half (ideally most) of a leader's calendar on
  product: roadmaps, reviews, brainstorms, hiring product people. Squeeze press,
  conferences and investor meetings. "Don't be a fake CEO."
- **Make everyone the CEO of something** with real ownership, and give promising people
  bigger jobs early (battlefield promotions). Clone your judgment through a **tech
  assistant** who shadows you for a year.
- **Challenge assumptions, not judgment.** Questioning someone's assumptions is
  collaboration; questioning their judgment is personal.
- **Hiring for new products**: look for people who built a failed version of what you're
  building ("broken résumés"); the product they made is the best résumé. Hire outside
  leaders one level below the intended role so they earn credibility inside your product
  first.
- **Values are earned in the trenches**, and the best ones say how you win (Zynga's
  "innovate on social game mechanics").

## 9. Roadmap template

```
## <Product> roadmap — week of <date>

Objective (this quarter): <the hill>
Key results: <KR1> <KR2> <KR3>       Status: green / yellow / red
Capacity: <N> eng days this week; <% on future growth> (redline < 25%)
Bold Beat this quarter: <name> — target ≥25% try, ≥10% lift on <metric>

| Item | PBN | Hypothesis | Expected outcome | Eng days | EO / eng day | Owner | Ship | Kill rule | Actual | Lesson |
|------|-----|-----------|------------------|----------|--------------|-------|------|-----------|--------|--------|

Learned last week: <...>
Bets changed because of it: <...>
What will our users thank us for this week? <...>
```


======== FILE: references/testing.md ========

# Testing: Minimum Idea State

How to turn instincts into conviction cheaply. A distillation of Pincus's argument
against the MVP and for testing far smaller units of an idea.

## Contents
1. The MVP trap
2. Minimum Idea State
3. The probe menu, cheapest first
4. Designing a test
5. Reading the result
6. Failure machines and AI
7. From signal to a Maximum Launch Product
8. Cautionary cases

## 1. The MVP trap

The weak word in "Minimum Viable Product" is *viable*. In practice teams use it as a
reason to keep building: it isn't viable yet, so it can't launch. Months go into
something that has close to zero chance of being right the first time. Viability is
also where hope comes from: if it's viable, it *might* work.

Two different things get blurred:

- A **learning product** exists to get signal on an idea. It can be fake, ugly, manual
  or broken after ten clicks.
- A **launch product** is something you already believe (from evidence) will be a hit.

Be explicit about which one you're building. Most of the time early on, it should be
the learning one, and it should be much smaller than people think.

## 2. Minimum Idea State

A **Minimum Idea State (MIS)** is the smallest expression of an idea that can be put in
front of the target audience and give directional signal. It isn't a product. It can
be a link, a slide, a video, a hand-run service or vibe-coded demoware.

Pincus's line on the podcast: build it wrong before you know it's right. Assume the current version is the wrong
product. If you believe that, you'd rather waste a day than three months on it.

## 3. The probe menu, cheapest first

| Probe | What it is | Good for | Book/podcast examples |
|---|---|---|---|
| **Listen first** | Ask target users what they did today, what frustrated them, what they use now, then stay quiet. Have no idea to defend yet. | Finding the real problem and latent demand before ego is invested | Emmett Shear (Twitch): gather data before having the idea, because nobody improves an idea they're already attached to |
| **Story test / focus group of one** | Tell one perfect representative of the audience a 30-second user story and watch their reaction | Fast read on adrenaline, i.e. whether they start inventing what happens next | Pincus pitching a game twist to two 13-year-olds on a gondola |
| **Fake door** | A link, button, menu item or dialog for a feature that doesn't exist; measure clicks | The appeal of a New idea inside an existing product or audience | A five-word link in Mafia Wars (Zynga's crime game), shown for one minute, clicked by ~23% of players, led to a poker crossover and a million installs in a week. A one-hour dialog-box test could have saved six months on Words With Friends' failed fast mode |
| **Ad / message test** | Run several ads or headlines to the target audience | Which promise, audience or variant has heat, before building | Pincus notes on the podcast how often teams never test their ads before launch |
| **Locked teaser** | Show the coming feature or content locked in the product, with "get early access" | Demand, positioning and even pre-revenue at once | A locked expansion on the FarmVille board tested art and messaging, and sold millions of dollars of early-access keys |
| **Landing page / waitlist / demo video** | Describe or show the product as if it exists | Whether the concept pulls sign-ups | Dropbox's demo video |
| **Ripomatic** | Mash up screenshots and screen recordings from existing products, with annotations and realistic copy, into a click-through story of the user experience | Conveying a new concept built largely from proven parts; getting feedback without code | Zynga's slide decks; a sitcom pitched as four key scenes instead of a full pilot script |
| **By hand (concierge)** | Deliver the experience manually before building software. Humanize before you productize | Learning what users value; getting the first superfans | Airbnb's founders photographing hosts' apartments and fixing the calendar in two days; DoorDash's Google Forms; Zappos buying shoes at retail; cable video-on-demand tested by someone roller-skating to a VHS deck |
| **Vibe-coded demoware** | A working prototype built with AI in hours, good enough for the demo path only | Interactive concepts, delight, onboarding flow | Interactive ripomatics |
| **Isolated hack in a live product** | A Bold Beat: a quick, hacky, isolated version of a big feature, shipped to real users | Big swings inside an existing product | See `engagement.md` |
| **Piggyback platform test** | Launch a tiny version where a captive audience already is (a platform, a community, another product's surface) | Distribution and real usage without building plumbing | Zynga building small apps on the newly opened Facebook platform instead of buying an audience |

Rule of thumb: if a probe will take more than a week, look for a cheaper one that tests
the same risk.

## 4. Designing a test

For every test, write down before running it:

1. **Hypothesis**: the single New element being tested, and the audience.
2. **Probe**: from the menu above. Use the cheapest one that real target users will see.
3. **Signal metric**: the user *behavior* that would count: click-through, sign-up,
   repeat use, invite sent, payment, return next day. Opinions ("would you use this?")
   are weak. Behavior is strong.
4. **Threshold**, set in advance, for "heat" and for "kill". Calibrate it against the
   proven baseline where possible. Reference points from the book: an in-game link
   clicked by about 23% of players justified building; a quarter of poker players
   joining friends' tables signalled the social idea worked; a Bold Beat needed ~25% of
   users to try it and a ≥10% move in a key metric.
5. **Time box**: days, not months.
6. **Next step on each outcome**: heat → build it properly; mixed → change one variable
   and rerun; no heat → kill it and run the next queued idea.

Isolate: test one New at a time on top of a faithful Proven base, so the result means
something.

**Split the risks.** Most ideas carry several independent risks. Give each its own probe:

- **Demand**: will people want it and come back?
- **Supply / content**: will enough people contribute, rate, post, list or host? Most
  users never contribute, so this is often the real killer for ratings, marketplaces and
  UGC.
- **Distribution**: can you reach the audience cheaply and repeatedly?
- **Monetization**: will anyone pay, and how much?

A single combined test that fails can't tell you which risk killed it.

**What counts as a test.** Interviews and data cuts are research that sharpens the
hypotheses. Experiments are probes where real users act. Thresholds and kill rules
apply to experiments. For research, state the question it must answer and the decision
it feeds.

## 5. Reading the result

- **Heat is obvious.** Numbers repeat when you rerun, users ask for more, they share it
  without being asked, they complain when it's taken away. Pincus turned a link on for
  one minute, got the same click rate twice, and took that as enough.
- **Lukewarm is a no.** "Some people liked it" is the B+ zone. Don't rationalize.
- **Watch for false positives**: mechanics that lift anything (rewards, scarcity, free
  stuff), novelty that fades in a week, friends being polite, a small sample of fans.
- **Read why it failed.** Did the New fail, or did the proven base get broken and drag
  it down? Fail for the right reason.
- **Kill quickly.** One team (Twitch's founders, pre-Twitch) killed any idea that didn't
  show results within about a week. If you must choose between the *most* shots and the
  *best* shots, most usually wins, because nobody knows in advance which shot is best.
  Twitchiness is a strength when it's anchored to one vision.

## 6. Failure machines and AI

Since most New ideas fail, build a **failure machine**: a system where the marginal cost
of testing an idea is close to zero, so you can test more ideas in a week than the
industry tests in a year. At Zynga that meant links and pop-ups in live games, and
eventually internal ad-serving technology that could test hundreds of ideas a day.

AI makes this cheaper than ever, but Pincus's worry is that teams use it to build one
idea faster instead of testing a hundred. Use it as a testing machine:

- Generate many variants (copy, art, onboarding flows, feature concepts) and test them
  against real users in parallel through ads, fake doors or prototypes.
- Vibe-code throwaway prototypes in hours rather than polishing one in months.
- Use simulated users only to filter options before real tests. Simulation is not
  signal.
- Keep the human job: taste, empathy, and spotting which result is true signal.

## 7. From signal to a Maximum Launch Product

The point of a cheap test is to earn conviction. Once you have true signal:

- **Overinvest** in the winning idea. Build it properly: the hacky Bold Beat becomes a
  real system. (FarmVille's crafting buildings were shipped as a hack in a month, then
  rebuilt over six months into the game's biggest engagement driver.)
- **Launch big**, as a Maximum Launch Product rather than a timid MVP, because you
  already know it's a hit. Makers who test this way (Brian Chesky is the book's example)
  don't launch to find out whether people like it.
- Being in market with real users makes a team far more creatively productive than
  polishing in private. Teams that keep saying "it's not ready, we haven't found the
  fun" usually need to put something rough in front of users now.

## 8. Cautionary cases

- **Quibi**: a right instinct (short video on phones) bet entirely on one expensive idea
  (premium Hollywood shows) without cheap tests. It shut down within months. Cheap,
  addictive serialized short dramas later proved the instinct at scale.
- **Words With Friends "Fast Play"**: a team assumed the game was too slow and spent six
  months building a faster mode. Few players tried it and almost none returned; the core
  audience loved the slow, turn-based rhythm. A dialog-box test would have shown this in
  an hour. The winning idea, weekly challenges, was tested as a simple progress bar
  first, and helped turn the franchise around.
- **Tribe.net** (Pincus's own): strong invite numbers hid weak retention. He stuck with
  one idea instead of testing alternatives and going with whatever had the most heat.
What it does

hit-products helps you decide what to build and make it something people keep using. It follows the product-making method Mark Pincus describes in Life at the Speed of Play and in his Lenny's Podcast interview. The skill is an independent distillation in its own words.
The method rests on one asymmetry: a good founder's instinct (the human need they sense) is usually right, but the specific idea built on it is usually wrong. So the skill:
states the instinct separately from your idea, and generates several other ideas on the same instinct;
breaks each idea into Proven (what to copy from products this audience already loves), Better (improvements every existing user would agree with) and New (the risky novel part, to be tested on its own);
grades each idea honestly (A, B+, C+...) and says when your original idea isn't the strongest;
replaces the MVP with the cheapest test that can give real signal, with success and kill thresholds set before it runs;
designs the core loop, a leading metric specific to your product, retention out to a year, small "Bold Beat" experiments, and how the product spreads.
New ideas come out as a Hit Plan, and existing products as an Engagement Audit. Either way you also get a short chat summary: the instinct, the recommended bet and its grade, and the test to run this week.
When to reach for it

You don't have to name it. It's meant to trigger on its own when you:
have a product, app, startup or feature idea and ask whether it's worth building, or what to build first;
want to validate, pivot or kill an idea;
are planning an MVP or launch;
want to know why a competitor or hit product works (it does a teardown);
have a live product with an engagement, retention or growth problem ("make it stickier");
are building on a new platform like AI agents, where little is proven yet;
run a product team and want a weekly roadmap discipline.
It works for consumer, prosumer, AI and B2B products. It is not for naming (use business-naming), visual design or writing code.
It's working if

The grade of your idea surprises you a little, and the reason is specific.
You get more than one idea to test, and the test for the first one costs days and little money, not a summer of building.
Every test has a number that means "this is working" and a number that means "stop".
Items labelled Better really would get a yes from every existing user. Anything doubtful has been moved to New.
Competitors are named, with sources and dates, and unverified claims are marked.
The plan answers "why would someone still use this in a year?"
Common questions

Is it just going to tell me my idea is bad?
No. It separates the instinct from the idea, and usually the instinct holds up. What it questions is the specific version you've fallen for, and it hands you several alternatives plus a cheap way to find out which one has real pull.
Why not just build an MVP?
"Viable" usually means months of building before any real signal. The skill tests the riskiest part first with something much smaller: a fake button, an ad, a mock-up stitched from existing products, or doing the service by hand. Once real users show heat, it recommends building properly and launching big.
Can it tell me whether my idea will work?
No, and it says so. Only real user behavior can. What it can do is make the bet as strong as possible and design the fastest honest test.
Why does it take longer than a normal answer?
It researches the products your idea builds on and current competitors, and reads several reference files. In testing, runs took about three times longer than a plain answer, and produced plans with real competitors, isolated tests and kill rules.
Does it only work for games?
No. Many of the examples come from Zynga, but the method has been applied to messaging apps, marketplaces, enterprise chat, TV and retail promotions.
Where it fits

Start here when the question is what to build or why people aren't sticking around. Once you've picked a winner, business-naming can name it.
Source: github.com/alikibao/public-skills/skills/product/hit-products