# 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: *Prepared . 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:** - **Recommended bet:** — grade because - **Run this week:** - **Don't build:** ## 1. What the numbers say ## 2. The core loop ## 3. Leading metric ## 4. Motives and social structure ## 5. Shots on goal | # | Bet | PBN tag | Grade | Why | |---|---|---|---|---| | 1 | | | | | | 2 | | | | | | 3 | | | | | ## 6. Proven Better New for the recommended bet **= Proven** — from **> Better** — <10/10 improvements> **+ New** — ## 7. Experiments (Bold Beats and probes) | Order | Experiment | Hack version | Audience / % exposed | Metric | Heat threshold | Kill rule | Time box | Eng days | |---|---|---|---|---|---|---|---|---| ## 8. Quarter plan ## 9. Anti-patterns to stop ## 10. Distribution (if relevant) ## 11. What will users thank you for? ======== FILE: assets/hit-plan-template.md ======== # Hit Plan: *Prepared . 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:** - **Recommended first shot:** — grade because ; confidence , and the evidence that would change it - **Test this week:** - **Biggest risk:** ## 1. The instinct ## 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 | | | | | | | 2 | | | | | | | 3 | | | | | | | 4 | | | | | | ## 4. Proven Better New: **= Proven** (this audience, this platform) - — from — keep as is **> Better** (10/10 current users would agree) - — why it's objectively better **+ New** (assume it fails; test it in isolation) - New #1: — the risk it carries - Backup News: <#2>, <#3> *Moved from Better to New because they fail the 10/10 test:* **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:** **If no heat:** ## 6. Engagement and retention design - **Core loop:** - **Leading metric (invented for this product):** - **Retention picture:** D1 · D30 · D365 story: - **Motives served:** - **Mechanics chosen (and why they serve the core loop):** <...> - **First Bold Beats:** — kill rule> ## 7. Distribution and cold start ## 8. Honest risks and open questions - - - ## 9. What will users thank you for? ======== 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: Audience and platform: Context: , and why the timing worked Core loop: Heat: frequency × intensity ; evidence: = Proven (what it reused, and from where) - — from ... > Better (what it improved that 10/10 users of the source would agree on) - — why it's objectively better ... + New (what was novel for this audience and platform) - — the risk it took; how it could have been tested cheaply Distribution: Retention engine: What didn't work / what changed later: <...> Lessons for : ``` 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 ``` ## roadmap — week of Objective (this quarter): Key results: Status: green / yellow / red Capacity: eng days this week; <% on future growth> (redline < 25%) Bold Beat this quarter: — target ≥25% try, ≥10% lift on | 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.