Roadmaps - Outcomes, outputs, features, dates and headaches
Thumbnail Photo by Andrew Neel on Unsplash
So you’re a learned Product Leader, you understand the importance of outcomes over outputs. You’re not leading a “feature factory”, you don’t incentivize your teams to deliver whatever features were decided months ago. You want your teams to listen to the market, to hypothesize, experiment to validate the hypotheses and then deliver solutions that your market will accept. All of this is great!
But, invariably, someone will ask you to “present your roadmap”. No problem you say, you whip up a tabular format with months or quarters as columns, teams or product lines as rows and start listing all the wonderful features you’re going to build in the table. Maybe you size each feature and visually make them longer or shorter, show dependencies, add milestones even. Congratulations, you’ve successfully created a gantt chart full of outputs, sequences and promises. Your PMO will be very happy. In fact go ahead and start calling yourself a Program Manager or a Project Manager.
You know this is not how product works, you know these are your best guesses and things will change, they will evolve as you build and deliver work, as data comes in and you realize what’s working and what’s not, you’ll iterate and your roadmap will change. So you add disclaimers, “this roadmap can change” - but no matter how much you try, the larger team will hold you accountable for “missing your roadmap”. Your teams will be confused, do you want us to do hypotheses driven, iterative work, or deliver the plan?
After years of handwaving around the roadmap, trying, giving up and several iterations I’ve found a formula that has worked for me. What follows is an outline my “Roadmap System” - an attempt to provide the order and visibility needed in a roadmap, with room for creativity and emergence needed for good product discovery.
There’s no framework / methodology that will work for every company and every stage of the company’s evolution. This is the context in which I have seen this method work:
You’re in the “complex” zone of the cynefin model. Where experimentation is the best suited plan of attack
You understand hypotheses and experiments can lead to unexpected outcomes, and success relies on discovering what works and what doesn’t as quickly and as often as possible.
You believe in decentralized decision making, you believe the team closest to the problem are best suited to discover the right solutions
You also believe teams can be empowered to solve the problem, provided they are accountable to solving the right problem
Building Blocks
Before you have a roadmap, you need to be clear about your goals and strategy. My weapon of choice are Product OKRs
Product OKRs are derived from higher, business level OKRs (Not mathematically)
Product OKRs are the “Product Outcomes” we think will lead to the “Business Outcomes” we seek to achieve. e.g. if the business OKR is to “expand into the SMB market and generate $1m revenue”. Product OKR can narrow it down to which SMB persona we want to serve, what problems we want to solve for them and how we’re going to measure progress.
These are strategic bets - there’s no certainty we will meet these product OKRs and moreover there no certainty that meeting the Product OKRs will definitely meet the business OKRs!
Each OKR should have a “Live Report” where anyone in the organization can see in simple terms the KRs and progress towards those KRs
The traffic signals are not “scores” of these KRs, they are signals used by the team to indicate we’ve already met the KR (Green), we’re working on it and believe we will meet the KR within the allotted timeframe (Yellow), or we’re giving up on this KR, we’re not going to meet it (Red)
I also assign a color to each OKR - for visual ease. This will become more obvious in later visuals
In case there’s any doubt - “Launch feature x by end of May” is NOT a good Product OKR
With well defined Product OKRs, the product team (obviously cross functional and empowered) get to work. The next building block is an Initiative
An Initiative represents one hypothesis to be validated or a distinct product feature
The initiative should be based on qualitative and / or quantitative insight, summarized on the initiative card so anyone outside the product team can read and sniff test.
There should be clearly defined, measurable Success Criteria, along with a link to a live report. These are KPIs with a specific target, not just “increase x”
Again in case there’s any doubt - “Launch by x date” is not a success criteria
There should be an associated list of experiments, and features that are part of realizing this initiative
An initiative can be considered “Successful” only if all the success criteria are met, denoted in Green. A Red signals denotes we invalidated the hypothesis, the feature was abandoned because of effort overruns, or the feature failed to meet its goals in production to a degree that we decided to roll it back. A Yellow denotes the initiative failed its success criteria, but we have other signals that tell us it is still worth keeping in the product.
Building the Roadmap(s)
To think a single representation of your roadmap will suffice for all audiences is in my opinion naive. We all have a desire to be “efficient” and have “one source of truth” - but these goals should take a backseat to the more important goal of communication with others. I have found having to maintain multiple representations of a roadmap to be far more effective and in the long term efficient, than to present the same version to everyone and answer the same questions over and over again, or worse, deal with people focusing on the wrong things.
Weekly, Team Level Roadmap
Maintained by the Product Manager in consultation with leads. Reviewed with team and leadership weekly
Leadership’s (VP Product / Head of Product) responsibility is assess if the team is focussed on the right initiatives, help level up the team in their experimentation efforts, and provide feedback on how to reduce lead times. Recognize and highlight successes. Absorb what the team is learning and see if the overall strategy needs an update.
How to read the roadmap:
Now - Initiatives that the team is actively working on. Expect completion in the next month or so
Next - Initiatives that are either waiting for capacity or in discovery. Expect Product Managers, Analysts, Team Leads, Designers, Stakeholders to be doing non-product experiments, interviews, design iterations etc. Some scoping may have begun. Expect initiatives to change drastically at this stage.
Later - High level initiatives that are yet to be fleshed out. Either due to capacity, or awaiting results from some earlier initiatives to come through
Each initiative is color coded to indicate the primary OKR it supports
Monthly / Quarterly Company Wide Roadmap
Used primarily to provide a quick summary to the company at all hands.
Each row is an OKR, with columns representing Quarters or Months (your choice)
Each done initiative indicates whether it was successful, and what we learned from the initiative. All failures are also shown.
Initiatives are shown in the column that corresponds to when they were done, ie. when we made the final call on whether the initiative as successful or not. The diagram is not meant to show how long we worked on it, or how much effort it took.
Goal is to show how many initiatives we can get done in a period and what our success to failure rate is
The “Planned” section shows Initiatives from the “Later” column
An enhanced version can include a graphical representation of the associated KRs and markers for major initiatives. This can visually show which initiatives had what level of impact.
Monthly / Quarterly Board Roadmap
External roadmap drops any initiative that were deemed unsuccessful or neutral
OKRs are also dropped, since they might be different over a course of a year
(Not shown here), the focus should be on progress towards the business level okrs, and what product work lead to them. This can also be shown graphically with markers for key launches.
I prefer to tell success stories in these scenarios, not the trials and tribulations (experiments) we went through to get here.
Quick Note on Tools
For the longest time I relied on Google Sheets to visualize Initiatives and Roadmaps. Sometimes transferring so slides for presentation. More recently, I used ProdPad and found it the least annoying of all the roadmap tools I have used. ProdPad has initiatives and ideas, the Now Next Later roadmap is natively supported and there’s an OKR add on. Try it out, they also have a sandbox which allows you to play around with things. However, I strongly recommend using this approach without any specialized tools first. There’s a mindset shift that is necessary for this approach to work, and adopting a tool before the change in mindset will lead to a lot of frustration.
To learn more:
Book: Product Roadmaps Re-launched - Excellent review of the many different roadmaps in action. Great resource to get you re-thinking your roadmaps
Strategize: Product Strategy and Product Roadmap Practices for the Digital Age - Roman Pichler’s GO roadmap template was my first experience with someone really trying to talk roadmap in terms of outcomes not features.
