Key Takeaways

  • Nik Storonsky rejects founder intuition for product development because his own guesses failed repeatedly during Revolut's early years.
  • Revolut isolates new initiatives into capped squads of up to 10 people, giving them 9 to 18 months to build and launch.
  • Product success is tracked by month-over-month gross profit growth compared against historical internal cohort benchmarks.
  • Features that fall into the bottom 25% of historical cohorts get sunset without debate, while top-quartile bets receive exponential capital and team expansion.
  • This discipline is codified in Storonsky's Algorithmic Bet Funding and Pruning System.

The Storonsky's Algorithmic Bet Funding and Pruning System

Step 1: Bet Proposal and Committee Approval

A product bet is originated either bottom-up or top-down and presented to an internal committee to evaluate whether funding the bet makes analytical sense.

Step 2: Seed Capped Cross-Functional Squads

Isolate a dedicated team capped at up to 10 people (traditionally 3-4 back-end developers, 2-4 front-end developers, 1 product owner, 1 designer, and optional data science or operations roles; compressing to 2-3 people with AI tooling).

Step 3: Rapid Execution Window

Give the team a fixed development timeline of 9 to 18 months to build, ship, and launch the new product into the market.

Step 4: Gross Profit Benchmark Comparison

Measure post-launch trajectory strictly by gross profit (GP) growth month-on-month, benchmarking the new product against historical cohorts of all previously launched bets.

Step 5: Algorithmic Cut or Exponential Scale

If the bet tracks in the bottom 25% cohort historically, sunset it immediately within 18 months. If it ranks in the top quartile (e.g., 10-20% month-over-month growth generating recurring GP), double down aggressively, expanding one team into multiple teams, a department, and a major P&L line.

When This Works (and When It Doesn't)

This system works inside scale-up and enterprise engineering environments to eliminate subjective executive intuition, eradicate internal corporate politics, and guarantee resources automatically flow to compounding winners. Storonsky built it after realizing that loose tracking let stagnant projects burn engineering hours indefinitely. “Even myself, I don't really trust my intuition in terms of which products to build, which products not to build because historically I was wrong so many times,” Storonsky noted. “Top bets you continue to fund, bottom bets you just cut within 18 months.”

Where this model fails is early-stage discovery before true product-market fit exists. If you run a seed-stage startup with no baseline data, comparing a feature against nonexistent historical cohorts is impossible. The model also stumbles on strategic loss leaders: infrastructure or compliance projects that produce zero direct gross profit but protect the core banking charter or lower transaction costs company-wide.

What to Do With This

Audit your active product roadmap tomorrow morning. Group every feature started in the last 12 months into a single spreadsheet.

Assign each initiative a single cross-functional owner and record its net gross profit generated over the last 90 days. If you lack historical cohorts, stack-rank your current projects by their gross profit contribution relative to engineering headcount.

Identify the bottom quartile of those initiatives. Pick the single worst-performing feature, call the team together before noon Friday, and shut it down. Reallocate those engineers directly to the single bet showing double-digit monthly profit growth.