Are You Building an Outcome or Feature-Driven Roadmap?

Last week we learned how to choose the highest value strategic initiatives as you plan for 2020. Now you’re ready to create your roadmap. This is when the product leader really sets the bar for what’s communicated and how. At the very least, a leader should provide guidelines and templates for their PMs’ roadmaps.

It’s important to understand that the roadmap is a living, breathing document. It provides a guide to where you want to go strategically. But you should plan for — and encourage! — deviations along the way. That’s part of the validation phase you’ll build in, right?

There are a variety of ways your roadmap can express your strategic intentions. What’s important is to show how you’re driving towards outcomes. And from those strategic intentions, you’ll have initiatives that evolve from a problem into a solution.

With that in mind, I want to share two specific approaches to roadmapping:

1) The outcome-driven roadmap — geared to your internal development team

2) The feature-driven roadmap — more sales and customer focused

The outcome-driven roadmap
Thanks to the data you’ve gathered, you have good indications what users might want. However, you don’t know what your users want, and so you’re not definitive on what the finished product will look like. This makes it nearly impossible to estimate how long the product will take to build.

I really like Melissa’s Perri’s approach to roadmapping, which allows and encourages the uncertainty for product discovery. Her approach is very practical, with the Product Roadmap made up of outcomes, a theme, and hypotheses. Any unvalidated solutions or features are omitted. In her ideal world, roadmaps are theme based and not committed to specific features before features are validated. The roadmap is clear that the team is experimenting toward solutions for a set of high priority problems, but doesn’t define what components will be involved just yet.

After validation, your team can scope out releases of features and update roadmaps now that they are more sure of what to build. You don’t want to over promise early on. Roadmaps done this way are about iteration and learning — they start off vague and directional and get more concrete over time.

This type of planning is great for internal teams made up of designers and developers. That way they know when their efforts will be focused on discovery vs. delivery and how much time is being allocated to each period for a particular problem.

The feature-driven roadmap
Once you’ve established internal alignment on the outcomes you wish to achieve, you can create a more traditional feature-driven roadmap for Sales and Customers.

With this more externally facing document, be sure to only list an item when you believe it will be delivered (and probably leave some buffer). Also, try to add a note about how items further out are still being explored and may shift if more streamlined solutions can be created. Ideally, your team will list Epic/Initiative level items that have been validated with data about customer/market needs. Then, while working towards completing that epic, the product managers will directly check with users/customers to refine the features and ensure the right things are being built.

Whatever roadmap type/s you use, remember that your roadmap is a communication tool. It’s ok to have several versions, depending on your audience. The outcome-driven roadmap works well for the internal development team because it clarifies the strategy and focus of the product team. But Sales and customers will need a very different level of detail from engineering, which is why the feature-driven roadmap may be the right solution. We’ll show you a few options of how to present your roadmap in next week’s edition.

Find the Meaningful Pebbles
While you’re working through validating your initiatives, you’ll want to think about balancing the big and small items in your backlog. You need both to communicate to customers that you are innovative and to keep the team feeling great about delivering value. What things can you do to keep momentum and gain some quick wins? The answer lies in your backlog. It likely has different sizes of User Stories — boulders, rocks, and pebbles. First, look for the pebbles, the finely grained stories that are ready for the very next sprint. Tackling customer pain points which align with your overall goals, even if small, can create a lot of payoff for little effort.

Not seeing many pebbles in your backlog? Overloaded with Boulders? Reviewing CS tickets can provide insight into potential quick wins. Another area ripe for small things to do is tech debt. Partner with your engineering counterpart to identify the “pebble-y” quick wins. And don’t be scared off by the boulders. You may find something that has no dependencies and could be a clear value add, even if it takes more than 1 sprint.

Collaborating for the Win
And speaking of partnering, you’ll want to stay aligned with UX and engineering at every step of the roadmap process. Buffer in time for cross-team discovery and design iterations, even for solutions you have more clarity on. That goes for QA later in the process, as well.

Product, UX and engineering can get siloed and sometimes don’t have a shared understanding of the customer or the jobs to be done. C ollaborating effectively can be challenging. All too often product will be heads down in the hypotheses and validation work, and then throw the resulting solution over the wall for UX to design. Needless to say, it’s not a recipe for successful collaboration.

The same goes with the engineering team. Bring them along on the roadmap journey as well. Walk them through your draft roadmap and solicit input. They may surface up areas for additional exploration, based on their feedback. Even better, engineering may be able to suggest simpler ways of accomplishing your goals.

Once your roadmaps are created, it’s key to keep the documents updated. You want stakeholders to know that this is the source of truth. The progress you share will bring everyone along as you work towards discovery and delivery.

We’ll get into communicating out the roadmap in next week’s installment. How do you share it out? What additional information should you include? What format or tool should you use? Tune in next week for everything you need to know about communicating your roadmap. If you missed some of the earlier pieces, click on the links below to catch up.

Week 1: Planning Starts with Setting a Vision
Week 2: Smart Product Bets Start With Data
Week 3: Generating the Best Ideas
Week 4: Choosing a Path Forward