product-bets

name

product-bets

description

Choose, construct, test, and operate product bets using Life at the Speed of Play (Mark Pincus) - instinct vs idea, Proven-Better-New, Minimum Idea State, the weekly roadmap OS. Use when deciding whether to build a product or feature, testing an idea before writing code, choosing a market or what to copy vs innovate, setting up a weekly product cadence or OKRs, picking a North-Star or leading metric, or when a team ships features that don't move any metric.

Product bets — decide, construct, test, operate

When to use

Any time the question is "should we build this?", "what exactly do we build?", or "how do we keep making good bets week after week". Four procedures, used together or alone: separating the instinct from the idea (before committing), constructing the bet with Proven-Better-New (what to copy, improve, and isolate), testing it as a Minimum Idea State (before building), and running the weekly roadmap operating system (after launch). Core stance: your instinct is right ~95% of the time; your specific idea is right at best ~25% — so fall in love with the instinct and kill ideas cheaply, often, and without grief.

The procedure

1. Separate the instinct from the idea

1. Write both down separately. Instinct = the deep human truth you feel ("getting a taxi should be easier"). Idea = the specific implementation ("order a taxi by SMS"). The instinct survives dead ideas; number the ideas as attempts.
2. Check the body of water before the boat: pick the market first. Criteria: market entry potential (available, not crowded) · proven business (clear path to revenue) · room to innovate (the best are mature markets that are secretly growth markets) · long-term macro tailwinds. "If you choose the right body of water, most boats will float."
3. Apply the B+ test: B+ ideas are good enough to get funding, customers, and hope — and never good enough to be great. Ask: would your smartest friends invest their own money? Are you pursuing this out of desperation? B+ is the enemy of A; kill it before it consumes the quarter.
4. Distrust false positives: smart investors or big partners wanting in is NOT signal. True signal is felt instantly ("f*** yeah", not "this is close").

2. Construct the bet with Proven-Better-New

1. Proven — copy what your target audience already loves, to the pixel. Operational test: "I could rebuild that same interface with the same features, put it in front of the same people, and get the same reaction." Get your PhD in deconstructing the proven products with heat, ideally proven on the same platform for the same audience. You haven't earned the right to change what already works. Best to market beats first to market.
2. Better — only objectively better counts: half the price, no download, one click instead of five — improvements 10 out of 10 users say "yes" to. The classic error: what you think is Better is actually New. Better rarely wins alone except on a platform shift.
3. New — exactly ONE novel element, isolated so it can be tested (and fail) separately without sinking the product. "All New fails" — assume it, so a failure is clean data, not a catastrophe.
4. Placement rules: on a platform shift, ship Proven + Better with no New — the platform IS the New (and it's the single best place to build). In a mature market, you need a genuine New vein to earn trial. Never bet on New without Proven underneath (fool's gold: unrepeatable one-off wins).
5. Guard the other flank: PBN over-applied yields derivative B+ products. Copy to de-risk the base, then pursue actual quality/magic on top — the bar is a product you treasure.

3. Test it as a Minimum Idea State (before building)

1. Replace "minimum viable product" with Minimum Idea State: the smallest artifact that gets directional signal on the idea — a text link, a landing page, a dialog box, screenshots, a 2-minute video, a demo that breaks after ten clicks. "Viable" is an excuse to overbuild and launch late.
2. A ripomatic reaches MIS without code: tell the story of the user experience as a scrapbook of screenshots and mockups from existing products, with realistic copy and content. UI fidelity is irrelevant; the experience must be obvious.
3. Pre-commit the signal bar, then run it twice: Zynga shipped a five-word link that led to a 404 just to measure clicks — 22.7%, twice — then spent 24 hours building the real thing and got a million installs in a week. The pattern: fake door → repeat → build only on repeated signal.
4. Kill hope before hope kills you. Hope is a belief unsupported by data; produce conviction shots, not hope shots. If a feature can be tested with a dialog box in an hour, six months of building it first is malpractice.
5. When true signal arrives, flip modes: build the Maximum Launch Product — overinvest and launch as big as you can. Test timidly, launch boldly, never the reverse.
6. Prefer most shots on goal over best shots on goal — keep cutting the marginal cost of a test toward zero.

