Roadmaps and stakeholder communication
Note: This is part IV of a 5 part series, I highly recommend reading previous parts if you havent. You can read the first one here.
I feel I’m cheating with this challenge because both Roadmap and Stakeholders can have their own separate chapters.
But the combination of creating a useful, updated, strategically oriented roadmap goes hand in hand with how you handle “planning information” with your stakeholders, which may arguably be one of the key communication areas for both you and them.
Unlike the previous challenges where knowing what to do was hard, in this case, you probably know what you are supposed to achieve, but it ends up being quite hard to get there anyway.
On creating good Roadmaps
There are hundreds of articles (and even some books!) about good product roadmapping.
I would actually focus on key challenges that are important for communication:
- Don’t be solution specific (which is exactly what your stakeholders are waiting for)
It is much better to have a roadmap that contains what problems you’re trying to solve rather than specific solutions or features. Since you still have to do research and discovery, focusing on the problem gives you room for maneuver and prevents you to create false expectations.
- Don’t be time specific (which is exactly what your stakeholders are waiting for)
Working with timelines like “now, next, future” is better than 3, 6, 12 months. If you make estimations you will probably fail (it is impossible to know based on a one-liner description how much will cost to resolve a problem that you will start evaluating 6 months from now). So again, avoid creating false expectations.
- Flight level
Another interesting challenge for bigger organizations is the level of detail within the product portfolio (or flight level). Ideally, you would want to see a 10.000 km altitude portfolio themes vision to share with the C-level, maybe lower a little bit to 5.000 km and see a portfolio with epics to discuss with business line directors, and then go down to a team level view of epics for a more specific team-to-team communication.
This is easier said than done, and without the proper tools, it can get quite hard to create and keep up to date. And as soon as a roadmap is outdated it is useless (or even harmful).
Why would that be hard?
There are many more challenges to be considered (like having a strategic alignment that I would discuss in the next part!), but these 3 points are probably the ones preventing a good roadmap conversation with your stakeholders.
If what we have to do is known, why is it so hard to do it? Regarding solution and time specific, the main challenge is “holding your ground”. Stakeholders want to know those specifics! When they see an item in the roadmap saying “improve onboarding experience” they would probably ask what exactly in the onboarding experience you will change. When they see “Future” as the timeline in the roadmap they will want to know exactly when in the future this is going to happen.
Hold your ground! Without being rude you can explain that there still is a lot of uncertainty yet so the team can’t commit to specific solutions or timelines. I would encourage you to share the details you already have (for example “after a deep data analysis our hypothesis is that the 5th onboarding step is where more users churn, so will try to experiment with reducing the fields on that form, but we yet need to validate it”).
Again, this is easier said than done. When the CEO is asking for details, it may be hard to say no. After all, you are dealing with cultural change and you have on your shoulders the insurmountable task of convincing people that these roadmaps are more helpful than the specific ones they are used to and loved for so many years.
Other Stakeholder “planning” communication issues
Besides the non-specific and non-time-constrained items discussed before, communicating “our plans” to stakeholders in an efficient and helpful way have some additional challenges to consider:
- Communicating changes
It may sound obvious, but it is amazing how many times teams will present an initial version of the roadmap and then present changes on a semestral or quarterly basis. Depending on how granular your roadmap is, things usually change more often than that. If you keep stakeholders frequently updated you avoid delivering unpleasant surprises. But it requires a lot of effort.
- Communicating context
To make the communication effective you need to provide as much context as possible so others understand why you are making these decisions. The problem is that this content usually is hard to summarize (is all the information you work gathering 40hs a week!) and is widely varied. You may have:
a. Data analysis from current user behaviour
b. New research information
c. Dependencies brought to you from other teams
d. Technical reasons that make you change priorities
e. Marketing events or special dates that impose particular deadlines
… among many other things. It is quite hard to consolidate this information for each item in your roadmap in a 30′ “update” meeting.
- Gracefully receiving modification requests
When presenting your roadmap it is highly likely that some stakeholders would not agree with how you planned things (no matter how much context you provided). It is hard to receive this feedback because you probably spent a lot of time and effort to make the best possible choice. Regardless of your feelings, you need to acknowledge that:
a. This stakeholder might have some information you don’t
b. She might have some decision-making power to be considered if you don’t want to fail later at execution stages
So the action to take is probably simple: take the feedback for later analysis and modify whatever you need to based on it. Once more, easier said than done!