Rethinking the Product Roadmap
After reading this article, check out our latest thoughts on this topic here.
I walked into the conference room on the first day of work at one of my previous jobs and looked at a huge list of features on the whiteboard. There were maybe 20 in total, with a few scribbles on the side that looked like the beginnings of more. The other PMs explained to me that these were the items that were in their Product Roadmap the previous year, but they had run out of time to develop them all. The dev teams were crunching for the first few weeks of the new year to finish these features and ship them to customers. To me it seemed that some of these features were unnecessary and there was more important work to do, but I quickly discovered that a lot of the clients had these written into their contracts... and we had not fulfilled those obligations on time. I watched over the next month and a half as the teams battled an exhausting schedule, fixing terribly buggy code and working through botched releases to get the products shipped before the next phase of the Product Roadmap started.
Now this case was a very extreme version of when "Product Roadmaps Go Wild" (TV series anyone?), but it’s not uncommon. I’ve seen unrealistic roadmaps destroy teams and good products time and time again. Many problems could be solved if we stop considering Product Roadmaps to be a Gantt Chart rather than a high-level guide, but the way we make traditional product roadmaps prevent teams from being innovative and successful. Here's why:
Estimations are arbitrary.
Estimating the time it takes to create a feature usually ends up in a guessing game. I've even seen product roadmaps get built without developer input (note: this is a terrible idea). Typically developers will listen to a high level overview of which features will be built, and then assign some kind of value that will indicate how long it will take to build them. These products are popped into time slots and something else gets put right behind it - a la gantt chart.
Now when teams are two weeks away from the end of those X weeks and it’s obvious the product isn’t going to be finished, one of two things happen. One is the development time runs over and the next product is pushed off. This usually results in lots of screaming by management "we missed our deadlines" or "you didn't prioritize correctly". Or, the other - the team ends up rushing to release whatever they have so they can make the deadline and avoid the chastising. Number two can be an even bigger problem, as it usually results in buggy code being pushed out and little testing. More work piles up to fix the product, but that becomes impossible since the product roadmap is full and we need to start the next epic. Your product now becomes the king of the bugs.
It’s nearly impossible to estimate large chunks of work without planning out and thinking through the features, which we do not do when we plan roadmaps so far in advance. See the first example of this post.
Time for validation and research is rarely budgeted in.
Developing an excellent product needs extensive research, product strategy, a great UX, solid development, plenty of testing, and feedback from customers. Estimations in roadmaps usually leave out at least two of these: testing and research. When companies estimate how long a product will take, they usually tack on a week or two at the beginning for wireframe and design. Because little research is done, we often end up building products that do not solve users' problems. We don’t find this out until we’re working on the next product in the Product Roadmap because we shipped it at the end of the time frame and did not include time for feedback. Then time is rarely budgeted in to go back and fix the previous product since our roadmap is full. Which brings me to the next problem...
There's little room for change.
When we fill up 100% of our allotted time in the Roadmap with the development efforts, we leave no time to act on the feedback and make improvements on existing features. Every time we release a product, we learn new information about the customer's problems, frustrations, likes, and dislikes. That information should go back into making our products better, but all too often it does not because by the time we receive enough information to act, we've moved on to the next product.
We may also find out during one of these feedback sessions that there is a bigger problem we should be tackling. In fear that changing course will screw up our nicely planned roadmap, the normal response to this is "we'll slot it in when we go over the roadmap again". Unfortunately most companies revisit roadmaps twice to four times per year which is far too infrequent to respond to change fast enough.
A lot of the problems I mentioned above can be mitigated or lessened if you are constantly revisiting your roadmap, doing estimations correctly, and have a great UX practice. I know a few companies who are doing these things and seeing some success. But there is one fatal flaw I see in product roadmaps that we cannot correct with these processes.
Product Roadmaps focus solely on solutions and features, ignore problems.
Product Roadmaps plan out which large feature sets will be built over a long period of time, called "Epics". Since we plan Roadmaps well in advance, by the time we reach the start of an Epic we usually don't have much up to date research or information on what we're building. It could even be irrelevant or the problem has been solved. But, we rarely ever scrap these features. Why? We completely miss the point of building features, which is to solve problems for our users. We focus so much on planning and speccing out these elaborate features that we forget why we're building them in the first place. When the speccing phase starts on the Epic, we generally don't spend too much time really analyzing if the problem is still relevant because it had been so obvious when we planned the roadmap. Unfortunately this is the nature of thinking of solutions without carefully analyzing the problem first - you get wrapped up in the bells and whistles of feature sets, the original problem starts becoming more of a rumor than a motivation to solve something.
I see this as a major problem especially for startups that are transitioning to young businesses. They are putting more processes in place so they can scale well, but they still want to hold on to their competitive edge - innovating rapidly. When these startups start implementing product roadmaps, they find themselves moving out of problem solving mode and into feature overload territory. This can stifle innovation faster than anything I know. When the team is more focused on the processes of a company and meeting deadlines than creating value for a user, that team is in trouble.
So how do we give these teams some structure and direction, without stopping the innovation?
The Problem Roadmap
I'm suggesting that teams I work with start to treat Product Roadmaps as Problem Roadmaps. Instead of focusing on features to be developed, we focus on problems to be solved.
The Problem Roadmap can be planned over any amount of time, depending on what is good for your business. In my example I use Quarters, which I think gives adequate time to work through a test and a solution. It's broken into two phases: Discover & Experiment and Build & Validate.
Each cross-functional team works on a problem to be solved during the time frame. Their goal is to the solve the problem. We assign a KPI to each team which signifies if the problem has been solved successfully or not.
During the Discover & Experiment phase, the teams are focusing on customer research and validating that the problem exists. Once they have gathered enough research, they will start to build an MVP to test in the market. This part of the process should be done rapidly but carefully, with extensive customer interaction. After the MVP has proved successful, they move on to the Build & Validate phase.
In the Build & Validate phase, teams focus on minimum solutions (feature sets) to solve the core problem for the user. They are constantly releasing to customers and receiving feedback. They plan what they can build in the time frame, keeping the features essential and useful. When they have feedback, they can add more features and iterate.
If a product needs to be built out more at the end of the time frame, they can add it to the prioritized problems and weigh it against other problems that need to be solved using metrics. If it's high priority that these features be developed, they can continue the Build & Validate phase.
How to plan a Problem Roadmap:
- As a team/company, list out the top problems customers are facing now.
- Prioritize the list of problems with the strongest at the top.
- Assign each cross functional team a problem to tackle in that quarter and KPI to measure their progress in solving the problem.
- Each team is responsible for validating that their problem is still a strong issue for the customer. If a problem is no longer an issue, they will move on to the next problem on the list and validate that.
- Once a problem has been validated, the teams will conduct research on the problem by directly interacting with the customers.
- Teams will start to develop MVPs after initial research and test in the market.
- Once an MVP has been validated (has met the goals set by the team), the teams will start building a solution that can be made in the time frame left. They will focus on Minimum Feature Sets, with just the essentials. Teams will focus on releasing often for customer feedback and iterations.
- At the end of the quarter, the teams can decide whether more investment is needed in adding to the solution after they have received customer feedback in the initial stages. The roadmap will be adjusted for this.
- At the beginning of the next cycle, the process repeats. We revisit the list of problems and re-prioritize them based on customer needs, or add in new problems.
This Problem Roadmap solves many of the problems above. Instead of thinking in features, we think about how we can deliver the most value to our customers by solving their problems. Estimation for complex feature sets is not needed, since we focus on minimum solutions that can be built and released in short time frames to get rapid customer feedback. The roadmap is flexible since problems are constantly being evaluated, and irrelevant problems will be squashed at the beginning of each cycle. We can communicate the problems we plan on tackling to the team and our customers without committing to solutions we do not know will solve the problem.
What do you think? What have you done with Product Roadmaps that has been successful? If you decide to try Problem Roadmaps, I'd love to hear more about it!
