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.
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.
The Downsides to Traditional Roadmaps
- Estimated timelines: Often, these roadmaps carry timelines based on estimates, leading to potentially unrealistic expectations.
- Predetermined solutions: They lock in solutions early, leaving little space for ongoing innovation and discovery.
- Risk of delays: Any change can cause significant disruptions with rigid waterfall dependencies.
- 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.
- Parkinson’s law: This principle states that work expands to fill the time provided, and with all these buffers, it’s evident how it applies widely here.
Embracing outcomes-based roadmaps
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 into the development cycle. Example: Improve onboarding experience and increase early user activation from 30% to 45%.
- Goal-oriented: Outcomes such as improving the onboarding experience or increasing user activation rates are prioritized.
- Flexible timeframes: While timelines are still important, they are more adaptable to new insights and learnings.
When to use outcomes-based Roadmaps
These roadmaps suit any project, especially those with high uncertainty or continuous learning needs. They are particularly effective in environments where innovation and adaptability are prioritized over strict adherence to specific deliverable dates.
Anyone can use an outcomes-based roadmap. You can add outcomes-based items to your regular Roadmap or focus entirely on outcomes across your Roadmap.
The benefits of outcomes-based roadmaps
By focusing on outcomes and over-delivering predetermined features, you can adjust your development plan and implement an iterative approach that includes a quicker feedback loop without being locked into a specific solution.
- Flexibility: This method allows for adjustments in the development plan, accommodating new insights without being wedded to a predetermined solution.
- Value-centric: Ensure teams work towards meaningful, value-adding user outcomes.
- Team motivation: Teams are more engaged when working towards impactful outcomes when completing the next task.
Challenges of outcomes-based roadmaps
Open-ended outcomes are never complete, so focusing on what you’re trying to achieve is essential.
- Never-ending outcomes: Open-ended goals require careful management to ensure continued progress.
- Need for clear definition: Outcomes must be well-defined and achievable within reasonable timeframes.
- Measurability: It’s crucial to have metrics in place to know when an outcome has been successfully achieved.
Preparing for an outcomes-based roadmap: Key considerations
Transitioning to an outcomes-based roadmap is not just about changing the format of your planning documents; it’s about adopting a new mindset. Here are some crucial factors to consider before you embark on this journey:
Define clear, achievable and measurable outcomes.
- Specificity: Outcomes should be specific enough to provide clear direction. For instance, rather than aiming for “improved customer satisfaction,” target “increasing customer satisfaction ratings by 20% within six months.”
- Alignment with business goals: Ensure each outcome aligns with your organization’s broader goals. This alignment helps secure stakeholders’ buy-in and keeps the team’s efforts focused on what matters most.
- Quantifiable metrics: Attach measurable indicators to each outcome. If you plan to enhance the user interface, define success in measurable terms, like “reducing the average user task completion time by 30%.”
Be ambitious but realistic.
- Realistic timeframes: While we want to be ambitious, ensure that the timeframes for achieving outcomes are fair. Consider past project timelines and current resource capacities when setting these goals. Be sure to allow time for learning and feedback signals.
- Flexibility: Allow some flexibility in your Roadmap. As new information and feedback are gathered, be prepared to adjust your outcomes or the strategies to achieve them.
- Regular reviews and adjustments: Set up frequent checkpoints to assess progress towards these metrics. This practice helps track progress and allows for timely adjustments if an outcome seems off track.
Foster a culture of continuous learning.
- Collaborative goal setting: Involve your team in setting these outcomes. Doing so fosters a sense of ownership and can lead to more innovative approaches to achieving your goals.
- Embrace experimentation: Encourage a culture where experimentation and learning are valued. This approach is crucial in an outcomes-based framework where adaptation and innovation are essential.
- Feedback loops: Establish robust feedback mechanisms, both internally among the team and externally from users or stakeholders, to continually inform and refine your approach.
Communicate the Roadmap clearly.
- Transparent communication: Communicate the outcomes-based Roadmap to all stakeholders, explaining the rationale behind this approach and how it differs from traditional methods.
- Regular updates: Keep stakeholders informed about progress and challenges. This transparency builds trust and ensures continued support for the initiative.
Considering these factors, you can lay a strong foundation for a practical outcomes-based roadmap that aligns with your strategic goals, adapts to changing circumstances, and fosters a more dynamic and responsive product development process.
How to pitch an outcomes-based roadmap to your team
Adding specific outcomes to your existing Roadmap can be a helpful way to start if specific features or solutions still require research or discovery.
- Highlight Traditional Roadmap Limitations: Discuss challenges with traditional time-based roadmaps and how they can hinder innovation and delay product value delivery.
- Start Small: Propose including one outcomes-based item on the following Roadmap.
- Address Estimation Challenges: Use past experiences to show how complex accurate time estimations can be and how an outcomes-based approach can mitigate this.
- Collaborate with Sales: Often, deadlines originate from commitments made to customers. Working with sales to set realistic expectations can be crucial. Find a champion within the sales team who wants to learn more about agile product development and product lead growth.
Conclusion: Embracing a new roadmapping philosophy
Transitioning to an outcomes-based roadmap represents a paradigm shift from a task-and-timeline focus to one centred on goals and impact. This approach fosters innovation, responsiveness, and company-wide alignment on delivering user value, unlocking new opportunities and creativity in product development.
This post was originally published on Roadmap Weekly.
Roadmaps aren’t intended to remain static. We’ll explore some ways to help keep your roadmap fluid and up-to-date as things change.
How do you decide what gets put on your roadmap?
When should you add Milestones to your roadmap? What constitutes a milestone?
Part 4: Outcome-based roadmaps 👈
This type of roadmap focuses on outcomes over features or solutions.
Avoid concrete timeframes and focus on priorities.
The roadmap you build for your dev team differs significantly from what you would create for your stakeholders and customers.
How layering shows different levels of detail within your roadmap for various stakeholders and taking a simple approach to maintaining them.
Let me know if there’s anything else about roadmaps you want to see expanded on, and I’ll develop this series more if there’s enough interest.