5 Tips to Creating a Meaningful Product Roadmap
As any PM knows, the creation of a product roadmap is no small task. The roadmap needs to convey not only your long term product vision, but the short term deliverables that will make or break your team’s credibility before it officially launches. Stakeholders need to see this roadmap and think, “Wow — I can’t wait for this product to be ready, and I have faith that this team will get it done.”
I adopted a product that had been in development for 2 years. One of the first things I did was engage with key stakeholders to understand their needs, visions, and dreams for the product. Lo and behold, they felt they hadn’t been looped into the process, and I found that they had an incomplete understanding of its features. As a result they had some of their most talented people working on creating ad hoc solutions, reinventing key outputs of this product in Excel. Meanwhile, someone had been working with a full developer team for 2 years to create a cloud based solution with the ability to process 40x the data they could.
It all came down to the product roadmap. There was one that had been developed and shown to the end stakeholders, sure, but they had no recollection of what was included. They knew something was being developed, but because the roadmap wasn’t clear, concise, and easy to follow; they were easily lost. They saw it once and promptly forgot about it.
This is why I’m writing this article. I hope that these tips can help you make sure your roadmap is impactful and memorable, and it can empower you and your team to deliver results to your stakeholders. Remember, though, if you’re working on an early stage product, a roadmap isn’t necessarily useful just yet. Wait until you’ve fully scoped out the product-market fit and developed a viable product strategy. See my tips below.
- Identify & Involve the Correct Stakeholders
Your product isn’t being created in a vaccum. Remember (and communicate!) that the roadmap is constantly evolving. Having the right people involved at each stage of development is crucial to building credibility and ensuring end users will use your product. PM’s rarely have direct authority — we have to lead through influence. Influence is created through relationships. Relationships are created through real listening. You need to be the expert on what your customer wants. Listening to end user needs and key business owner needs is just as important as listening to the needs of your product team, as all are constantly evolving. You need to get the right people involved at the right time in the dev process, otherwise you’ll struggle down the road to get buy in. - Tie Every Piece to the Long-Term Strategy
The development process can be long. When you’ve been working on something for two years, it’s easy to get sidetracked and forget what the true minimum viable product needs to accomplish. It’s easy to say, “Well, while we’re doing A, we might as well tack on B since they require similar work.” Remember that as your team notices opportunities for improvement, you can and should entertain them. But you, as the PM, need to evaluate the tradeoffs and quantify the incremental value associated with any addition. The roadmap needs to drive towards the long term plan for the product. The key to keeping your team engaged through this process is making sure they are fully versed on the long term product strategy. If your developers are aware of the big picture of what you’re trying to do, when they encounter a fork in their day-to-day development road, you can trust them to make an efficient decision and guide them towards having a product mindset. That is why every piece of the roadmap needs to tie back to your long term — and you should be able to refocus & realign the team by pulling up your roadmap. - Design to Scale Logically
Your purpose is to deliver a product that furthers your company’s mission and credibility. To do this, you’ll likely need to map out the customer journey to identify milestones that will best implement the strategy. These milestones need to be at the right level of granularity; and you should work with your stakeholders from Tip #1 to make sure you’re covering the correct scope. In my experience with platform products, sometimes having milestones (Epics) as different features on a singular platform works in the short term, but more often than not it is necessary to break out each of those features into milestones as well. It depends on how complex the products you are working on are; the more complex, the more subcategories you will have. Every company (or department or team) has a different definition of what granulatiry constitutes an Epic; no matter how many PM articles there are around best practices, every company will change the guidelines to fit what suits their needs best. There’s no one-size-fits-all answer on assigning milestones — but you do need to make sure that each milestone ties into the product strategy (refer to Tip #2).
This is why designing to scale is so important to the product roadmap creation process; creating your milestones so that you can stay organized and scale logically is crucial to ensuring long term communication success. If you create your milestones around features, and you end up scrapping one of those features entirely or merging two features, you need to make sure that your roadmap can adapt without a full rewrite. This will allow you to concisely and clearly explain how the change continues to tie into the long term product strategy without introducing confusion around retired features or subfeatures. - Create a Clear, Concise Visual
Most teams I’ve been on use an Agile methodology, meaning we drive towards an MVP (Minimum Viable Product) and then deliver incremental value. The biggest challenge I continually face is reconciling the development process, often in the sprint framework, with business deadlines on a calendar. Sometimes stories don’t get finished in the current sprint and have to be pulled into the next one, despite all your analysis around sprint velocity / burndown, length and how much you help prioritize when (not if) bugs come up. Creating a clear visualization to articulate dependencies and identify checkpoints is crucial, because when you explain the status of the product to business stakeholders, they need to be able to visually see what you’re talking about. In my experience, without a clear & understandable visual, it’s easy to lose the trust of your stakeholders. You need to be able to show them, visually along with verbally, the status of your product. If you have intermediate results to demo, even better, but often this is not possible. Consider setting up a touchpoint at a set cadence showing stakeholders the same roadmap with a clear indication of current status and dependencies. Consistency and follow up go a long way in maintaining motivation among the team and keeping stakeholders optimistic, bringing me to Tip #5. - Communicate! Communicate! Communicate!
I’ve said this once and I’ll say it again. Regular checkpoints and communication are key in establishing rapport & product credibility long term. Really taking the time to listen to the constantly evolving needs of your end users while hearing your developers’ ideas on how to improve the here and now are vital to a meaningful product. Communication isn’t just driving your vision to everyone else with a single minded ferocity. It’s making sure your vision is constantly evolving to incorporate what is truly relevant to your product, and communicating it. Refer back to Tip #1 — you need the right stakeholders giving you feedback. That being said, there’s a fine line between being collaborative and being a people pleaser. Remember your focus on the MVP and your quantitative frameworks to prioritize different incremental value adds. You’re managing both up and down — it’s important that all of you are on the same page. To do that (you guessed it) you need to communicate!
These tips have proven incredibly useful in my experience as PM/PO. If you have thoughts or come across another relevant article, please share! I’m always looking to engage with others and talk shop. Cheers! — Meera
