Every product team faces the same uncomfortable tradeoff: ship the obvious incremental improvements that customers ask for and stakeholders expect, or invest in the ambitious bets that might unlock the next growth curve. Choose all incremental and the product stays alive but stops mattering. Choose all moonshots and the team burns out before any of them lands.

The honest answer is not either side. It is a deliberate allocation that protects both. This article distills a workable framework from Adrian Bryant's analysis on ProductPlan and adds the guardrails that make it survive quarterly pressure.

Why most teams default to short-term wins

Three forces push roadmaps toward the incremental:

  • Customer requests are loud and specific. Big bets are speculative; bug fixes and small features come with named requesters and clear scope.
  • Quarterly reviews favor visible output. Five small features shipped on time look better in a board deck than one big bet still in discovery.
  • Sales pipeline pressures. Every "we lost this deal because we do not have feature X" is a forcing function. Few sales people lose deals for the absence of a moonshot.

The result is roadmaps that win every quarter for two years and then suddenly look obsolete because no one was building the next thing while the incremental wins compounded.

The 70/20/10 allocation

Borrow the model from Google's old innovation framework, adapted for product roadmaps:

  • 70% of capacity on core work: maintaining the product, fixing real issues, shipping requested improvements that compound user satisfaction.
  • 20% on adjacent bets: extensions of the core product into nearby use cases or audiences. Higher risk than core, lower than moonshots.
  • 10% on big bets: ambitious initiatives with uncertain outcomes and big potential upside.

The exact percentages can shift by stage (early-stage startups skew more 50/30/20, mature products often slide to 80/15/5). What matters is the principle: protected allocation. The 10% is not what is left over after the 70% finishes. It is reserved capacity that gets defended.

Without protection, big bets always get eaten by short-term wins. Quarterly pressure is asymmetric: the cost of skipping a moonshot this quarter is invisible. The cost of skipping a feature request is loud.

Three guardrails that keep the allocation honest

Guardrail 1: a separate capacity bucket

Make the allocation explicit in the roadmap tool. A team that works on a 10% big bet should not also be picking up incremental tickets that week. Mixing capacities means the incremental always wins because it has clearer deadlines.

Guardrail 2: different review cadences

Review incremental work weekly (what shipped, what is next). Review big bets monthly (what was learned, what is the next experiment). The big bet does not move on the same clock; reviewing it weekly creates artificial pressure to show progress that does not exist yet.

Guardrail 3: a portfolio view, not a per-feature view

Stop asking "will this feature succeed?" Start asking "is the portfolio balanced?". Big bets are supposed to have high failure rates. A 10% allocation where 70% of attempts fail is fine if the 30% that work produce 10x outcomes. A 100% allocation with 0% failures means the team is not actually swinging.

How to identify a real big bet vs a disguised feature

Many things get called big bets that are just larger features in disguise. A real big bet has three properties:

  • Uncertain outcome: you genuinely do not know if it will work. If the team can predict the ROI in advance, it is not a bet, it is a project.
  • Multi-quarter horizon: the time from start to validated outcome exceeds one quarter. Bets that resolve in 4 weeks belong in the 20% adjacent bucket.
  • Strategic optionality: if it works, it opens new paths. If a winning bet only optimizes the existing path, it is incremental work with a bigger price tag.

Communicating the split to stakeholders

The hardest part of this allocation is not deciding it. It is defending it in front of executives, sales, and customer success when each one is pushing on the 70%. Two communication moves help:

  • Make the bet visible. Show the 10% explicitly on the public or internal roadmap, with the hypothesis. Stakeholders cannot complain about invisible work.
  • Report learnings, not deliverables. For big bets, your quarterly update is "we tested X, learned Y, next we will try Z". Not "we did not ship anything yet." The first is a portfolio update; the second sounds like failure.

What changes after one year of disciplined allocation

Teams that defend the 70/20/10 split for four quarters in a row report a few common changes:

  • One or two big bets actually land and reshape the product
  • The pipeline of "next big bet to try" is full because the team has been generating hypotheses for a year
  • Stakeholders adjust expectations and stop asking why moonshots are not shipping every two weeks
  • The team has a story to tell beyond "we shipped 47 features this year"

The takeaway

The default gravitational pull of any product organization is toward all-incremental. Without explicit allocation, big bets get squeezed out by quarterly pressure. The 70/20/10 split with protected capacity, different review cadences, and portfolio thinking keeps both sides funded. It is uncomfortable for the first two quarters and obviously correct by the fourth.