3 Steps to Creating an Outcome Driven Roadmap
Travel the road less traveled by but be wary of its hair-pin turns
Much of the advise for product managers about creating and managing roadmaps starts with the premise that your organization has used them in the past. Some of the hardest work, however, is working toward an outcome driven roadmap in a larger organization or enterprise that already has a portfolio of products but has never gone through a roadmapping process.
If you’re a business analyst looking to see beyond a never ending stream of requirements, a product manager hoping to work toward clearer goals and priorities, or a leader looking for greater impact and ROI, this post is for you.
I’ll preface that this work is a slow burn and it’s not sexy. It will test you, and you may come to realize that while you love product management, maybe you don’t love the place you’re at. But there’s a huge “on the other hand.”
But if you love solving organizational, behavioral, and potentially game-changing problems then yeah, it’s pretty amazing.
Some of the most difficult but rewarding work of my career has been our office’s four-year journey from a stack of legacy products to a platform with a budding set of new applications guided by an increasingly outcome driven portfolio. There is nothing secret in the sauce. It is hard, sometimes crushing and demoralizing work. But if you love solving organizational, behavioral, and potentially game-changing problems then yeah, it’s pretty amazing.
Let’s get into it.
Step 1: Take stock of yourself and your surroundings
Know Thyself: Cliche for a Reason
The most important factor for a successful change to a road-mapping strategy is not you — it was how well you know yourself in the context of where you are.
Yes, your leadership team matters. Yes, the existing state of your portfolio and your organization’s priorities matter. But at the end of the day, you matter most. You can be a solid product manager without necessarily being successful in this specific work. So I encourage you to start with a self-assessment of your strengths in these areas:
- Influencing. Can you lead through indirect power and authority? Do people follow your lead in how you work and want to be a part of what you’re working on? Do you have concrete strategies and tactics to influence both peers and leaders?
- Storytelling. Do you communicate through stories or rely more on briefs, memos, and decks? Can you shape a future-state vision through the clarity of a story that others can see and feel? Do you have concrete techniques for developing, testing, and sharing impactful, sticky stories?
- Vision. Do people describe you as having an inspiring vision? Do you have experience and evidence of executing and leading others in pursuit of that vision? Do you have methods to effectively communicate your vision to different stakeholders in different forms?
See the field
After assessing your strengths, deepen your understanding of your surroundings. Here are a few guiding questions that can help you gauge whether the time (and situation) is right?
- Do leaders feel enough ‘pain’ with the current state of the portfolio (and how do you know)? What are their motivations for undergoing change and at what cost? What are the risks to them in making changes?
- Do other product managers, business analysts, developers, and designers share your pain or frustration with the status quo?
- Do you have a partner or ally in leadership who can help you advocate for change and coach you through organizational politics?
Change management at this level requires deeply understanding people where they’re at. Don’t start with a proposal of what you want to do. Start with a conversation about what is and isn’t working for leaders who are likely to be most affected by the change.
Don’t start with a proposal of what you want to do. Start with a conversation about what is and isn’t working for leaders who are likely to be most affected by the change.
There are a number of techniques and tools for stakeholder mapping, and I would encourage you to use them as you begin these conversations.
Step 2: Build allies across functions
While product roadmaps are typically considered the domain of Product Managers, moving toward using them for the first time requires substantial shifts from designers, devs, DevOps, and many more.
From my experience having done this in two different organizations in different contexts (one as part of IT, one on the outskirts of it), there’s no path toward a problem- or outcome-based roadmap without buy-in from every branch of the team who will be working on the apps. Here are a few tips to get you started
Start with a cross-functional team
Identify a small group of colleagues to comb through user research, business priorities, tech debt, and more to develop a first roadmap. Here are some tactics that help all team members feel a part of the process:
- Facilitate activities where everyone digs into the research. In some organizations it’s more common for UX researchers to present their findings and insights to the group. In others, they might facilitate or lead Design Studios to go from problem statements they’ve identified to solution ideas. If this is the first time you’re building out your roadmap, consider synthesizing research together as a group. Tools like Miro or in-person affinity mapping sessions can make quick work of this process so long as you have your UX research somewhat structured and well-documented.
- Create clear expectations around a timeline and capacity needs. It’s not fair to anyone if you say this work will just take a few hours because you think it will increase the chances people will participate. Be clear about how much of participants’ time you’ll need and when you’ll need it. This is a good place to leverage your partner and sponsor in leadership to secure this. The committed time sends a signal to participants and their managers that this is important work that needs dedicated time. On the flip side, be sure to update the participants’ team leaders and managers about your progress, learnings, and findings.
Step 3: Start with one goal
A common mistake teams make when first creating roadmaps is to over-reach. The best thing you can do to show that working with an outcome-driven roadmap is to show its worth: start small, with one particular outcome you’re trying to change, and constantly share out what you’re learning.
