For any product leader or product manager, the roadmap is always the most requested deliverable. Turns out, it’s also the hardest to get right. Experience tells us that what most of your stakeholders are looking for is a “feature roadmap”. On the surface, it’s a great idea:
“Here’s a super predictable plan of what we plan to build so every function can go ahead and figure out what they’ll be doing to support it, market it, and sell it! Let's go ahead and plan out the next year so we'll forecast 100%.”
And it makes sense that everyone wants it. Knowing what’s coming can give everyone confidence; they can tell customers their feature is finally coming soon, “just hang tight”, or gives sales a little edge they can throw out to a new prospect. But the dark reality is that it rarely happens as expected. Even saying you know for sure what’s coming in 60 days is likely wrong (and it probably should be). Every day, you’re getting new information, talking to different customers, the landscape is changing, competitors are rolling out new features, your biggest customer just came on.
At best, feature roadmaps give false hope.
While it definitely makes everyone feel good for awhile, inevitably most realize over time that they probably don’t want to be making promises to it. You’ll be creating work for teammates in other functions that ends up sitting on the table. And by the time that feature is released, the positioning is outdated.
Don’t get me wrong; there are places that feature roadmaps do work and people commit to them. Especially very early on in finding market-fit; listening to the customer and doing what they ask will fulfill needs of very early adopters. The problem is once you’ve been there, you realize that isn’t the best way to give your customers what they need. Without ongoing validation of opportunities and refinement of ideas, you’ll likely end up releasing a bunch of features that don’t move the needle. It might take a year or two to see it happen but at some point you realize features aren’t what drives your business or product forward.
Now if you’re a product leader who’s iterated and made roadmaps before, you’ve likely run into what I see as the second biggest issue with roadmaps: every stakeholder wants to see it differently. Your internal stakeholders are happy with just seeing that list of features but your leadership team needs to see what product line or customer’s its impacting. Or maybe your board of investors doesn’t even know what the feature means; they just want to see what the problem you're solving is.
One additional wrench in all of this is that product roadmaps aren’t just features that a development team cranks out. They need iteration, water, and feeding. They need well laid out GTM plans, documentation, and demos. They need support and product marketing.
Enter the objective-based roadmap
The basic idea around the objective-based roadmap is that every product or feature launch is a cross-functional effort that ultimately is to serve the desired outcome for the company or business unit.
Because of this, the objective-based roadmap includes this information. Features are just one small part of your roadmap; remember that your job isn't just to crank out new features, it's to build value for your customers.
Here's a quick example of what an objective-based roadmap might look like for product team:
Immediately what you'll notice is it's not a gantt chart. We're proactively removing the idea and setting expectations that product development happens on a perfectly formed timeline in an Agile environment. Because it shouldn't. The sooner you're able to communicate what your role is responsible for, the better.
You can also use the example into smaller chunks like 30 or 90 days. If your objective is a sub-objective, just add a row above that indicates where your objective aligns to.
Let's talk about what's included on the objective-based roadmap:
- Objectives - This is your destination and should answer "where do we want to go?" Don't worry about SMART; it should be qualitative but significant. Keep them aspirational and focused on an outcome. These might not come from your team; it could be from the business. That's okay. You want to make sure you're communicating your responsibility for fulfilling that goal and why you've prioritized the work you have.
- Measures of Success - These are the measures you're holding yourself and your team accountable for. This is how you should be measured as a product leader. These shouldn't be your business-as-usual metrics. These are directly aligned to embody and measure the results of your work towards an objective. Don't be afraid to focus on leading indicators either; use this to your advantage if a time comes that you need to pivot.
- Initiatives - Initiatives are the work and deliverables your team will be working on to help reach your goals. This is where your features are represented, as well as the other function's work that align to product. These should be large buckets of work, not individual tasks. This is a great opportunity to work cross-functionally with other leaders to collaborate. Creating buy-in across departments will eliminate silos and create shared accountability. Also, don't be afraid to build in research and validation initiatives for your follow-on objectives or initiatives. Another note on initiatives: for lower confidence blocks, instead of features or GTM plan, use customer problems or hypotheses as your initiatives to validate.
- Confidence interval - This represents how confident that the information in your roadmap is the correct information. This is key to setting expectations especially as you move further along the timeline. One of the biggest misses for leadership is not setting expectations. Use your confidence interval to tell your team where your focus is and that data is always changing; you're constantly evaluating to make sure you are spending resources on the most valuable things because of what's best for the company and not because it was in a roadmap.
Every organization, team, leadership team, company, product are different. There is no one-size fits all. However, you as a product leader have an opportunity drive the entire organization to be focused on outcomes with your roadmaps. Product teams do not drive growth alone; you need buy-in and shared accountability. By including the above in what might be the most-viewed deliverable in a SaaS company, you're setting the tone for how each team should operate.
I hope this helps and please feel free to share your feedback with us.
If you're interested in more about objective-based roadmaps and building strategy around outcomes, I'd invite you request early access to Devplan. We're building a product that focuses on this and more to build high-performing teams.