The Product Roadmap
It goes without a doubt that majority of your team has no idea what you were thinking at this moment of time. They probably don’t know what you have been thinking for the past week and still won’t have a clue as to what you are going to be focused on tomorrow or a week from now. Why? Because you have it all locked up in the smart ol’noggin of yours of course. Needless to say, if I was a member on your team, I would be looking at you with some sense of tension and a splash of anxiety since I have no clue what to anticipate next if you aren’t communicating the plan.
That is the topic of discussion today. The plan — more specifically the Product Roadmap, something I have realized to be one of the coolest weapons in the Product managers arsenal. Unlike my other posts, this discussion truly is a more explorative feat of how and why the product roadmap effects your daily work. In a nutshell, I have grown to respect and see the value of clarity in direction the roadmap can provide to yourself and others in your organization.
Let’s begin;
Firstly, as you are already aware the responsibility of being the visionary when it comes to the product is solely managed by the product manager. It is your job to take this idea/concept/thing of value from point A to point B and realize its goals. You already know that. But do you know how exactly you anticipate the work of the marketing team to unfold three weeks from now? If the answer is ‘no’, which is totally acceptable [to a degree ;)] then the following will be useful.
Given that at this point you already have business requirements gathered to ensure that you are in fact building a product that satisfies the end user goals, it means that the level of input from a variety of teams are going to be complex. In the software development world this would be referred to as the requirement matrix or backlog that captures inputs that are important for the team to deliver.
What you may notice is that the requirements can be categorized into themes or chunks of similar work loads. Let’s see an example in action;
Product: Car
Requirements to build Car:
- Chassis
o Metal framework
o Plastic Framework
o Interior Framework
- Engine
o Fuel intake
o Cooling
o Combustion chamber
- Wheels
o Brakes
o Suspension
o Tire/Rim design
With 3 categories outlined for the making of our over-simplified car we still need to understand as to what order or priority each element of the requirements should take. It’s not like we have infinite resources and all the time in the world to pump these cars out, so naturally we prioritize.
Some simple logic will tell you that it’s going to be difficult to build an engine and wheels if there is nothing to attach it too, so our most prioritized build will be the Chassis. Again, a reminder that I am overly simplifying the process because I want to focus on the actual creation of the roadmap vs the pre-planning involved with the entire business unit. Essentially at this point we can agree that the following order is how we plan to build our car
Chassis ~ Engine ~ Wheels
Simple. Now let’s actually place dates in order to hold ourselves accountable, but also the bigger reason to estimate the reasonable time it would take for each requirement to be completed.
Brilliant — our plan is taking shape into something beautiful.
The next part is where I believe many people over complicate and thus make the entire roadmap a burden to reference to — Which is the visual display of the content.
Being totally frank, the key here is not to make it complicated when you are explaining the vision/end goal. No big charts or matrices — just SIMLPE engaging graphics to use that highlight the important parts your team needs to know in 30 seconds. What does this look like?
Some key elements here are the breakdown of the large phases into micro parts that are expressed into the roadmap schedule. Nothing makes it easier to understand when you are able to highlight the change in dates or requirements with the use of complimentary colours that naturally catch your attention. The idea is that, as the schedule is being presented and circulated within your organization — succinctness and clarity is extremely valuable in getting teams aligned instantly. Saving time for your colleagues by making your plan visually digestible to understand not only makes you a good product manager, but also showcases your competence in the subject to distill the complex process into a manner of few info bytes.
Additionally I also appreciate the need to explain the ‘key focus’ in the roadmap you create and distribute because it aligns the thinking of across the entire team. Keep in mind that much like all plans, the likelihood of events going smoothly is very low. For that reason then is why most people can get stuck into a cycle of rigidity and not allow themselves to be open to change. Hence the product roadmap is a direction and not, I repeat not a concrete plan. If anything the roadmap is expected to change in order to adapt to the user needs or the business in general. Being nimble is a huge a benefit in any in flight project.
As a result, what you thought was a one-off design plan was actually the beginning of a constant ever evolving product roadmap that you will eventually hate [hopefully not too much]. A good tip at this point is to obviously make your product plan easily editable since there will be changes occurring weekly and possibly even daily. Just another reason as to why I am fan of simple design and effective communication when it comes to creating the map for the next 6 months of development. Building the roadmap with tools like MS PowerPoint or Excel have numerous functionality that mostly everyone can pick up immediately.
At this point I hope I have instilled the need to not overthink the creation of the product plan but to instead think of it as a means to explain an effective plan with your team without the confusing details that could lead to misalignment. Again as the leader responsible for shepherding the product to release I have learned that an eye for long term logical planning is extremely impactful. Even being aware of other product releases within your organization or a competitors can provide valuable insight to how the next product launch could be anticipated.
So instead of keeping your team in the shadows till the next full team meeting, the idea is to have this living roadmap constantly updated in a quick and dirty manner that gets the job done so that you can focus on the many other tasks at hand.
Ah — I forgot to add the steering wheel and electronics for the car. Guess that’s another month added to the build time. Version 2.0 of ‘product CAR’ coming right up.
Originally Published May 2018 from my Previous Blog
