Skip to content

Outcome-Oriented Roadmaps

What is it?

An outcome-oriented roadmap is a tool for product teams to communicate vision, strategy, and direction to a variety of audiences. Your roadmap is a central, high visibility artifact and the first version usually gets built as an output of the initial Discovery and Framing phase. This roadmap outlines the desired results or outcomes that an organization aims to achieve over a specific period.

Why do it?

The purpose of a roadmap is to align the product team, stakeholders, and users on planned value delivery.

When to do it?

An outcome oriented roadmap is built during strategic planning or whenever clarity, direction, and focus on achieving specific results are needed. For example, Setting strategic direction. * Initiating new projects. * Developing products. * Implementing organizational changes. * Improving performance. * Allocating resources. * Pursuing continuous improvement.

Who to Involve?

Product Managers, Designers, Engineers, Stakeholders, Executive Leadership, Users and Cross-functional teams

Tools You Might Need

Whiteboarding tool (figjam, miro) or shareable document like Google Slide Note: A roadmap should live somewhere that team members can easily access and update as it constantly evolves .

How to do it (Steps)

Crafting a roadmap involves specific steps that ensure clarity and effectiveness. Here are three pivotal steps:

  1. Define Clear Goals and Objectives:

    • Start by articulating overarching goals aligned with the organization's strategic vision and priorities.
    • Break down these goals into specific, measurable outcomes or key results that represent tangible achievements contributing to the overall vision.

  2. Identify Actionable Initiatives and Milestones:

    • Once outcomes are defined, pinpoint initiatives or projects needed for their achievement.
    • Collaborate with stakeholders and cross-functional teams to determine initiative priorities, using methods like the 2x2 prioritization framework.
    • Break down each initiative into smaller milestones or tasks that signify significant progress towards desired outcomes.
    • Collaborate closely with designers and engineers to estimate project timelines, considering stakeholder approvals and buy-ins.

  3. Create a Clear Roadmap:

    • Utilize visual formats like Gantt charts, timelines, or swimlane diagrams to craft the roadmap.
    • Organize initiatives and milestones logically, considering dependencies, resource constraints, and strategic priorities.
    • Ensure effective communication of the roadmap to stakeholders, fostering understanding of goals, objectives, and the plan for achievement.
    • Regularly review and update the roadmap as necessary to adapt to changing priorities or circumstances, ensuring its continued relevance and effectiveness.

Things to consider when crafting your roadmap:

Direction: What are your desired outcomes for the product?

Work: Which large feature sets do you hope will contribute to each outcome? State your progress towards achieving each one (completed, in progress, planned etc).

Metrics: How have you measured the success of each outcome? How do you plan to measure future outcomes?

Timelines and Milestones: When do we plan to tackle and complete this work? If you’re wary of putting dates on your roadmap try using milestones instead, or even a simple now, next, later framework.

Threats: What are the risks, blockers, and/or asks for each outcome?.

Now that you have the core components of a roadmap we recommend taking the following tips into account to ensure it functions as a valuable communication tool that does not put your team in any unwanted or difficult situations.

  1. Outcomes over outputs: Outcome-oriented roadmaps focus on the direction you wish to take the product without prescribing specific solutions. For example, if your team were building a calendar application you could specify four different ways for a user to create an event but, after building one of those ways, learn that users do not need the other three. If you made all four methods key delivery points on your roadmap, you may have stakeholders who are now using those to measure your progress. Instead if you focus on the outcome of the user being able to create an event, you are not committing to a potentially unnecessary set of features.

  2. Balanced needs: A good roadmap should reflect the needs of users, the business, and the product team. Also consider using your roadmap to advocate for technical outcomes that benefit the engineering team and health of the codebase.

  3. Committed yet adaptable: Your roadmap should be a reliable artifact that gives a strong sense of your product scope and direction. As you learn new things your desired outcomes, feature sets, and constraints can evolve considerably, and your roadmap should update to reflect that. A helpful tool for communicating this is a Clarity Continuum. Set expectations early by adding a visual cue to your roadmap that shows the current outcomes as high clarity and declines towards lower and lower clarity as you get further in the future.

  4. Easily digestible: A great roadmap is one that is discoverable by stakeholders and answers their questions without requiring clarification from the team. As a result, your roadmap should only contain necessary details and should avoid language or acronyms that may not be understood by all audiences.

  5. Up to date: It is very tempting to set and forget a roadmap, but as soon as it becomes stale it no longer serves its intended purpose. Consistently update your roadmap as work is accomplished, threats are mitigated, direction changes, and new opportunities are uncovered. Try updating your roadmap at least weekly if supporting a fully staffed product team and include a Last Updated field to hold yourself accountable for keeping it fresh.

Once you have built a roadmap, we strongly recommend getting feedback from your team, other PMs, and mentors. Whether you are inheriting an existing product or building a new one from the ground up, you want to ensure you have a roadmap that you feel comfortable and empowered to share out externally since stakeholder alignment on a roadmap is key to avoiding unwanted surprises and pivots. It can be a little scary to get to that point, but if you have conducted strong product discovery you will end up with a relatively clear sense of your outcomes, success metrics, and initial epics/feature sets. All a roadmap does is simply synthesize those learnings into a cohesive artifact. In the same way that product discovery is continuously alive throughout the life of your product, so is your roadmap.