I doubt I’m the only one thinking wistfully about travel at the moment, looking forward to a time when the world returns to some kind of normality, and we can spend our leisure time how we please. I also guess I’m not the only one planning for the next time we can enjoy carefree holidays abroad. I’m probably also not the only one looking to make my next holiday a truly epic one.
And I do mean epic – my wife and I are going to drive across America, coast to coast, east to west, in a Shelby Mustang. But we won’t be taking the most direct, time-efficient way to cross the continent, because that would defeat the object of the trip. The scenic route is the order of the day (every day; it’s going to take us months).
Planning for what matters: keeping it flexible
We want to visit as many states as possible while we’re in the US; we want to see the incredible colours of autumn (though they’ll call it ‘fall’) in New England, visit the Big Bend National Park in Texas for the unrivalled stargazing opportunities, and head to Wyoming to take in the incredible geology (geysers, waterfalls and petrified forest) of Yellowstone National Park. We plan to go into Louisiana to experience the vibrant culture of New Orleans, and visit Arizona to learn about the indigenous populations that have made the area their home for some 12,000 years – that’s just the start of our list, too!
I could tell you, in more detail, about more of the things we’d like to see and places we’d like to go. But what I can’t tell you is the exact dates we’ll be arriving in each place, or how long we’ll stay there. We’re not building an itinerary, or committing to accommodation bookings along our route. We’ll book the car hire (because it’s important to me that we get that particular vehicle, for nostalgic reasons – it won’t be the first time that I’ve done a US road trip in a Mustang!), and we’ll make sure we have a hotel room secured for the first few days (we’re factoring in a few days’ R&R, because nobody wants to begin the road trip of a lifetime with jet lag). I’ll also do some good research on AirBnBs on the East Coast, so we’ve got some idea of our next steps after the jet lag has worn off, and also pick out some special options in the Bay Area for the last few nights of our trip.
What does all this information about my holiday planning tell you? It gives you a clear idea of what’s important; of what I want to achieve, what the point is. From what I’ve shared above, you can tell that I want to enjoy the trip of a lifetime, in a relaxed way that makes the most of the opportunities that present themselves at the time (and works around any metaphorical bumps in the road – for example, a route diversion because of roadworks, or finding that a restaurant we wanted to visit is closed when we turn up). It also tells you that I want to make the most of those serendipitous moments that offer positive opportunities we couldn’t have planned for.
Trying to pin down a really specific schedule of when we’ll be where and doing what would be counterproductive. We’d just end up stressed and dissatisfied, distracted by negativity over ‘not sticking to the plan’ (because no complex plan ever pans out quite as one might expect, there are usually setbacks and obstacles, as well as unforeseen changes that shouldn’t be missed).
Roadmaps and release plans in product development
Why I am I telling you this story about my lockdown daydreaming and future trip planning? Because my cross-America trip planning is an excellent analogy for the product roadmap, and the reasons why a release plan should be undertaken relating to small chunks of project time, with a flexible mindset.
It’s common for people to confuse the concepts of roadmaps and release plans; the terms often get used interchangeably when they’re very different things. This not only hinders communications (encouraging working in silos) and subsequently the effectiveness of teams, but can also result in missed opportunities for improvements during the process, since with a release plan the focus is often (mistakenly) on ticking off the milestones that have been set out at the start. You lose adaptability.
A roadmap is a strategic view of where a product might go, and over what timeframe. It embraces the good product discipline of taking on board customer feedback and works well with Agile software development. A good roadmap is a plan, not a commitment.
Any good plan (or roadmap) starts with some certainties. So my roadmap for my trip of a lifetime would look something like this:
The trip will last no more than three months.
We’re going to fly to the East Coast of the USA to begin our journey.
Not every car hire place will have a Shelby Mustang, and this is important to me, so I’d better book that early.
It makes sense to book accommodation close to the airport for the first couple of nights, and spend the first week or so in New England, keeping the travel distances lower while we recover from the jet lag.
I like using AirBnB, as you meet some interesting people. I’ll do a bit of early research on great-looking places to stay on the East Coast, so I’ve got some possibilities in my head for the first couple of weeks.
I want to book somewhere really special for our last few days, so before we go I’ll research places to stay near San Francisco, maybe in Monterey – no need to make the booking just yet, though.
I need to think about any concrete dates or restrictions, and know about them in advance, even though the plan itself will be loose. For example, perhaps it’s not possible to drive into all parts of Yellowstone, or maybe I want to be in New Orleans for Mardi Gras.
This roadmap tells you the WHAT of my trip, it’s the strategic plan, my statement of intention. It sketches out my priorities and includes the WHERE and the WHY. It details the high-level proposal (and thinks ahead to any hard constraints), but leaves enough wiggle room for reacting to feedback and new information.
In product terms, I think of my roadmap as a similar sort of list. It’s a document that answers the following questions:
Where do you think this product should ultimately go?
Given what you know about your customers’ needs now, where do you want to take the product in the short, medium and long term?
Do you have any concrete deadlines to hit, that are beyond your control? (for example, there might be a piece of new legislation coming into force)
As a product manager, my main purpose would be to find out about all the opportunities that are out there, decide if they fit with my vision, and then prioritise those that do.
So a roadmap is about priorities and vision, but how do those get turned into an actual product?
Once you have decided where your product is heading, and where to start – based on the information available to you at the time – you need to start thinking about the HOW. How will you translate that vision into reality? That’s where your release plan comes in.
Your release plan is about delivery and execution. But how can you utilise a release plan without falling into the trap of becoming a slave to its milestones?
The impact and potential of the ‘cone of uncertainty’
The key to this approach is to embrace uncertainty. Uncertainty is a powerful concept; you need to navigate it to enter new markets or pivot to a new customer need. In fact, the very edge of certainty is often where opportunities exist.
There is, of course, the inherent uncertainty in any plan if you don’t have all of the information you need to guarantee 100% accuracy – and in the real world that just doesn’t happen; you can’t predict the future accurately. You can however model a ‘cone of uncertainty’, which can plot the likelihood of where a project might end up. Think about the maps you see when meteorologists model hurricanes. They show the likely course of the hurricane’s progress, and this is usually cone-shaped because the model necessarily loses accuracy the further ahead you project the data, resulting in a shape that begins narrow, and gets broader.
At the end of the cone that represents ‘now’ or ‘very soon’, the probability of the model being accurate is high – there are few variables that could have a material effect on the path in the very near-term. At the far end of the cone, it spreads out. Whilst you might have been able to model the major influences, a series of minor influences can build into an effect that little by little has a material impact on an outcome. This is known by various names, including ‘the butterfly effect’, and is often adopted when modelling something that cannot (yet) be modelled with complete accuracy. It is this effect that leads to your weather report telling you that there is a 50% chance of rain today – in other words, the model has reached a point where the intrinsic uncertainty of earlier events has left it unable to decide if it will rain or not.
Big up-front planning: the bad old days
Once upon a time in software development, business analysts believed that they could take an incomplete set of data and use that to build a plan outlining exactly where the project would be on any given day, even if that day was two years away. People looked at the 200+ page project specification and believed it must be true just because of the sheer volume of work that went into creating it.
But the weight or size of a book (or a specification) rarely tells you whether it is any good or whether the information it contains is accurate. It will only turn out to be ‘good’ if there is sufficient data, time and resources to draw highly accurate conclusions. Rather than set out such a detailed specification right at the beginning of a project, it is often better if the author simply accepts that the further in time they move on from their accurate data, the less accurate the conclusions will be.
Having worked on such waterfall (big, up-front design) projects, it is clear to me why many failed to deliver what was projected at the outset. Those responsible tried to ‘manage away’ the uncertainty rather than embrace it. Software development’s response to this inaccurate planning model was to embrace change and customer-led learning, and this brought about the birth of Agile software development movement.
Reaching the best possible outcomes
But how does knowing all this get me to my destination, whether that’s San Francisco or a completed product?
You have enough data and capability to take the first steps in the journey. You can (literally or metaphorically) create a detailed plan for flights to JFK, you can book the car and you can book accommodation for the first few nights. You can manage the costs with 100% accuracy for these stages.
In week two of your trip, you think that you know where you are going to stay, and you can be fairly accurate with your fuel and accommodation costs.
This is your execution plan (in software development language, a release plan). It is detailed and accurate and it defines the HOW of the first part of your journey. You could get people in your team to start looking at flights and accommodation and working to a concrete budget.
There is little point at this stage spending hours trying to plan the same level of detail for three months into your trip. At that time horizon, you are at the wrong end of the ‘cone of uncertainty’ and you only think that you know when you will arrive in California. It is too early to jump into booking where to stay as you’ll probably get the dates wrong and lose your deposit!
A release plan is best employed as a detailed view of part of your roadmap. In terms of the three-month trip of a lifetime it’s your arrangements for the first week or two of travelling, in software development it would perhaps cover the first six months of releases in a 24-month product roadmap. Primary responsibility for the roadmap lies with the product team, while it’s the responsibility of the engineering team to ‘zoom in’ to the roadmap to create a release plan. Everyone should have access to both and agree on the contents.
Embracing uncertainty, maintaining flexibility
So, in summary, the takeaways – other than ascertaining my fondness for American muscle cars, stunning vistas, and the melting pot that is American culture – are as follows:
A product manager should embrace uncertainty and communicate clearly.
A roadmap tells stakeholders (and potentially customers) about the vision for your product and highlights how you think that the product will evolve over the next 12-24 months.
A release plan is a document which is created collaboratively between the product and engineering teams. It homes in on a specific part of the roadmap, and adds detail to a period of time, giving you more scope to effectively project from the data that you have at that time.
The model of ‘only planning as far ahead as you can’ is well understood and used in many fields, but frequently forgotten in product management. Uncertainty is unavoidable. But if you define the differences between a roadmap and a release plan, you can more easily embrace the inherent uncertainty in a complex environment and use it to your advantage.
If you’d like to talk in more detail about the differences between roadmaps and release plans, and how it’s possible to utilise the power of uncertainty to develop better products, send us an email.