Making Product Roadmaps Like You Mean It

The state of affairs

Every software team out there uses some sort of planning system or tool to do product roadmaps and sprint plans, and yet many are unhappy with the tools, or frustrated at the lack of getting things done, or getting "pointless" things done, and the list goes on..

For an industry that has been using planning pretty much since its inception, and has written volumes about good plans vs bad plans, waterfall vs agile, strategy vs execution, we still seem to be at a loss when it comes to effective planning.

So what's the point of all this planning?

Let's take a step back and find something we can all agree on i.e. The purpose of planning is to give us an idea of how things might go in a perfect world. Perhaps even throw in some exceptions and conditionals like "if we manage to do user authentication, we can proceed to do user on-boarding" OR "if we build a wishlist (backlog) with all the requests coming from our users, we will add comments or scoring feature to discuss and prioritise those requests"..

But why do you need to do anything?

Simon Sinek's "start with why" is an excellent way to uncover the motivation behind doing anything. In product development, your why is the salient part that happens in-real-life, through your own understanding and the conversations you have around the purpose of your company or product. Once you know why you want to something, the next best thing is to attach a goal to it, to enable the planning process as well as to know when you're done.

Back to planning:

All that a plan does is gives us an understanding of what we will do, and in what order, if our assumptions are correct, in order to achieve the (relatively concrete) goal we have attached to our "Why". And when those assumptions are incorrect, we will update the plan and proceed accordingly.

It is not a plan if it doesn't have an end goal. This goal might be very concrete e.g. increase user retention by 5% OR generic e.g. keep prioritising the top most-asked-for features.

The goals are what enable all the discussions that need to happen in order to ensure the quality of the plan as well as the execution. Without a goal you can not argue whether an intermediate milestone or a feature makes sense. In other words, without a goal, you might build something and get somewhere, but that somewhere might not be where you want(ed) to be.

Given this context, it is perfectly alright to consider a product roadmap or a project plan as a living document that is subject to change, in line with our understanding of the world as well as the impact that we want to create.

And so, when the world changes and our plan doesn't, and fails us, it is also perfectly normal that we complain about lack of flexibility of our plans (read: waterfall sucks).

It is also understandable when top management (the people in power) keep pushing for features that the Product Manager or the development team knows to be out of touch with reality, or when the ground situation or the purpose of the feature has not been clarified.

What do the product roadmapping or planning tools offer us?

Let's suppose you have determined a goal that you want to achieve, and laid out the intermediate steps (milestones) you need to take to get there. This is essentially the core job of a Product Manager i.e. to take in the business objectives and translate them into product strategy and lay out a path to achieving those goals -and work with a team to make it a reality. It goes without saying that one needs to involve all the stakeholders in this process, and that includes your business leaders, your customers, and your team.

Having done all of this, what do we do? We put all of this in some document or a tool.

This document is supposed to be your representative and the reference point for everyone, when you're not in the room.

In real life, you make your plan, you document it, present it to management and your team and get the buy-in. And then?

This is a crucial point where things start to go wrong. We know that what you say may not be understood the way you intended it to be. And if the document you prepared only works when you're in the room, then you have a problem.

2 weeks in or two months later, you look at the product and say the famous words "this is not what I expected".

So the job of the document really is to be able to not only convey what you wanted clearly enough, but also to encourage the right discussions about how to achieve those goals, whether they're even realistic and whether there might be exceptions or other ways to get the same results.

Unfortunately, the way most of our industry works is this: The document gets stale, things go out of sync, and we do this over and over again.

The solution:

Find a way to make sure that this document lives in the same space where the day-to-day work happens. Ideally even directly connected to the day-to-day tasks so that any problems and misalignments are seen almost immediately and can be addressed; and everybody stays in the loop if the plan changes, without the wait for the next quarterly meeting.

For those of us using sticky notes in the team room, you're in luck, you've done the important part and can continue with fostering the daily communication that needs to happen around these plans.

But if you have a remote team or are using digital tools, we need to nudge people to look at the roadmap. And most of them don't. Simply because what works for a product manager doesn't directly work for an engineer, or the CEO.

Perhaps a new tool is in order

This is where epek.app comes in.

By plotting your business goals on a timeline (roadmap milestones), you effectively kickstart the discussion around what is it that you want to achieve, what the next goal is, and how it connects to the ones after that.

Having done that, you can work out the details of what you need to do in order to achieve those goals (stories and tasks)

And by having all of those in one place you can simply share this with your stakeholders for maximum visibility as well as real-time understanding of how things change.

While no tool can do the homework for us, we can make our goals visible enough to invite the conversations that need to happen.

Epek's goal is to foster collaboration by bringing roadmaps close to day-to-day work, and enable those crucial conversations around how to achieve the intended outcomes, which often goes missing when roadmaps live in separate documents that don't scale.

If you like the idea, go try out https://epek.app!

• Disclaimer: Thank you for reading. I am an the founder and CPO of 

  epek.app

   - we have just launched, and regardless of whether you agree or disagree with my thoughts, if you give 

  epek

   a try, please do share your feedback! We will remain forever grateful for it!

• P.S. 

  epek

   is optimized for a desktop experience - mobile will definitely look broken atm

• You're welcome to follow us on 

  twitter

   - DMs are open 

  @epekworks