Product Roadmaps - your action items for success

Vision, strategy, and product roadmaps build upon one another — you need all three to create winning plans and achieve your goals.

👋 Hi, I'm Jaryd. Welcome to this weeks Slice— the free weekly newsletter for PMs and founders about product, startups and growth.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice


Over the last few weeks, we’ve spoken a lot about product vision as well as product strategy.

We started with vision — because it’s an essential starting point to creating product strategy. We then moved onto (1) Creating Product Strategy, and (2) Communicating and Executing on Strategy

Vision, strategy, and product roadmaps build upon one another — you need all three to create winning plans and achieve your goals.

If you haven’t read those yet and are interested in the product roadmap— I’d suggest going back to them first (in that order), as they are essential to the process of building a successful roadmap.

Otherwise — let’s jump into it! 👇

What and why

"Roadmaps are evidence of strategy. Not a list of features.” – Steve Johnson

Once you've defined what your big picture product strategy is and you have a guiding framework for how you will grow and achieve your product vision – you're ready to have a roadmap.

Your product roadmap is the actual stuff you will work on and build to achieve your objectives in the short and long term. It's your tactics, and it paves the path for how the product will evolve over time to get you from A to B in a prioritized and thoughtful way. It's like a super-charged and highly strategic chronological to-do-list of what's coming next – and it helps map your development efforts with the broader product and company goals.

While the roadmap itself shows what is being worked on, it's essential that every initiative on the roadmap has a very clear why, and a why that clearly maps to the product strategy,

Here are some key benefits to the product roadmap:

  • It helps with prioritization. There are always going to be ideas and projects to work on, and the roadmap creates the source of truth for what's most impactful and the order of operations to work on them.

  • It creates alignment. It's great for you to know what the priorities are, but the roadmap makes sure others also know what they are –making it the source of truth for alignment during development cycles, and a great tool for building consensus.

  • It gives transparency. The product roadmap is visible and available across the company, helping other people know what's being worked on currently and what's coming up next.

  • It creates accountability. The roadmap is the document that outlines what the planned output and outcomes are for teams, people and the company. With a clear roadmap and timelines, it becomes much easier to see how successful the team was at execution in a given cycle – and if there are problems, dive into those and course correct.

  • It plans for dependencies. The roadmap should be prioritized in a sequenced way, helping hi-light which tracks of work depend on others.  If you need to implement a user profile before you can build your profile search functionality, then the roadmap will call that out.

  • It helps you advocate for, and allocate, resources. The roadmap is used to drive conversions with managers and leadership about what resources are going to be needed to actually build everything – and is a great tool for visualizing hiring gaps.

Just like product strategy, depending on the company you're working for there may be a single product roadmap or multiple roadmaps for different product lines. Also, each project you work on should have its own mini roadmap that outlines your development plan. 

Creating the roadmap 

1. Where roadmap ideas come from

Any product manager will tell you – you'll never be at a shortage of ideas. There will always more to build that you have resources for. 

Not all ideas are equal – and what ends up on the roadmap is a reflection of what's been filtered and triaged through a strategic lens, and been chronologically prioritized. 

As you filter your pool of ideas down to figure out when lands up on your planning cycles roadmap – you'll have to make trade-offs between things like:

  • Brand new product ideas. These are initiatives to build a new product or feature you don't have.

  • Ideas to iterate on existing products. These are initiatives to continue incrementally improving on an existing product of feature.

  •  Quality improvement ideas. These are projects that the customer often doesn't see in the form of new functionality. They could be bugs or improvements to your code – and while less shiny and exciting as building new stuff – are often extremely important.

Your roadmap will most likely be a balance of those types of ideas. The next question is, where do those ideas come from?

  1. Customer research.

  2. Market research.

  3. Keeping an eye on your competitors.

  4. Inspiration from other businesses in different markets.

  5. Spending time looking at your data.

  6. Talking to your customer-facing colleagues (like sales, customer success, marketing).

  7. Talking to department heads and team leads. 

  8. Talking to people on your team (like designers, engineering managers, other PMs, your boss).

  9. Using the product yourself. 

  10. Strategic thinking.

  11. Keeping an eye on new technology trends. 

