Roadmapping — Part 4: Outcomes-based roadmap

Outcomes-based roadmaps focus on long-term strategic goals while accommodating new learning. They emphasize solving problems or achieving goals for users, with flexibility built-in.

Conventional roadmaps

In the world of Product Management, roadmaps are indispensable tools. They guide teams, align stakeholders, and provide a sense of direction. If you’ve spent any time in Product Management, you’ve undoubtedly heard varying and conflicting advice on roadmaps. Chances are you’re most accustomed to traditional roadmaps. But what is a conventional roadmap anyway?

This post was originally published on Roadmap Weekly.

Traditional roadmaps, familiar to many, often resemble Gantt charts — detailed, timeline-focused, and heavily reliant on specific deliverables and dates. These roadmaps are project-based, delineating tasks like ‘Design,’ ‘Development,’ ‘Testing,’ and ‘Release’ along a clearly defined timeline. While traditional roadmaps offer structure and clarity, they also come with limitations, particularly in a product-led organization that values agility and innovation.

Representation of a traditional waterfall-style roadmap

The Downsides to Traditional Roadmaps

1. Estimated timelines: Often, these roadmaps carry timelines based on estimates, leading to potentially unrealistic expectations.
2. Predetermined solutions: They lock in solutions early, leaving little space for ongoing innovation and discovery.
3. Risk of delays: Any change can cause significant disruptions with rigid waterfall dependencies.
4. Time buffering: As a Product Manager, you add significant time buffers to your work to help ensure you hit deliverable dates. Engineers do the same, and then the Engineering manager adds their buffer. Even your upper-level VPs may add a buffer.
5. Parkinson’s law: This principle states that work expands to fill the time provided, and with all these buffers, it’s evident…