4. Operate the weekly roadmap OS (after launch)

1. Weekly meeting, one artifact. Every bet on one shared sheet: feature name · expected business outcome (a number) · engineering-days cost · actual outcome. Expected outcome per engineering day is the currency of prioritization. Open by reviewing priorities, quarterly goals, this month's objectives, and team health; then the sheet drives the meeting.
2. Every team (or solo founder) brings: the hypothesis being tested · expected outcomes per eng-day · actuals vs expected · what was learned and how it changes next week's bets. Target over time: 80% of engineering days are shots on goal — features users may actually want (typical teams run ~20%).
3. Quarterly goals, never changed mid-quarter. Default ambition ~30% quarter-over-quarter on the core metric. The widening gap is the feature: it forces bolder bets instead of safe "mouse nuts" (small increments that quietly make the product worse — and by the Rule of Four, everything costs 2x and takes 2x, so mouse nuts eat quarters).
4. Invent your own metric. Standard metrics (MRR, retention, NPS) are trailing and unmovable — teams ignore metrics they can't move and default to squeezing revenue. Find one that is leading and movable (Zynga's poker: hands played; Words With Friends: turns taken). For durability, track the D365 lens: how many of today's users were also here a year ago?
5. One bold bet per cycle, institutionalized in the quarterly goals: quick to build hacky, quick to test, quick to kill, isolated impact. Success bar: ≥25% of users try it AND it moves a key metric ≥10%. Permission to build it "wrong" now; earn the right to build it right by the reaction.
6. Teach the wins ("teaching hospital"): don't just copy a winning bet across teams — break down how the opportunity was spotted, how the cost was estimated, which metric moved and why.
7. Open and close the meeting with: "What will our users thank us for?" — the standing counterweight to metric-squeezing.

Rules and quick reference

Rule	Meaning
Instinct 95% / idea 25%	Keep the gut truth, kill the implementation. Prosecute your own ideas.
B+ is the enemy of A	Good-enough ideas that never become great are the most expensive kind.
All New fails	So isolate the one New thing and test it separately.
What you think is Better is actually New	Better must be objective (10/10 "yes"), or it's a risk to isolate.
Kill hope before hope kills you	Any belief without data is hope; test it this week or drop it.
Most > best shots on goal	Volume of cheap tests beats polish of few tests.
Mouse nuts	Small safe features that make the product worse; the default failure mode of a stable team.
Rule of Four	Everything costs twice as much and takes twice as long as planned.
Altitude	Announce the level you're operating at — ground details, strategy, or vision — so a discussion doesn't mix them.
Focus group of one	One person who perfectly represents the audience (often you) outweighs diffuse data — then validate it scales.

Where it doesn't transfer

The evidence base is free-to-play social games — ultra-high-frequency, virality-distributed, whale-monetized. Translate accordingly:

• The engagement machinery is games-specific. The game-mechanics catalog, 60% DAU/MAU bars, hourly-active-users, and feed-driven viral loops don't map to low-frequency, considered-purchase, or B2B products. Keep the shape (leading movable metric, bold-bet bar); recalibrate every number. For products used monthly or yearly, the D365/annual-return lens is the honest one, not daily actives.
• "Copy to the pixel" has a failure mode the author admits: it tends to produce B+ me-too products. Use Proven to de-risk market entry, not as a ceiling on ambition.
• The track record is survivorship-flavored (the author's claimed ~80% hit rate came with a post-IPO crater he also describes). Treat the numbers as one operator's priors.
• The culture chapters (micromanagement, no one-on-ones, moral contracts) are a separate, contested management philosophy — out of scope for this skill; adopt deliberately or not at all.
• Solo founders: the weekly meeting still applies — it becomes the weekly retro with your agent over the decision journal; "teams" collapse to you, and eng-days to your hours.

Source

Compiled from Life at the Speed of Play — Mark Pincus (2025). The skill is the procedure; the book carries the depth (worked examples, edge cases, the author's reasoning). If this stage is where your venture lives right now, buy and read it.