Share

2. Aligning with vision & strategy

Vision, strategy, and product roadmaps build upon one another — you need all three to create winning plans and achieve your goals.

A roadmap without vision and strategy is just a list of stuff to build without a clear big picture purpose – it lacks the why

When thinking about what ideas should go into the roadmap – always consider how impactful a successful outcome will be towards helping your strategy be successful. And when you're doing roadmap documentation be sure to include that info about each roadmap item for clarity. 

Consider this high-level example of building a new electric car:

  • The vision is your exciting idea about what kind of car it will be and why it matters

  • The strategy is your blueprint that outlines how you will win in the market

  • The roadmap is your plan that builds upon the blueprint with specific details to go from not having anything built to having the vision of your car become tangible

If your vision is to be the fastest car, and your strategy is to cut out all the luxuries and additional weight– does a roadmap idea like “adding extra trunk space” make a lot of sense? 

Viewed in isolation on the roadmap – why not? But when you align it to your product vision and strategy – it doesn't look it like helps you get there. 

3. Collaborating

Collaboration is key to building a successful product roadmap. Where the product is heading, and why, is going to impact everyone in the company.

When you go about creating the roadmap in a way that involves a variety of stakeholders and partners – it provides the necessary context to them early on in the process, helps you funnel in additional insights from other departments/leaders, creates a sense of shared ownership and helps you get essential buy-in, which all together sets you up for the collaboration needed during execution to actually get everything done. 

Your stakeholders will not only understand what's on the roadmap and why – but they will be heard and have their needs and ideas taken into account and have transparency about why they have or haven't been included. This builds your credibility as a PM and is important for your working relationships – you're don't want to be seen as the idea guy – rather you're the guy who facilitates healthy collaboration towards the best shared ideas. 

PMs are the owners of the roadmap – so it's your responsibility to drive that collaboration during the roadmap process. So what does “collaboration” actually look like? 

Here's a 5-Step approach to collaborating on the roadmap: 

  1. Identify who your stakeholder are. The first step is knowing who the right people are to collaborate with – ask yourself who's perspectives and buy-in do you need? Your list may include executives, and department heads from teams like marketing, sales, engineering, etc.

  2. Meet with them separately. Schedule time to meet with those stakeholders individually. In these meetings you should set context by communicating/refreshing what your product strategy, vision, and goals are (this is assuming this is already nailed down). From here you want to hear what products/feature ideas they have towards that. Make sure you understand why, and what the priorities are for them for each idea. 

    As you go into these discussions – keep in mind that although everyone in theory wants the same thing for the company (success), people from different teams will have different priorities and ideas to get there, potentially even conflicting. Sales for example gets measured on how much they sell – an engineer doesn't. Those motivations will come across in what they want on the roadmap.

  3. Present your draft roadmap to key stakeholders. At this point you have gathered inputs and priorities from your stakeholders – the next step is to review them and use them in conjunction with your other inputs to put together a draft roadmap. This can be as simple as a prioritized list. 
    With this in hand, schedule a roadmap kickoff meeting with the key stakeholders. Your goal here should be to get your first round of shared buy-in from the group on the priorities.

  4. Design and refine the roadmap based on the above meeting. You'll definitely get feedback from the above discussion – and based on that you can polish up your roadmap and organize it in a more structured way.

  5. Communicate the final direction with them. Have a follow up meeting where you get final approval from your key stakeholders on the roadmap. Once you've done this – your next step is communicating and sharing your roadmap within the company. 
    This isn't a one-time thing either – a key part of roadmap management is ongoing communication and governance of it.

4. Outcome-based roadmap

