Launch a Free Shuffle-Only Tier Using Premium Engagement Data
Outcome: If premium users spend ~50% of time shuffling, offer shuffle-only access for free — it captures roughly half the value but never 100% of any user's need, minimizing cannibalization while driving top-of-funnel growth.
“Gustav Söderström — How Spotify Thinks — Gustav Söderström on Invest Like the Best”
- 1
Analyze premium user behavior to identify the single highest-usage feature or mode.
At Spotify, 50% of premium listening sessions were shuffle.
- 2
Model cannibalization risk: confirm that the feature represents a large share of aggregate usage but not 100% of any individual's consumption.
If it's 50% of sessions, no user relies on it exclusively, so free access won't fully replace premium.
- 3
Launch a free tier restricted to that single mode (e.g., shuffle-only playback).
At Spotify, this became the free mobile experience.
- 4
Track both free-tier growth and premium conversion/churn to validate the no-cannibalization hypothesis.
Spotify saw 'growth explode' without material premium erosion.
Stop or pivot when
- →If the feature accounts for ≥100% of any significant user cohort's usage, cannibalization risk is too high
Before you start
- · Detailed usage telemetry by feature/mode
- · Ability to gate features at the product level (e.g., shuffle vs. on-demand)
- · Willingness to launch a lower-value tier despite internal skepticism
freemium-tier-designgrowthcannibalization-modeling1-1010-50
Run a multi-year co-president apprenticeship before handing over the CEO seat
Outcome: Transfer escalating operational control to your successor over years so the title handover is low-risk.
Context: Daniel Ek named co-presidents three years out, widened their rope from daily to weekly to monthly P&L ownership, and kept only external/ceremonial duties to transfer at the end.
“already about three years ago he asked me and Alex Nordstrom to step up and become co-presidents and sort of start to run the, the day-to-day of Spotify for him. He was still the CEO and so he is been gradually like giving us more and more rope to, to run the, the business day to day and week to week and then month to month.”
2-3 years before handover per
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Before you start
- · A founder genuinely willing to delegate
- · A successor with enough tenure to hold institutional trust
- · Board alignment on the transition timeline
Take the distribution pain of a single app instead of shipping a separate one
Outcome: When distribution is the binding constraint, build into your existing app rather than shipping a standalone.
Context: Seeing 7+ good podcast apps stuck near 0% share against Apple's 98.5%, Spotify judged distribution (not product) the real problem and built podcasts into its 300M+ user app despite the engineering pain.
“is that the biggest problem to design the experience or is the biggest problem actually getting distribution? ... I think Apple Podcast was still like 98.5%, all of them. So like the problem wasn t that there wasn t a good enough podcast product, the problem was that they didn t get a distribution. So we chose to take the pain of doing a single app with all the complexity that comes with that for the benefit of reaching what was then already 300 something million users”
per major product expansion per
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Before you start
- · A large existing distribution surface / installed base
- · Engineering capacity to absorb multi-model backend complexity
- · Willingness to take the harder build for the larger reach
Merge separate leadership meetings into one synchronized all-functions weekly
Outcome: Replace siloed leadership meetings with one weekly all-functions meeting so blockers resolve in real time.
Context: Spotify's co-presidents killed separate product and business leadership meetings in favor of a single 3-hour Tuesday "ET" meeting with ~14 SVPs across all functions, banning "take it offline."
“We chose to say we re not gonna have our own leadership meetings. We have a single one with all of our SVPs. So we have a single meeting every Tuesday called ETE for three hours with all the SVPs of, of all the internal functions like you know, marketing ads, subs, but also, you know, all the product and technology functions in the same meeting.”
3 hours, weekly per
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Before you start
- · A single unified product/experience strategy that justifies the coordination cost
- · Senior leaders willing to sit through non-immediately-relevant discussion
- · Tolerance for high leadership time spend
Run an anonymous third-party "regret" survey across all competing platforms
Outcome: Measure how much time users regret — anonymously, third-party, across all platforms — to surface value vs capture.
Context: Spotify ran a blind third-party survey across Spotify, YouTube, Apple Music, Amazon, TikTok et al., asking both satisfaction and regret; it found Spotify lowest-regret and some platforms at 60%+ regret, which became the basis for the "time well spent" strategy.
“We surveyed our users through a third party anonymously... We asked the question like, how do you feel about the time you spent... But then we also asked the opposite question, how much of your time did you regret afterwards? ... we were actually the lowest regret content sort of on the internet”
periodic (ongoing competitive tracking) per
- 1
- 2
- 3
- 4
- 5
- 6
- 7
Before you start
- · Budget for third-party blind research
- · Willingness to act on an unflattering finding about your own product
Run Six-Month VC-Style Bet Pitches with Stack-Ranked Resourcing
Outcome: Every six months, VPs pitch bets as if to a VC, the company stack-ranks them (e.g., 1–44), then resourcing teams work top-down until capacity is exhausted, ensuring only the highest-conviction initiatives get funded.
“Gustav Söderström — How Spotify Thinks — Gustav Söderström on Invest Like the Best”
six months40 per 180 days
- 1
Hold a pitch session every six months where VPs present their proposed bets as if pitching a VC.
Treat the session formally; each VP makes the case for why the company should back their initiative.
- 2
Stack-rank all submitted bets from highest to lowest priority.
The example given was 44 bets ranked 1 through 44; typical range is 30–50 bets.
- 3
Hand the ranked list to resource-allocation teams and start resourcing from the top.
Teams work down the list until they hit capacity (e.g., 'maybe they get to 30' out of 44).
- 4
Commit only the top bets that can be resourced over the next six months.
Unfunded bets below the cut line are deferred or killed for the cycle.
Stop or pivot when
- →If a bet cannot be resourced after working top-down through the stack rank, it is not executed in that cycle
Before you start
- · VP-level or equivalent leadership team with ownership of strategic initiatives
- · Ability to estimate resourcing capacity for a six-month window
- · Organizational willingness to kill or defer lower-ranked bets
roadmap-prioritizationresource-allocationportfolio-management10-5050+
Require a Falsifiable Theory Before Launching Winning A/B Tests
Outcome: Even when an A/B test shows positive results, insist that the team articulate a 'hard to vary' explanation for why it works before you ship — ensuring the learning scales across the organization.
“Gustav Söderström — How Spotify Thinks — Gustav Söderström on Invest Like the Best”
- 1
Run the A/B test and observe the metric lift.
Standard experimentation; measure whether the treatment wins.
- 2
Before greenlighting launch, ask the team for a theory that explains why the test worked.
The theory must be falsifiable, have reach (scale), and be hard to vary (changing one parameter breaks the predictiveness).
- 3
If no coherent theory emerges, hold the launch or run additional experiments to uncover the mechanism.
Pattern recognition alone ('it worked in the test') is not sufficient justification.
- 4
Document and share the theory so the entire org can apply the learning to future decisions.
This is how insights compound across teams.
Stop or pivot when
- →If the team cannot articulate a hard-to-vary explanation, do not launch the winning variant
Before you start
- · Active A/B testing infrastructure
- · Organizational norm that metrics alone do not justify launches
- · Leadership willing to delay or reject statistically significant wins without theory
experimentation-rigorknowledge-scalinglaunch-gating1-1010-5050+
Hold a Weekly All-VPs Escalation Meeting with No-Offline Rule
Outcome: Run a recurring all-VPs meeting (e.g., Tuesday) where blocked issues are escalated, 'offline' discussions are banned, and no direct reports attend — forcing senior leaders to resolve cross-functional blockers in real time.
“Gustav Söderström — How Spotify Thinks — Gustav Söderström on Invest Like the Best”
ongoing weekly cadence1 per 7 days
- 1
Schedule a weekly all-VPs escalation meeting (e.g., every Tuesday).
With five-day work weeks, no one waits more than 2.5 days on average to escalate a blocker.
- 2
Enforce a 'no offline' rule: when someone says 'let's take that offline' or 'I'll talk later,' immediately require resolution in the room.
The goal is to eliminate deferred decisions and force closure on the spot.
- 3
Ban direct reports from attending; only VPs may participate.
This forces VPs to own details and resolve issues themselves rather than delegating on the fly.
Before you start
- · VP-level or equivalent leadership cohort who own cross-functional outcomes
- · Cultural buy-in to real-time decision-making and no deferral norm
escalation-hygienecross-functional-coordinationdecision-velocity10-5050+