The Diversified Roadmap Portfolio
Treat a product roadmap like an investment portfolio, balanced across three axes of risk and intent.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 83%
Weiss frames a feature team's roadmap as a diversified portfolio rather than a flat backlog. It should be balanced across three tensions: new capabilities vs. making what exists a little better every day; risky high-upside bets vs. known bets; and work meant to drive confident impact vs. work meant to learn about a new possibility space. Slack operationalizes the 'better every day' bucket through time-boxed Customer Love Sprints.
Origin
Articulated by Noah Weiss as Slack's approach to roadmap construction across feature teams.
Core principles
- 01A healthy roadmap is deliberately diversified, not concentrated in one type of bet
- 02New-capability work and incremental-improvement work must both be funded
- 03Learning-oriented work has value even when it drives no immediate metric
- 04Balancing known bets against risky bets prevents both stagnation and reckless swings
How to run it
- 1
Split by new vs. incremental
Allocate roadmap capacity between building genuinely new capabilities and making the thing you've already shipped a little bit better every day.
- 2
Balance risky bets against known bets
Include some bets you aren't sure will work but that carry large upside, alongside bets whose outcome you're already confident in.
- 3
Balance impact work against learning work
Separate work meant to drive impact you're already confident in from work meant to learn about a new possibility space, and fund both intentionally.
Watch out Don't let confident-impact work crowd out learning work — the learning bets are what surface the next levers with years of room to run.
- 4
Fill the 'better every day' bucket with Customer Love Sprints
Because small polish work is hard to allocate across a quarter, run a dedicated two-week sprint on the lowest-effort, highest-impact changes to generate customer love.
Pro tip Aim to ship all of them — this isn't throwaway hack-week code — and run it at least once a quarter for very user-facing teams.
In the wild
Slack teams run a two-week 'customer love sprint' — like a hackathon but working off a burn-down list of the lowest-effort, highest-impact changes that generate customer love in a feature area. Design, product, and engineering sprint together and demo a batch of shippable delight fixes at the end.
→ Small delightful improvements that customers love get shipped (not thrown away), and the change of pace re-energizes teams between multi-month feature efforts.
Common mistakes
Running a roadmap of pure incrementalism
Concentrating only on making existing metrics tick up a percent a quarter loses sight of what's beyond the horizon and starves the bigger, bolder bets that create new S-curves.
Refusing to fund learning bets
Because learning work may drive no metric this quarter, it gets cut first — but killing it means never discovering the new levers that pay off over years.
Is it for you?
Best for
Product leaders and PMs constructing a quarterly or annual roadmap for a maturing product with multiple feature teams.
Not ideal for
Very early startups still searching for initial product-market fit, where focus beats diversification.
From the transcript
“the way that we think about it or I like us to think about our roadmap for any feature team at slack is that it's…”
“are there things that are meant to be risky that you aren't sure are going to work but might have a lot of upside there's…”
“almost like a hackathon but with that kind of burn down list of what we think is the lowest effort highest impact changes we can…”
From the episode
The 10 traits of great PMs, how AI will impact your product, and Slack’s product development process
Noah Weiss (Slack, Foursquare, Google)