Feature roadmaps are a mass delusion

Feature roadmaps are a lie, a mass delusion that the company buys into, only to get let down when it doesn’t come true. And yet, we can’t seem to quit them.

Lies told by feature roadmaps:

Step 1: We know exactly what work needs to be done to solve a business and/or customer problem.¹

Step 2: We know exactly how long it will take in order to complete that work.²

Step 3: We know exactly how many resources we’ll need for that amount of time.³

Step 4: Therefore, we can allocate the remaining resources to other work. Repeat Step 1 with the remaining resources.⁴

Step 5: Because of Step 1 and Step 2, we can present the roadmap to external customers, too. But we’ll lie to them because if we told them the truth, it would expose the fact that we know it’s a lie too.

What inevitably happens is the roadmap proves itself to be the lie that it is.

But instead of rejecting the roadmap as a faulty tool, the Product and Engineering teams get blamed for missing their deadlines and are told to increase their velocity and improve their estimation.

So we get into this cycle where build teams focus on improving velocity and internal process — better estimation by having more requirements up front, breaking projects down into smaller tasks, more frequent communication and status updates, additional documentation with stakeholder sign-off meetings so that what gets built is more likely to be “approved” for launch — and that makes them deliver actual company and customer value slower.

I’m out of room today, but in a future post I’ll talk about what I like better, which is hypothesis-based roadmaps paired with OKRs.

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.

Back in October, researchers from Harvard, German Institute for Economic Research, and Imperial College published a paper claiming Generative AI has led to a 21% decline in online freelancer job opportunities (the summary article; the actual paper).

Lots of the usual reactions: every disruptive technology eliminates some jobs and creates new ones, but that doesn’t put food on the table for those affected today; the quality of AI work is poor right now and you get what you pay for; etc.

Setting those aside for now, it got me thinking about what this means for marketplace operators. If GenAI can solve the needs of your demand-side customers, should you risk cannibalizing your supply in order to give it to them?

Google clearly has decided their answer is “yes”, with their inclusion of AI Overview Answers at the expense of clicks out to publishers.

Should Shutterstock offer AI-generated images next to professionally created stock photography? Should Upwork build its own logo generator or code snippet generator?

My hunch is that this is kind of like when open source became more mainstream. There were fears that commercial software as an industry was doomed because everyone would switch to open source.

But it turns out that words (or pixels) are cheap. The value is in how you put them all together. And open source companies ended up becoming really valuable businesses in their own right because making it work for you is worth paying for.

So I’d say, yes, marketplace operators should build in the GenAI tools for the demand side of the marketplace. And, create job opportunities for your supply side to help make it work for them, when they inevitably are dissatisfied with what they did on their own.

1  If the company is output and not outcomes based, they might completely miss the lie that is Step 1 and be confused why the company isn’t performing better.

2  Most likely, Step 2 proves false, and the work takes longer than we thought or, if we were really sandbagging, shorter than we thought. And all the pressure from the organization gets misdirected into demands for more velocity and better estimates.

3  Roadmaps tend to be political documents as much as they are operational ones. Stakeholders want to see their needs reflected in it. So there is pressure to split teams into parallel swim lanes, so that we can avoid saying no. What gets forgotten is that while software is work-in-progress, its actual value to the company and to customers is zero. So spreading your resources thinly across a wide range of initiatives, all of which will now individually take longer to complete, significantly reduces the value per year delivered to the company and to customers. A better approach is to swarm all resources towards a single outcome, up until diminishing returns (Mythical Man Month is still real), and then swarm to the next best thing, and repeat.

4  Teams often over-allocate because they forget to account for meetings, time off, fixing bugs, unexpected fires, urgent unplanned work, not to mention time for paying down tech debt or product debt. I encourage my teams to set aside 20-30% every quarter to non-OKR work.