3 Ways to Create 10X Better Product Roadmaps

 

PAWEŁ HURYN

A product roadmap is a strategic tool to align everyone in the organization. But a poor one might result in confusion, broken promises, and even conflicts.

3 ways to create 10x better product roadmaps:

1. Focus on goals, not features

According to Marty Cagan,

“(…) most of your ideas are simply not going to work” - Inspired

Instead of telling your teams what to do (features), set goals and let them discover how best to achieve them. This will also enable agility, build a sense of ownership, and increase intrinsic motivation.

My favorite technique for setting goals is using OKRs.

You can place them on the roadmap, for example, the “Now-Next-Later.”

Outcome-based goals should:

• Create focus on what's important (strategy)

• Be inspirational (the right cortex of the brain)

• Explain the "WHY"

• Do not focus on a tactical level (features)

Ask yourself:

• Why are we doing this?

• How will it create value for the customers?

• How will it create value for the business?

• How is it aligned with our vision and strategy?

• How is it aligned with organizational goals?

2. Do not commit too soon

There are cases when your business needs a specific date. The most important rule is not to make those commitments too soon.

Ask for additional time to address 5 risks:

• Value. Will it create value for the customers?

• Usability. Will users figure out how to use it?

• Viability. Can our business support it?

• Feasibility. Can it be done (technology)?

• Ethics. Should we do it?

Product Discovery results in a validated product backlog. This means 5 risks are significantly reduced (although not eliminated). And now you can make so-called “high-integrity commitments.” For more information, see Marty Cagan's article.

At the same time, there are two other risks Product Discovery can’t mitigate:

• Estimates. How long will it take to implement?

• People. How well will they work together? Will the team survive?

Even if your “commitments” have a high probability of success, they are estimates, not promises.

Communicate it openly and clearly.

3. Shorten the planning horizon

The risks accumulate over time. According to The Cone of Uncertainty, the longer the planning horizon, the more uncertain the future becomes.

I have personally never seen a detailed plan longer than 3 months that has stood the test of time. The best strategy is to focus on the nearest future and significantly reduce the details presented for the following months.

Keep it simple.

More information:

1. The team gets business problems to solve (Product Outcomes derived from Business Outcomes), e.g., as team OKRs.

2. Through Product Discovery, the team identifies and prioritizes Customer Needs (Opportunities) that, when addressed, will drive the expected Product Outcomes.

3. The level of detail decreases over time.

4. High-integrity commitments might be done only for ideas tested in a Product Discovery (typically Now or Later).

5. By default, don’t present features. But if you really need some, present them as hypotheses. Remember that as PM, you need to ensure ideas will work for the business. So you don't want to hide them. It's only about (not) presenting them on the roadmap.

6. For more information about Product Outcomes, see Empower Product Teams with Product Outcomes, Not Business Outcomes by Teresa Torres

3 Ways to Create 10X Better Product Roadmaps

Product Development Roadmap Template

 

About the Product Development Roadmap Template

Product development roadmaps cover everything your team needs to achieve when delivering a product from concept to market launch. On the other hand, a product roadmap offers context and helps define short-term and long-term goals worth reaching.

Your product development roadmap is also a team alignment tool that offers guidance and leadership to help your team focus on balancing product innovation and meeting your customer’s needs. The product development roadmap is agile, so reiterate details quickly and often. 

Investing time in creating a roadmap focused on your product development phases helps your team communicate a vision to business leaders, designers, developers, project managers, marketers, and anyone else who influences meeting team goals. 

Keep reading to learn more about product development roadmaps.

What is a product development roadmap?

A product development roadmap combines your product vision with your product strategy to build a detailed plan for how your team will get your product to market. 

Ideally, your roadmap would answer a few key questions, such as your product goals and how you plan to achieve them, who will build the product, what your key milestones are, your current status, and how to get to the market launch phase. 

When to use a product development roadmap

Product development roadmaps help your cross-functional teamwork towards a common goal, speed up your product’s time to market, and save time or money. 

A product development roadmap is useful to help teams:

• Decide on and work toward a focussed product strategy 

• Keep everyone motivated in the lead-up to a product launch 

• Help product owners plan and prioritize tasks 

• Understand a product’s strategic direction

• Offer transparency to all stakeholders affected by decisions made

Product development roadmaps also help you decide on your success metrics and compare them to your business objectives. Ideally, you want to find opportunities to make incremental product improvements. 

Create your product development roadmap

Making your own product development roadmap is easy. Miro’s whiteboard tool is the perfect canvas to create and share them. Get started by selecting the Product Development Roadmap Template, then take the following steps to make one of your own.

1. Set some clear goals for your product development. Your roadmap is less of a to-do list and more of a success strategy. Work backward from market launch to set goals and initiatives with your teammates. Make sure you have a compelling high-level vision and can communicate it both with internal teams and external stakeholders.

2. Agree on who has ownership of tasks with your team. Every item on your roadmap should have a clearly defined owner. That person then agrees to take responsibility for reaching the milestone in an agreed timeframe. 

3. Monitor and update your roadmap as circumstances change. Milestones may change from quarter to quarter. Make sure cross-functional team dependencies (between UX, product, and development, for example) are kept up to date with changes. Share your Board with new colleagues as needed, so they can help implement changes too. You can toggle the ‘Anyone at your Team’ option to make the board appear on their dashboard. You can also choose the access rights of your team members.

4. Reprioritize goals as needed based on new information. The most successful roadmaps are the most up-to-date. Resources may shift, and priorities will change. Keep your product on track by thinking of this roadmap as a living blueprint rather than a static record.

