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'ld probably have a roadmap. You'ld be updating 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.
And so at any given moment, you could open up your roadmap, and tell me where you were at that moment, where you were headed, and your informed belief about when you might get there.
Your software product roadmap or project plan should be able to 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 KPIs.
As CPOs and CEOs we create strategic roadmaps, which mark our path to the realization 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 realize the business goals.
As Engineering managers, we concern ourselves with the development roadmaps, that will help us realize 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.
And all the activities that we do in product development are supposed to help us achieve certain business outcomes.
And 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 both of the following are true:
- your roadmap doesn't mention outcomes
- your roadmap is not connected to your weekly/sprint goals
Unfortunately, too many product managers and engineering teams are working without product roadmaps.
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 of 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, before you jump into how. Here's a simple illustration of an outcome oriented milestone on a roadmap, made on epek.app
The two milestones on the bottom side of the timeline exemplify the don't do of a roadmap, namely:
"Do not use phrases that don't clarify purpose"
"Do not define the feature specifications without giving context"
The two milestones on top side show what belongs on a outcome-based roadmap instead i.e. provide context and and clarify purpose.
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!
Previously published at https://medium.com/@balach/product-roadmaps-you-can-actually-follow-epek-de483cb74a44