Product roadmaps in Agile
Time is a very important concept in life and its importance in the modern technology space cannot be over-emphasized. It’s absolutely necessary that you build things at the right time and at the right pace. This problem is what roadmaps hope to solve in building tech products.
PARKINSON’S LAW:
The need for prioritized work to fill a certain time period or time-space is not a new concept. There are so many quotes, speeches, and blog posts that have existed in the past to drive home the fact that it is better to plan ahead in anything you do. Parkinson’s law which is an informal law at best gives insight into the need for planning and prioritization.
Parkinson’s law says, ‘Work expands so as to fill the time available for it’s completion’
This informal law is also vital in the SDLC (Software development lifecycle). The right timing is very necessary especially when you are introducing a new product.
The difference between The Plan and Planning:
There are two main ways of building software technology: Agile or waterfall. The waterfall is the traditional building process where requirements are completely spelled out before any sort of building starts. This doesn’t mean it’s old school though, it is a very important building process for high-risk products like Airplanes, cars, houses e.t.c. On the other hand tech products especially software products don’t need to have all the requirements spelled about before building starts, this is where agile came in, where you build continuously iterating on feedback. This feedback is important because you don’t want to end up building a product that no one wants or needs, you get to validate your ideas with this valuable feedback.
In Agile, there is always the main plan exemplified in documentations like a roadmap, product strategy, product vision, Lean model canvas .e.t.c. and there is planning which is the point of feedbacks used to iterate in Agile.
It’s just like how we set tasks in the morning to achieve but, we have to still make adjustments to that task during the day to get it done because of unforeseen circumstances that were not accounted for at the beginning of the day.
The Plan: Everything that needs to be done properly has to start with a plan. For the waterfall process that is a very obvious statement but in the case of Agile, it’s a little tricky because you are not supposed to have all the requirements clearly planned out from the start.
The plan you start out with must be very dynamic, we call them living documentation because as it is seen with many successful tech products being able to iterate based on what you learn about your product is extremely important. Instagram used to be known as Burbn, which included check-in features, photo-posting options, and the ability to earn points, among other functions. A game called Glitch pivoted to Slack which you will most likely be very familiar with if you work in the tech industry. Twitter was a pivot that first launched as Odeo which was supposed to be a platform for discovering and subscribing to podcasts. Youtube was originally a dating site and the list goes on and on from there. If you are new to product management you must have heard something like documentation and communication are a major part of product management. Well, there is no documentation without a plan.
Planning: This is what forms the core of Agile. In scrum, we have rituals like Daily stand-ups, Sprint planning, Sprint reviews, Sprint retrospective just to make sure the team is iterating and making sure the team is working on the actual value. Kanban doesn’t have standardized rituals but concentrates on the flow of work in a way that accommodates feedback for validation. These flexible short-term plans that I call ‘planning’ will always affect the main Plan which I introduced earlier and now we will see how this affects the roadmap.
The error with using roadmaps alone:
The Product roadmap is nothing more than a long-term product development plan that gives all product stakeholders the information they need to coordinate their planning. Firstly, if you found this article looking for a roadmap template let me first explain that a product roadmap depends on the stakeholders involved in the product. The most important thing to consider when building a roadmap is that the stakeholders involved are aligned.
So who are the stakeholders? They are customers (note that these are not individual customers but a representation of customers because customers using your product is what determines success or failure), customer-facing groups like sales and marketing, investors, and even the development team. The stakeholders have two main worries according to Marty Cagan:
- They want to be sure you are working on the highest value items first
- They want to know when there are key capabilities to launch, so they can plan for the business
These are all valid things to worry about as stakeholders but the problem is in some companies, some stakeholders draft out the roadmap and pass it down to the development team and when there is a problem, each team will claim they were not consulted. The most realistic roadmap, which has the closest accuracy, is formed from the alignment of key stakeholders and the development team, the reality that the product roadmap can change, and a sound product strategy.
This is completely different from when stakeholders conceive the roadmap and hand it down to the teams. This is a recipe for disaster because the stakeholders have not considered so many factors like the capacity of the team building it, how customers will react to it, and the necessary feedback that can affect the schedule. So these roadmaps are usually far from accurate and when achieved do not satisfy customer/market needs. This is why we need goals to drive the roadmap.
For the roadmap to be successful it must have obvious value, great usability, must be feasible, and must be viable to the business.
The Product Goal and The Roadmap:
The scrum guide describes the product goal as the future state of the product. I believe this gives enough insight into why the product goal is very important in the plan and planning of products. With the future state of your product in mind, you think and deliver in terms of the big picture goals rather than just delivering immediate tasks. A lot of product leaders I follow have made this distinction by differentiating them as Outcomes and Output. For an Output you just want to deliver what you’ve been asked to do, or you just want to declutter your table or to-do list. A team that reasons this way is not aligned and that means the product manager has failed in his job.
The Outcome is what drives the sprint backlog or the release timeline, which in turn forms the roadmap. In this case, you are not just delivering features over a period of time but valued features.
In case, you have been getting lost in all the product management lingo, or you’ve just been using a template without much in-depth understanding. I hope you can use this article as a guide because I’ve realized from experience that understanding the reason why we use these tools or best practices in product management is more important than using the tools themselves.
You use roadmaps every day already…
You have probably planned a cleaning day before, you most likely woke up and drew up a task list: Sweep the floor, wash clothes, do the dishes, feed the dogs, take out the trash, mow the lawn, cook food, eat. etc. First, you have to prioritize how this will flow but in reality, even though you have planned to mow the lawn before cooking food, you might cook before mowing the lawn because of hunger. Like Maslow’s hierarchy of needs says, food, which is a basic need for you will trump secondary things like mowing the lawn.
So with this, you understand that roadmaps are a very important planning tool but they will change depending on how needs arise in reality.
