Building an outcome-driven product roadmap strategy
How do you create a roadmap that will guide you to launching a best-in-class product? Hint: It’s not a one-step process. This is an ongoing cycle that must involve your entire organization. It’s not just about product, executives, or even your customers—your roadmap needs to reflect input from all these stakeholders while staying true to your product vision.
In a recent webinar, Productboard’s SVP of Customer Success Zach Anderson sat down with Mickey Alon, CTO and founder of Gainsight PX and Richard Steers, Chief Product Officer at ROLLER Software to discuss how to build an outcome-driven product roadmap strategy.
In case you missed it, here’s an edited excerpt of the conversation.
Watch the webinar on-demand
Mickey: Let’s start by talking about planning and prioritization. We see a couple of common phenomena: the feature-factory roadmap, which is highly focused on features and meeting deadlines.
Another is the sales-led roadmap, which focuses on a few features requested by promising prospects and tends to drift away from the overall vision.
The goal of an outcome-driven roadmap is to keep you in a safe place and guide your colleagues to where you want to go.
Zach: We have this dangerous animals of product management campaign we’ve been running at Productboard, and one of those is the HiPPO, the highest-paid person’s opinion. We need to be careful of those, especially in the sales-led environment. It’s become harder to separate the signal from the noise, and salespeople can be some of the noisiest when it comes to asking for what they want and what the customers want.
Mickey: Product managers have a lot of responsibility but they don’t always have a way to influence. It’s one of the most challenging jobs out there. You have so much pressure—from customer success and sales who come with very clear data points of, ‘This is the deal I’m going to close.’ And you have to balance the long-term vision vs. tactical vs. the technical debt you might be creating. The more frameworks you have to guide you, the better position you’re in.
Richard: Great product leaders are very good at helping sales teams better communicate the product’s purpose and vision. When you do share your roadmaps and the reasons behind the outcomes you’re driving to achieve, sales is on board for it. And it doesn’t take much to realign them and remind them why we’re doing something or not. But if there’s a void and we don’t set expectations, then people will set their own expectations and that’s when the requests get quite loud.
Mickey: Absolutely. Joining sales calls, I always learn what the prospects are looking for. But if you have a vision, you’ve probably thought about that problem already—you just have a different way to solve it. If you communicate that to the customer, they’re normally okay with that. Getting product people closer and closer to customers is really important.
Let’s take a moment to define what a classic roadmap should look like.
Zach: Here’s a definition we use at Productboard: A good roadmap is a strategic communications tool, a statement of intent and direction, and, done well, a way of rallying the whole organization around key problems that must be solved to achieve your product vision.
It’s less about the features and sales or success being in misalignment—it’s really getting that first level of buy-in that these are the right problems to be solving. And hopefully the product team is strong enough to know the right way to solve them.
There’s this friction that happens when your roadmap is too tactical. It becomes a point of contention within the organization—why is my feature not on this roadmap? When you’re all solving the problems at the right level and that’s clear to the customers, it becomes a lot easier for the team to be aligned and pointed in the right direction.
A roadmap should be debated. The product team should have gotten a lot of input from a lot of different places. The roadmap is a tool for saying, here’s everything we’ve heard and this is our interpretation of it. Here’s what we’re proposing, and now let’s have a dialogue to move this in the right direction.
Richard: There’s a tendency for HiPPOs to try to pull you into jobs that you don’t want to be doing or really shouldn’t be doing. Once you’ve had that open dialogue, they’re aligned with where you’re going from a product vision perspective. It becomes an easy conversation when you communicate that intent and direction.
Mickey: You need to build trust with cross-functional teams because eventually they’re the ones that are going to speak with customers and try to close more deals. Letting them know that you can’t build everything and you have to prioritize is a great way to start thinking about the purpose of roadmapping. So what should you avoid with roadmapping?
Zach: What you want to try to avoid is just sharing your release plan. You need to make sure you’re communicating the right level to the right folks. Roadmaps shouldn’t just be capturing what the team is working on. It really has to start with the vision, strategy, and alignment.
At Productboard, our core customer is the product team, and we’re always saying that focusing on the gut and opinion-based model is really a dangerous place to be. You should be talking to customers, focusing on how you understand customers’ problems, and bringing their feedback into your process. The roadmap isn’t a secret document—it’s intended to be shared and debated. Getting others involved in that process creates a really strong roadmapping culture.
Richard: One of the things that I find Productboard does really well is create multiple views of that roadmap so we can share it with stakeholders very easily.
Mickey: That’s a perfect segway to the discussion about different levels of roadmaps that we want to have.
Zach: We had some of our key customers—mostly Chief Product Officers and some VPs of product—join us for a customer advisory board meeting earlier this month, and one of their challenges related to roadmapping was matching the roadmap to specific stakeholders.
The product team tends to focus on their own goals and agenda. But there are also internal and external stakeholders, and each of those groups has a different level of detail and context to the roadmap.
Your customers just want to know if you’re working on the right problem—they don’t care about the features, per se. But when you’re presenting a roadmap to your internal product and engineering teams, it’s much more granular. What is the work that we’re going to do to solve that problem? What’s the sequence? What are the dependencies?
Mickey: Sometimes we see roadmaps at a very high altitude that don’t go into detail, sometimes we have the middle ground, but what you’re saying is that you want to build different views of that roadmap with different granularity.
Richard: I think in a real product-led organization, products are at the center of enabling success in all departments. And a lot of those initiatives you’re working on don’t necessarily benefit the customer, like billing integration or subscription management for your finance team—that’s not something the paying user really wants to see. And that’s why being able to create those different types of views for different stakeholders is really important.
Mickey: Having some elements of the roadmap that are associated with adoption is yet another view that’s worth mentioning.
Let’s look at a few common roadmap types.
Zach: With internal stakeholders, you’re presenting to your senior executives and talking about the market opportunity and the outcomes that might impact your business. That’s the lens through which internal stakeholders want to view the product roadmap. Usually the executive teams are defining OKRs or key strategic initiatives and what they want to see from a roadmap is that the work the product organization is doing rolls up to those same themes across the organization.
The second one is presenting your plans to the collective product organization. The focus becomes delivery-oriented and getting more granular with those timelines. Solving a billing or performance problem might be really big endeavors for your product organization with really minimal impact to your customers, so those objectives need to be presented a little differently.
The third is your customers, partners, and others who fit in that external stakeholder bucket. And this is really about trust, instilling confidence that you’ve understood and heard your customer-facing teams’ feedback. When your customers see this roadmap, they see that you’ve heard their feedback and ultimately you’re going to solve these jobs-to-be-done. It seems like as a partner, you get it.
Richard: If you don’t develop these roadmaps and publish them out, your stakeholders are going to feel this void with their expectations, and that’s where you get overwhelmed as a product manager with so much feedback coming in. It becomes difficult to deal with so many stakeholders and their whims and wants. Without creating alignment, those expectations are going to be set by stakeholders.
Mickey: I can tell you—as a founder, you underestimate how much you want to invest and make sure everybody is aligned. You have this vision and you know where you’re going, but the army is not necessarily behind you and they’re confused. So making sure that everybody is clear and aligned will help you scale the business.
Want to hear the panelists’ take on what should (and shouldn’t) go into an outcome-driven roadmap? Tune into the on-demand webinar.