A feature-based roadmap is an easy and common pitfall. The more outcome-based/impact-orientated a roadmap is – the more likely it is to help you win in the market.

Essentially, the shift from feature-based to outcome based starts with changing the conversation focus point from what to build to why to build. 

If you find that you're thinking and talking about features you can make – you're thinking in terms of output. Your goal should be to be talking about problems instead – and what measurable impact/change you want to bring about. 

Here's an example for a marketplace:

  • Feature-based: Add ratings and reviews to profiles

  • Outcome-based: Improve marketplace trust between buyers and sellers

When you commit to achieving an outcome – you're fostering a culture where the team will own solving the problem – not finishing a solution that's been defined. 

That might sound similar – and in some cases it can be, and focusing on a solution over the problem will get you to the same place.
In the example above, adding ratings and reviews to an online marketplace will very likely get you closer to that outcome. However, when you rally the team around the outcome, everyone can think more holistically about how to achieve that. This sets the team up to work more autonomously, where people can get creative and have more fun thinking about the how and what – opening the solution(s) up too much wider possibilities. 

Things change and solutions can become irrelevant – whereas problems and meaningful outcomes are more persistent. 

And remember, your roadmap needs to closely align and build up towards your vision and strategy– so the outcomes you're thinking about need to (1) be relevant and make sense as those building blocks to help achieve key business goals, and (2) be measurable so you can know if you've been successful or not. 

If you have an outcome-based roadmap that doesn't translate to desirable goals for the business, and importantly, doesn't translate to what success looks like from the customer perspective – you're setting yourself up for building and successfully achieving the wrong thing.
 

5. Prioritizing

Prioritizing anything, not just a roadmap, means taking a bunch of inputs, figuring out how important each of them are in a structured and communicable way, and then deciding on a sequence to do them in.

As the PM, you're responsible for prioritizing the projects on your outcome-based roadmap – and you should have a framework you use to do that. Without one, you're going to have a harder time justifying why project X is coming before project Y to your manager or stakeholders – which comes off like you're unstructured in your thought process.

My advice – keep it as simple as possible. 

There are a ton of different frameworks out there with ranging complexities. Certain approaches can work really well for one team, but can be detrimental to another. 

Based on personal experience and speaking with other PMs – the best place to start (just like building a product) – is with a simple version. It's easier to build upon a simple framework that it is to bring an overly complex one into the mix that slows your team down and messes with your process.

A good prioritization framework to start should:

  • Make sense and work for you

  • Be easy to communicate to others

  • Be easy for others to understand 

  • Help you make decisions quickly 

  • Be rooted in a few, meaningful, variables

Here's an example of an effective framework that covers all that:

  1. Make a list of all the roadmap ideas 

  2. T-shirt-size (XS, S, M, L, XL) each idea on two dimensions: estimated impact and estimated cost 

  3. Sort the list based on the highest ratio of impact-to-cost 

Impact means how much you guess a successful outcome for an idea will move the needle. You haven't validated much at this point yet unless you've already run an MVP for the idea– so the impact is an estimate you and the team come up with based on research you've done. 

Cost means how much effort engineering (usually) guess something will be. Even if you're a technical person – you want the people who will do the building to drive the level-of-effort (LOE) provided. Engineering effort is an important piece of cost – but there's other variables you need to factor in – like design and research time, vendor fees, as well as go-to-market costs. 

Therefore – an idea with an XL impact and XS cost would be a top priority. 

Within your list of roadmap ideas – you want to have a balance of impact, as well as cost/effort. If all your ideas are XL estimated cost – you'll be taking on a lot of larger and riskier bets. Not all of them will pan out on the impact side the way you think – and often the estimated cost will be higher than guessed. You should approach your roadmap like you would a balanced stock portfolio – hedge your bigger bets with some smaller and less risky ones. 

Find this post valuable, and know someone else who might? 👇

Share


The Product Slice is the free weekly newsletter for PMs and founders about product, startups and growth.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice