Create an Effective Product Roadmap by Using Uncertainty Bubbles

There are many ways to create a product roadmap. Today, I'm introducing a new way of building a roadmap for your product development, with a one-day workshop.

The workshop consists of five simple components:

The first step in creating a product roadmap is defining your roadmap work items. These work items are the features you would like to include in your product portfolio. They appear during each brainstorming session. Basically, a list of your brain dumps. Getting all those ideas in one place will create a pool of ideas for product improvement. A key thing here is the infinity. Don't restrict yourself to any of the boundaries such as time restrictions, budget limitations, insufficient man-month, overcomplexity, scope uncertainty, etc. Put all these creativity impediments aside and just create an infinity pool of great ideas, as if everything is possible. Because it is possible.

You've just created chaos, a ton of unstructured requirements. Now it's time to bring some order. Write those work items on sticky notes and pile them up. Next, take your whiteboard and draw a timeline. Actually, the board it's not time-related, it's complexity-related. The least complex work item will be on the far left side of the board and the most complex work items will be on the far right side of the board.

How to determine the order? Well, for a start, pick one sticky note, any one, and stick it on the center of the timeline. Next, take another one and discuss with your team if this new one is more complex than the one which you've just posted on the board. If it is, stick it on the right relative to the existing one. Next, pick another one and compare it to both of the work items which already landed on the board. Keep in mind that you're comparing the complexity of each work item. Once you finish, you will get an ordered list of work items, starting from the least complex (easiest) on the left side of the board and ending with the most complex one on the right side of the board.

Now that you've established some order, let's move things to the next level. Start from the left and discuss the effort required for each work item. Assign relative numbers, just for the sake of the comparison between each item in a storyboard. You can use fibonacci numbering for this step. Assign a value of "1" to the left-most work item, and move to the next. Ask yourself: Is the effort required for implementing the next item as double as the previous? If so, assign "2" for the effort value. Otherwise, assign the same value as previous ("1"). Move to the next one and ask the same question. You get the pattern. In the end, you will have groups of work items, ranging from easy wins to complex monsters.

Now, you have grouped these work items based on complexity and effort. But those metrics are too abstract to have some real meaning. Instead of talking about the complexity and required effort in some relative units, I've decided to group them by the only thing that we know for sure - level of uncertainty. Each work item is represented with a bubble. Bigger bubble radius means higher level of uncertainty. This metrics come from our gut feeling, and we all know that our unconscious mind always gives us the best answer.

If we treat complex work items with uncertainty, we will be driven to sharpen up this blurred image of a yet-to-be-feature and define the requirements in more detail. Complexity causes fear, uncertainty drives curiosity.

As I said, a bigger bubble radius means a higher level of uncertainty. If you want to deliver value quickly, you should probably start working on those tiny bubbles, with a low level of uncertainty (high clarity). On the other hand, if you want to start working on a feature with a high level of uncertainty, you better burst the bubble into smaller ones. As you burst the bubble, you will gain valuable knowledge and master the domain before you start the implementation. So, before you deep dive into the implementation, make sure that the bubbles are tiny and actionable. Ideally, during one implementation cycle, you will work on delivering those tiny bubbles. At the same time, you will work with your stakeholders on reducing the uncertainty for the next cycle. This will give you a clean start for the next iteration or product increment. Clear scope and refined requirements are key to high-quality products. So go burst those big bubbles!

Since you've put all those work items into some sort of timeline, it doesn't mean that everything you mentioned there will be implemented. It won't. Furthermore, roadmaps should never be tied to a definite timeframe or milestone. Don't mix product roadmap with project timeline, they are totally different areas. Roadmaps are supposed to give you a relative timeframe of what to expect in the future, a strategic view of achieving the product vision. As we established the aspect of uncertainty, we should integrate that concept into the expectations of your stakeholders. High uncertainty levels (big bubbles) can result in high oscillations in delivery dates.

Short-term plan with tiny bubbles can be delivered with high accuracy, but as we move further into the future and the feature bubbles are getting bigger, accountability for delivery is also oscillating. You could deliver the feature later than initially expected, but sometimes, you could deliver it earlier. This is why the accountability is oscillating around a relative timeframe as the plan goes further into the future.

This should be clearly communicated with stakeholders because uncertainty about the delivery dates will motivate them to iteratively work with you on requirements refinement.

Hope this helps! Reframe the complexity of your work items into uncertainty and you will see how the planning process improves over time.

Have fun!

P.S. I've spent a couple of minutes to create a timeline infographic which is an outline of the article, so feel free to share it.

Disclosure: The Writer of this story is the Author of Treasurer Roadmap.