Quarterly planning is not roadmapping

I used to approach quarterly planning as a roadmapping exercise: combine the needs that I see with the needs of my stakeholders, rank them according to some kind of ROI framework like RICE, and turn it into a Gantt chart¹ for stakeholder sign-off.

I was so wrong.

First of all, if you don’t have Product Market Fit, you don’t need to do any quarterly planning or have a roadmap. Your only job is to find PMF.²

If you do have PMF but it’s still early days, my old approach isn’t the worst, because there are big gaping holes that need to be filled and fires that need to be put out. There are so many table stakes features and tools that are missing, the risk of solving the wrong problem is minimal.

But once you’re at a stable size (say, $8-10M in post-PMF revenue), treating quarterly planning as a pure prioritization exercise is a mistake.

It’s a mistake for two reasons:

1. As a larger business, maintaining a double digit growth rate gets harder and harder. The low hanging fruit has mostly been picked.

2. Knowing ahead of time exactly what we need to build gets harder and harder as the product gets more optimized.

What’s needed to address #1 is a cohesive strategy that aligns the resources of multiple teams to work together towards a bigger outcome, to achieve something that would be difficult or impossible for any one of them to achieve on their own.³  

Addressing #2 is shifting stakeholders from expecting outputs to expecting outcomes. Hold teams accountable for delivering on those outcomes, and give them the autonomy to use Discovery tools to uncover the best ways to achieve those outcomes.

So if you are in quarterly planning now and find yourself doing the same old roadmapping exercise you’ve always done, take the time to ask if this time we should try something different.

The Workshop

This is a newsletter-only section where I share a half-baked idea in hopes that y’all who are smarter than me can work it out with me.

Silicon Valley has a history of pumping out massively funded startups that are terrible ideas. The Humane AI Pin being the latest (NYT gift link) and the Juicero being one of my favorites (Wikipedia).

Defenders of Silicon Valley would probably argue that this is the cost of doing business, that dreaming big (fueled by VC dollars) is what leads to the incubation and birth of some of the greatest companies ever, even if there are some flops along the way.

I have a different take, which is that, for all the good things that make SV a uniquely special place, there is also a toxic streak of “I’m the next Steve Jobs” and “the world will soon be thanking me for the fruit of my genius” hubris.

Which is exactly the opposite of what good Product people would say and do.

What I really don’t understand is why VCs will invest crazy amounts of dollars into founders who are not showing themselves to be good at Product. Maybe it’s ego mixed with FOMO: they both want to be the next genius investor who was early money into the next Google and they don’t want to be the next investor who could have and said no.

Maybe they can’t tell the difference between a good Product founder and someone who isn’t. If that’s the case, I’d like to better understand why. For all their skill at pattern matching, why is this one so hard?

1  Gantt charts are such a colossal waste of time. It’s kind of like detailed 3 year financial models made by early stage startups: all precision, no accuracy.

2  As measured by: 1) top of funnel conversion reach and conversion rates to validate the problem we’re solving and value prop; 2) engagement and/or purchase rates + qualitative feedback to validate we’re successfully delivering on the value prop; 3) a repeatable and scalable GTM strategy that shows we know how to spend money to grow

3  I know, I know: easier said than done. Find the harder problems that have been tougher to move but are also becoming more and more existential for future success. Usually these are retention problems, either literally (for subscription products) or behaviorally (customers use us for one use case but not multiple use cases). Chances are, a whole-of-product approach is needed to identify and solve the problem that siloed squads can’t.