Building my first roadmap

Intro

For years I was simply spectacle to numerous roadmaps - both revealed (on paper) and unrevealed (in the head) that Product and Program Managers created. My job was always to contribute opinion and any insights, and sometimes I did influence the roadmap provided my arguments were strong. However, I never had an opportunity to build one myself from scratch. The first chance occurred in my most recent engagement as a Product Owner to build a roadmap for a SaaS product implementation in an enterprise for an important use case, and here are my thoughts

Lessons (in the order of importance)

A. Focusing on tackling assumptions first rather than building features 

This might sound cliche but whenever there is a development team on standby hungry to build and deploy there is a never ending temptation to do the 'real' work i.e. coding. Once we give into this temptation to build a roadmap full of 'features' it automatically influences prioritization by focusing on knowns i.e. items for which requirements are clear, since they can be built quickly. Fortunately, working under guidance of a senior product owner I learned to deliberately focus and collaborate with the development / engineering team mainly to conduct research or to prototype in a sandbox at the most, by ruthlessly focusing on unknowns or big assumptions.

The biggest tasks / questions I would put forward to engineering were those for which the answers were typically 'Yes/No' rather than "show me" or "demo" this, which could be comfortably tackled later (once we had some idea about the least understood items)

1. Does an API exist to send data or query info from a system?
2. Can we customize the workflows so that we are able to do use our own process?
3. Can we query data related to these attributes in order to prioritize attributes?

Due to this intentional behaviour, the focus automatically shifted to ambiguous / unknown or "we have no idea what that is or looks like" kind of items. 

1. What will be the modified process/workflow once we implement the new technology?
   
2. What strategy will we use to get buy-in from stakeholders for this new process?
3. How will we prioritize large pieces of effort so that we can target the 80-20 rule (instead of aiming for 100 on the first day itself)

B. Future Process is typically the least understood item

Often overlooked, a process is typically the most affected piece by new technology. Hence, it makes most sense to articulate or pen-down the new process steps/workflows that technology will introduce/modify followed by the critical task of getting all key stakeholders to agree to this. When I stared initially at the current process which would be vastly simplified by the SaaS implementation I could only think of 5 high-level steps. Upon brainstorming with SMEs I came up with around 100 steps. Only when I focused on a sub-set of the overall process - once again the new technology, did I come down to a manageable 50 steps that required attention. The rest of the 50 didn't need to be delved into at least initially.

C. Sequencing items

This is the beauty of a roadmap. Although, lots of questions or assumptions surfaced we had to focus those that mattered most i.e. logically link one to another so that we knew which one had to go first. For example: To ask information from a Customer on a form we had to know what we were legally allowed (i.e. research legislation) to ask or what was reasonable to ask (i.e. research what others are asking in a similar use case). Coming from a Business Analysis background, the assumptions quickly surfaced two keys things that are the most challenging in any project - 'What' are the User Requirements and 'Who' is giving them or in a best position to provide them?

D. Influence of Strategy on Roadmap

Strategy is inherently behind everything we plan. A good roadmap also utilizes a thoroughly debated and vetted strategy, not one hidden behind in someone's head. Not paying attention is a recipe for a plan that will quickly run into obstacles. A core part of my strategy focused on delivery - Since a 100% delivery in a large enterprise meant a super high cost we had to prioritize i.e. 80-20 for the first release. 

E. Other items

1. Roadmap has swimlanes of themes or aspects
2. The further along the fuzzier/fancier the Roadmap can be and that is perfectly normal. AI driven OS [2] 3 years down the lane..That's perfectly fine.
3. Individual buy-in from key stakeholders especially Architects and Sponsors
4. A balanced mix of known and unknown items for a Increment - Too many unknowns on plate at once will drive one nuts with anxiety.

 

Conclusion

At the end of the day a Roadmap is a plan that may need to be changed even a week after it's done in the light of new information. There is no point in trying to cross all the 't's and dot all the 'i's when building one. In my case, the strategy depended on passage of a regulation to be the driving force for getting the work done by external teams. However, we also chalked a back-up strategy, in case the legislation took much longer than anticipated to pass, to modify the Program Objectives while still meeting the Goal. Finally, as Marty Cagan proposes in his book Inspired - The best roadmaps focus on creating business value and solving the problem over outcomes or a list of features[3]. I am happy that we were able to collaboratively achieve that!

 

References

1. HomePage - Timeline@2x. https://www.productplan.com/uploads/Homepage-Timeline@2x.png
2. A quote from the Telugu Movie Maharshi, 2019
   
3. Marty Cagan, Inspired - How to create Tech Products Customers Love, Wiley, New Jersey, 2018