Get real about roadmaps and plans
Product Roadmaps you can actually follow
If this was 40 years ago and you were doing a cross-country road trip from the American east coast to the west coast, you’d probably have a roadmap. You might be checking it every few days depending on the weather and the news you picked up along the way. You might have stayed a night longer in a beautiful town and might have decided to skip another.
You could open up your roadmap, and tell me where you were at that moment, where you were headed, and your estimate about when you might get there.
👉🏼 Your software product roadmap or project plan should do the same for you.
The point of a product roadmap is to communicate your current state, and the path to a particular state of affairs w.r.t. to your product and its goals.
And contrary to the popular belief, Roadmaps don’t just belong to Product Managers. We all have different inputs and expectations of roadmaps. As CPOs and CEOs we create strategic roadmaps, which mark our path to the realisation of the vision and mission of the business. As Product Managers we create strategic product roadmaps for the path that we take, in order to realise the business goals. As Engineering managers, we concern ourselves with the development roadmaps, that will help us realise those strategic moves w.r.t to our product.
In all these cases, we are talking about outcomes at different zoom levels, from vision to mission, to product strategy, to weekly and daily development.
All the activities that we do in product development are supposed to help us achieve certain business outcomes.
So a product roadmap is great or terrible in proportion to how well it does the job of communicating what those outcomes are and what our current plan is.
How does your product roadmap compare?
You might want to revise your product roadmap, if one or more of the following are true:
- your roadmap doesn’t mention outcomes
- your roadmap is not connected to your weekly/sprint goals
- Not everyone in your team can access the roadmap
Unfortunately, too many product managers and engineering teams are working without product roadmaps.
Many people have written about the love-hate relationship they have with their roadmaps. A lot of PMs do not want to put dates on a roadmap for the fear that it’ll be considered a commitment and they will be held hostage to a promise that might become obsolete during development. Some people even suggest to not talk about dates and commitments at all. Personally, I feel that’s akin to throwing the baby out with the bathwater. I’ld much rather plan properly, and adjust, than not commit at all.
In all of this, there is a better way to plan effectively: Outcome based roadmaps that connect with day to day work! Think about “what exactly is it that you want to achieve”, not a feature you want to develop but the business outcome you want. Most business outcomes boil down to either getting more users, or keeping your existing users happy.
So when you do outcome based roadmaps, think of what you will enable your users to do and the results you want as a business, before you jump into how you will get those goals.
Product Roadmap Planning for the 21st century
epek.app lets you build great roadmap plans in minutes. Epek roadmaps are actionable, shareable, and a delight to work…
The moment you switch your roadmap from features to outcomes, and make sure that the roadmap lives in a place where everyone can access it, you unleash the collective intellect that will find the best ways to achieve those outcomes.
At least that’s how I’ve experienced it with my teams. Let me know if you’ve tried it or want to try it. I’m always happy to support if you have questions!
Disclaimer: Thank you for reading. I am the founder of epek.app — for feedback and exchanging notes, you can always reach me on twitter: @balach- if you give epek a try, please do share your feedback (@epekworks)! We will remain forever grateful for it!