Tip for Jira users: you can import Jira cards directly onto your Product Development Roadmap Template to visually organize and keep track of issues.

https://miro.com/

What Does an Agile Product Roadmap Look Like?

 One of the biggest challenges in product management is planning the work in a linear, visual way. Sure, we’ve had “roadmaps” for a long time but they betray the true nature of software development. Digital product development is not linear. It is iterative. We build some things. We ship them. We see how they impact customer behaviour. We iterate them and ship again.

The traditional linear roadmap model, one where there is a starting point and clear, feature-specific endpoint (almost always with a fixed date) is outdated. It reflects an output-focused mode of operating a digital business. Instead, today, successful product-led organisations focus on outcomes. Outcomes, as I’ve mentioned here time and again, are the changes in customer behaviour that affect our business success. They are the true measure of the efficacy of our work and how well we’re meeting the needs of our customers and users.

However, managing to outcomes is much more difficult as it dispenses with the pretence that we can predict the future, know exactly how our software will look and function and what our customers will do with it when they finally get to use it. How then do we build product roadmaps in a world of continuous improvement, learning and agility?

Here is what an agile product roadmap should look like:

An outcome-based product roadmap for agile teams

You’ll notice a few key components in this diagram:

1. Strategic themes — these are the organisational product strategies set by executive leaders pointing the teams in a specific direction. These can be things like, “Expand our market share in Europe” or “Leverage the under-utilised time our fleet isn’t ferrying passengers to deliver other goods and food.” There can be multiple themes running in parallel for a larger organisation.
2. Quarterly OKR goals — we’ve spoken here about Objectives and Key Results in the past but it’s worth reiterating that OKR, when done well, use customer behaviour as the metrics in the “key results” part of the equation. These quarterly outcome goals are where each team is going to focus in an effort to help achieve the strategic theme. This is the goal teams strive to achieve. It is their definition of success and their definition of done. They should work together with leadership to ensure these are aligned and properly levelled.
3. Feature/product hypotheses — These are the team’s best guesses as to how they will achieve this quarter’s OKR goals. Looking out one quarter in advance a team can make strong, educated guesses about what product or feature ideas they think will achieve their quarterly goals. Looking out two quarters ahead, those guesses become less confident so the team makes less of them. Three and four quarters out, the teams really have no idea what they’ll be working on so these guesses become fewer and fewer. This is exactly the way it should be. Teams will learn in the next quarter or two how well their ideas worked, what moves the needles forward and what their next guesses should be. The boxes for Q3 and Q4 will fill up as learning from Q1 and Q2 gets synthesised and acted on.

Frequency of review:
Each team should present this type of outcome-based roadmap for review at the beginning of an annual cycle. It should align with the strategic goals leadership has set and ensure their OKR’s use metrics that ladder up to these goals (Want to learn how to do this? Start here.)

While it’s incumbent on the team to continually expose what they are doing, learning and deciding, official check-ins can happen on a quarterly basis. Teams meet with leaders to determine how well they’ve tracked towards their OKR’s, what they’ve learned during the last quarter and what they plan on doing in the next quarter. This is a perfect opportunity to reaffirm the validity of the team’s OKR’s going forward and to make any adjustments based on new learnings, market conditions or any other factor that may have affected the direction of the company.

Measuring progress:
Progress on this type of roadmap is not measured in how many features have been delivered or whether they’ve been delivered on time. Instead, progress is measured on how well we’ve changed customer behaviour for the better. If our ideas didn’t drive customer success, we kill those ideas and move on to new ones. The learning drives ideas for future quarterly backlogs.

These are living documents. We don’t fix these at the beginning of an annual cycle and leave them as if they were etched in stone. There is too much uncertainty and complexity in delivering digital products and services. Product-led organizations — those focused on customer success with empowered teams — ensure that they’re always pointed in the right direction. Outcome-based roadmaps ensure that leaders and teams are being transparent with each other, realistic about their goals and targets and most importantly about how they measure success.

https://cutt.ly/s5tWbMK

Building Partnerships Map

 I want to develop a clear plan

for working with other groups that have the same vision as me

INSPIRED BY : Tennyson R. (2003) 12 Phases in the Partnering Process, p4. In: The Partnering Toolbook.

LEVEL OF INVOLVEMENT

FAIRLY SIMPLE, SELF ADMINISTERED TOOL, needs relatively less time.

What is it & why should I do it?

Many complex problems have several different yet related causes and effects – with several organisations from different sectors trying to solve things individually. With many organisations having limited resources, forming partnerships is a good approach to not only increase capability, but also your reach. Partnerships help build a common understanding, and harness the knowledge which might be spread across various different perspectives.

Building partnerships takes a lot of effort from all those involved. They often take a considerable investment of time to build the high quality working relationships that underpin effective collaboration. The Building Partnerships Map breaks the process into steps, so you can anticipate difficulties and challenges ahead.

How do I use it?

The Building Partnerships Map describes a series of phases which a partnership might involve. The map indicates what is needed in each phase to make such partnerships work, offering guidelines rather than rules. Each phase, as outlined on the worksheet, is important and should not be neglected if the partnership is to remain balanced and on course to achieve its goals.

 

To work well, partnerships need to be mutually beneficial to the partners involved. You can use the Building Partnerships Map to analyse at what phase of partnership you and your partner are, so that you can move through the next phases to build a strong partnership together.

 

• Identify the stage that shows where you are at.
• Identify the stage where you would like to be.
• Use the template as a map to build a pathway towards that stage.
• The mapped pathway gives an outline of the activities that need to be done in between.

https://bit.ly/3I7XEKh