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.
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, with certain explicit or implicit assumptions.
Once you write those assumptions, hopes and wishes, in such a way that someone else can follow them to reach the expected outcome, you call it a plan.
This plan 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 at the end. And when we realise that some of those assumptions are incorrect, we will naturally update the plan and proceed accordingly.
It is not a plan if it doesn’t have an end goal.
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 only makes sense 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 perfectly normal that we complain about lack of flexibility of our plans (read: waterfall sucks). But also understandable when top management feels they have been hard done when teams fail to honor the plans time and again (read: why can’t you commit).
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/software tool.
This document is supposed to be your representative and the reference point for everyone, when you’re not in the room.
Let’s say you make your plan, you document it, present it to management and your team, and get the buy-in. And then?
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 if 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, goes out of sync with reality; 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 you using sticky notes in the team room, you’re in luck, you’ve done the important part of making the plan impossible to miss. You 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 the planning tools that work for a product manager don’t work for an engineer, or the CEO.
Perhaps a new tool is in order
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.
epekworks’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.
Having said that, it’s not about the software but the fact that for your plans to be realistic and helpful, they have to accessible, update-able, and fostering collaboration.
Disclaimer: Thank you for reading. I am the founder of epekworks- 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!You're welcome to follow us on twitter - DMs are open @epekworks
