Product managers (PMs) everywhere have long asked themselves the same question: “What should we build next?”
Most PMs turn to their product roadmap for the answer. The only problem is, most roadmaps suck.
Time after time, well-intentioned PMs find themselves falling into the same trap: using their roadmap as a release plan. In his talk, Roadmaps are dead! Long live roadmaps!, from #mtpcon San Francisco 2018, C. Todd Lombardo (VP of Product and Design at Openly) explains the dangers of treating your roadmap this way. On top of trying to keep up with unrealistic release deadlines and managing the expectations of frustrated stakeholders, not having a strategic, vision-casting roadmap in place can lead PMs to launch products or features they think their users need, only to find themselves retiring those very same products and features two years later.
I recently sat down with C. Todd to talk about all things roadmapping, and to learn how PMs can transform their roadmaps into the strategic communication tools they were always meant to be. Read on for part one of my discussion with him, and be sure to check back in a few weeks for part two.
The root of “Product Roadmaps Relaunched”
As a former PM himself, C. Todd is no stranger to the challenges PMs face—and in particular, their roadmapping struggles. “[After publishing Design Sprint], I started getting questions around, ‘What do I do next? What’s next after this? What should I do from here?’, and of course that’s where the roadmap as an artifact and a technique is really useful,” he explained. “I had struggled with it myself when I was a PM—and my colleagues were also hearing the same thing from their clients.”
Todd and his collaborators soon realized that there really weren’t any books out there purely dedicated to building roadmaps the right way—so they wrote it themselves. In the process, C. Todd noticed that most organizations and PMs were running into the same problem: They were treating their roadmaps as if they were feature release plans.
“People were conflating the purpose of a mid- to longer-term roadmap with a shorter-term committed release plan. They were expecting these two very distinct, very different things from two different artifacts,” he explained.
Roadmaps ≠ release plans
In the fast-moving and competitive world of tech, it can be easy to over-index on the importance of continually releasing new features to try to keep users engaged. And it’s not uncommon for these commitments to make their way onto the product roadmap. But making feature releases the focus of your roadmap actually muddies your longer-term strategic vision, and makes it hard to understand the real “why” behind everything you’re building.
“Your release plan should communicate, ‘We’ve committed to this, and we’re planning to release this thing.’ It’s short term. You shouldn’t have a release plan that goes out two years—but you should have a release plan that goes out from a few weeks to maybe a couple months,” C. Todd explained.
While release plans are bound by a higher level of rigor and commitment, roadmaps should be more directional. “Roadmaps should indicate the direction you’re going in,” said C. Todd. He used the metaphor of a roadtrip to demonstrate the difference between the two, where your destination is your roadmap and the turn-by-turn directions you use from Google Maps are your release plan:
“Those turn-by-turn directions to get me out of [my town] and onto the highway are very near-term, and should be really specific. It’s what I’m doing. But those turn-by-turn directions might change as weather conditions change, or there may be construction or traffic jams on the roads, even though my final destination hasn’t changed. Those turn-by-turn directions are great for the short-term, just like your release plan is. But don’t expect them to have the same committed stature as a roadmap, which is mid- to long-term, and which shouldn’t change. There will be some fluctuation, but your longer-term destination should still be roughly the same.”
I asked C. Todd how PMs can overcome this common challenge and start to leverage their roadmap for what it was always intended to be: a visual summary of the product’s vision.
1. Separate strategy from execution
The first step is to look at what’s on your roadmap and determine what pieces of it actually reflect your product’s long-term vision and strategy vs. which elements are more tactical, release-based tasks.
“Sometimes just forcing that conversation can [make you realize that you] don’t have that more strategic roadmap, C. Todd said. “You obviously want to see that what’s in your near-term roadmap does flow into and align with your short-term release plan. But . . . having those conversations can lead to the aha moment of like, ‘oh, this is how we need to separate those things.’”
Todd also encouraged PMs to partner closely with the engineering team throughout this process, since release plans are typically owned and driven by engineering. Including engineers in this reimagined roadmapping and release planning process helps them see how their work ultimately contributes to the company’s strategic goals, without compromising the integrity of the roadmap as a vision-casting, aspirational tool.
2. Focus on outcomes
The only way a roadmap will truly be effective is if it’s aligned to the company’s overarching strategy, vision, and goals—so it’s critical to focus on the outcomes you want to drive as you map out your product’s future direction. C. Todd challenges the teams he works with to get as specific and measurable as possible:
“‘Build version 2.0’ isn’t really an outcome-focused OKR. That’s not an objective. That’s a thing you want to make. But why are you making that thing? What do you get when you get that thing? Sometimes the conversation goes away from roadmapping and release plans into ‘Tell me about how you’re setting goals at your organization. Let’s talk about outcome-driven goals and have good KPIs that measure those.’ If you don’t have that, it doesn’t really matter what your roadmap or release plan are.”
He also noted that a company’s guiding principles are a valuable resource for shaping the roadmap. If you can’t map an initiative back to your company’s long-term strategy, there’s a good chance you shouldn’t be giving it your time or attention, because it doesn’t serve your organization’s ultimate purpose. Building the roadmap in alignment with the organization’s strategy is also a powerful way to empower product teams to prioritize their efforts and say “no” or “not now” to projects that aren’t in line with the company’s current goals.
3. Establish ownership
While your roadmap should be informed by a wealth of qualitative and quantitative data from sources both within and outside your organization, it should remain grounded in your company’s strategy. To make sure that’s the case, you should assign clear ownership of your roadmap and the strategy behind it.
“That really rests on the PM’s shoulders,” said C. Todd. “They’re the spearhead of the cross, the translator, the one who’s speaking a lot of the different languages and trying to be in all those different rooms. They need to be the ones soliciting all the information, synthesizing it, and having those conversations to make sure that everyone’s aligned.”
Todd also noted that while it can feel hard to manage stakeholder opinions, or even to say “no” to their requests, it’s important for PMs to hold firm and remember the reason for the roadmap (again, company strategy comes in handy here). “PMs need to be stepping up and making sure they’re driving the conversation and not letting their stakeholders drive them,” he said.
Using feedback to drive continual learning and insights
Another mistake some PMs make when it comes to their roadmap is not having a clear line of sight into their customers’ experiences with and perceptions of the product. Without a data-driven understanding of how customers use and think about the product, PMs are left to make assumptions about where to focus their efforts. In other words, they’re building in the dark.
Todd argued that the feedback you need to inform your roadmap shouldn’t just be limited to customers—your internal teams have a wealth of insight to share, too.
“It’s going to come in via your customer success teams, your sales teams, your engineers, your designers . . . You’ve got to put all your feedback in one spot, and figure out how to tag it and organize it in a way that’s useful for the product team so they can then look at what’s on their roadmap—and in that repository of information—and say, ‘how does this request match up with what my team’s roadmap looks like?’”
The most important step in collecting this kind of product feedback in an actionable way is putting it all in one place where your team can easily spot trends, assess the volume and associated value of the requests received, and use it to prioritize their efforts. “You need to give it a centralized home,” C. Todd explained.
Leverage qualitative feedback to enrich quantitative analytics
In addition to gathering stakeholder feedback, it’s also critical for PMs to have a firm understanding of how users are moving throughout and engaging with the product. Product analytics is an invaluable tool for PMs, and should help anchor how they plan and prioritize their roadmaps.
“You want your product to be an instrument for measuring user behaviors in the product. What pages are they going to? What workflows are they going through? Are they completing tasks the way the UX team designed them? . . . As a PM, you’re going to get Slack messages, you’re going to get PowerPoints, you’re going to get Excel files. You have to match all that qualitative information up with quantitative behaviors and KPIs.”
While the metrics used to track and measure success vary from organization to organization, product to product, C. Todd encouraged PMs to keep close tabs on core product KPIs like product and feature adoption, retention, and onboarding completion. He also noted that it’s important to understand where users are spending most of their time in your product so you can determine which areas are adding the most value to their lives—for example through track events or heat maps.
At the end of the day, there isn’t a one-size-fits-all approach for how to evaluate success. “What’s most important is that the data should help you understand if you are matching your expectations of what the feature was supposed to do,” said C. Todd.
Stay tuned for part two of my conversation with C. Todd—coming soon!
