In my last post within this series, I looked at roadmaps and how to build them in an agile environment. In this post I will share with you more the type of roadmaps I like to build. Following on from my last post, I received lots of questions around “dates” and maintenance of the roadmap, and while there are many ways to “skin a cat” as they say, I thought it would be best to write about the much-needed evolution of the roadmap.

Evolved roadmaps fit for the agile world

A product roadmap is a highly communitive and rather powerful tool. Because of this, it can also be the source of friction between the “business” and technology. Often if you see a date in a roadmap, expectations are that everything will be done by that date. This is because traditionally, everyone thought you could predict how long things would take to build, the method to follow was one of strict feasibility study, strict planning, understanding the problem and then knowing how long it would be to execute the solution. Throw in some testing time, release windows and add some tolerances and there was your rather “waterfall” highly structured project plan and roadmap.

The reality is, that structured project plans etc work exceptionally well when you do NOT have any unknowns. In technology, we have unknowns. We do NOT know how long something will take to build often, and if something is more innovative, depends on some newer technology, then the number of unknowns goes up. This all means and indicates that prediction of the future is going to get less and less accurate, rendering your nice Gannt chart / roadmap pretty useless. This is why we have seen the rise of “agile” in technology for many many years now, and its all about a simple principle which I have mentioned various times in this series, value “Delivery over Predictability”.

We should therefore think of our product roadmaps as more of a strategic roadmap. By thinking in this way we start to remove the specific dates and focus on what matters, delivery, so we are more focussed on outcomes.

Think of value

If you are able to remove your thinking away from a specific output, on a specific date, then you are starting think more along the lines of delivering strategic value, prioritisation and pathway forward. This isn’t too dissimilar from an old-fashioned roadmap, however the focus is on delivery and strategic outcomes, stepping stones to ultimately where you want to get to.

Since our focus is now on value creation, and we are following an agile engineering culture, we don’t need our roadmap to be highly detailed. Great levels of detail detract from the power of a roadmap at being a communication tool, if its too complex it loses its impact and macro view of your strategic objectives. With this in mind, keep it high-level, keep it to a single page.

Now, I know there will be many readers shouting “I need a date!!!”. I have had this discussion with “delivery” departments, exec and pretty much every type of stakeholder you can imagine, you don’t need a fixed date with a fixed set of deliverables. We think we do because it gives us some form of comfort that we can plan accurately. The reality is that its an illusion, you are not planning accurately. So, you can continue to live in an illusion, or you can accept it and ask, “what can we do then?”

Milestones

I don’t have issues with supplying some form of dates, however, I have issues with pegging dates directly to specific deliverables. For me, dates should be about “goals” and “milestones”. When we think in this fashion, we de-couple specific deliverables from the time. For example:

• Goal is to deliver automation. We can set a time frame, which should be broad, say Q3
• Milestone – automation for processes x,y,z all completed

Now the date is associated with the goal. And yes, the goal could hold detail like automation for processes x,z and z, but it’s not a hard delivery. The milestone has no fixed date, rather it is could be seen as a retrospective thing. We can therefore hit our goal, but not the milestone, since as part of our goal we only automated processes x and y.

Alternatively, you can have a goal and a milestone that are very similar as in, “we hope v1 of our product goes live on a specific date”. This is both our goal, and it will be a milestone. The key here is, not to over define v1, rather v1 is whatever has been delivered into production on that date.

MVP (Minimum Viable Product)

MVP is a fabulous concept. The concept being what is the minimum we need to be able to launch. You then iterate post launch to continue to deliver more and more functionality into your product. I say this is a fab concept, but I am not a fan, I am not a fan because it’s open to abuse. I have yet to see any form of exec or even “product” focussed management stick to a true MVP. What happens in reality is that MVP becomes bloated with things that we “think” the customer wants, or we “believe” we internally need in place. The truth is, unless the customer has specifically told you, then you don’t know. Secondly, there are so many internal ways of ensuring you can support your product live, they may not be ideal, but until you are launched do you really understand all of your needs, or the priority of those needs? So ask yourself, are you really pushing the MVP or are you adding what “you think” should be in there. The MVP concept is often not challenged enough.

Larry Ellison (founder of Oracle) reportedly asked his teams, when launching Oracle:

“When will we be ready to ship to our customers?”,

to which he got the reply “we need to add in x, y and z because our customers expect this”

“Does it compile” Larry replied.

“Yes”.

“Ship it!”

Now this is a true MVP. Larry new that by shipping there and then he had achieved a goal and a milestone, the goal to get product into the marketplace and the milestone of receiving revenues. Was the product ideal? No. Did it work how he wanted it or his engineers? No. Did it work how his customers wanted? Only his customers knew that, and now that they had received the product, they could tell him first hand based on real use.

Components of the evolved modern roadmap

Your modern roadmap is, as I have said earlier, about strategic objectives and focus. Let us look at the components that help you provide this. The best way to show this, is by showing a roadmap, noting that I am trying to keep this very generic, which is a trick in itself:

Vision

Your roadmap needs to ensure alignment, so include in it your vision statement.

Business objectives / intent

You may have different intents you want to focus on, relay these intents back to your technical roadmap for delivery, make sure they remain aligned and coupled. This should be easier to achieve if you have an effective product steering committee.

Strategic focus / timeframes

Keep this broad, do NOT have dates on there, rather try to show that things “closer” in terms of date are more solid in terms of as a deliverable, when compared to those later in the roadmap. The roadmap must remain agile and fluid, however, there is a point where things need to be locked. They have to get locked in order for engineers to pick up and actually work on what needs to be delivered.

Ice, Water, Steam and Air

This analogy allows me to show that things can become more fluid the further they are out, in terms of priority / as a deliverable. Now I have seen other roadmaps use terms like, “now, next, then, later”. When you are in water, steam or air, you may move work loads in to other columns, add to them, juggle as much as you want to. But once it moves into “ice”, you are locked and loaded.

Items

The items in the individual “blocks” that make up the roadmap, held within their relevant prioritisation column, will be high level and business focussed. For example:

“Deliver feature x, to allow us to broaden our customer base”

“Deliver feature y, as customers demanding this additional feature”

Now, you can decide to tag these with the relevant “epic” or “work items” that your engineers are keeping in say Azure DevOps, but this can actually become quite an overhead, so I wouldn’t say it’s something you must do, rather it could be of use if you can get everything tied together nicely.

Conclusion

A good roadmap needs to ensure strategic alignment primarily, this means it is “outcome” based and not based on specific deliverables or output of your teams. Never get hung up on specific dates, focus on goals and milestones. In doing so, you are valuing delivery over predictability.

Your roadmap, even without dates, gives you what you need. If you need to coordinate business operations, legal, customer communications, even head back to your investors to raise more funds, you know when to focus on what aspects and you get quite accurate goal dates. This is because you have that alignment, and you know what is being focussed on because work is now sitting in that “ice” area of your roadmap.

Now, you may not have specific timelines, but you get to understand delivery dates more and more as you witness work flowing into production. When you look at large technology companies, they now announce products once the product is already in production, or vast amounts of it are in production. More often than not, the product is already being used by pioneering customers.

Now you know how to build a modern evolved roadmap, try implementing them and start to measure the benefits you will experience.