Your Audience’s Real Roadmap Questions
I get pulled into lots of discussions among product managers about the best ways to represent (and then present and present and present) roadmaps or backlogs, especially to internal sales/marketing/support audiences. These discussions often get very technical or theoretical: treating roadmapping as a purely intellectual exercise, where our secret ambition is for the world to admire our brilliant algorithms and decision criteria. Hint: this is how engineers would approach prioritization and roadmapping in an unemotional world of perfect information and fully aligned organizational goals.
For me, these discussions confuse good decision-making with “selling” those good decisions to various stakeholders. (I strongly advocate a “portfolio pie” model of prioritization, to avoid putting all of our development eggs into the feature basket. More here.) When we stand up in front of different audiences and present roadmaps, we need to understand their divergent – even conflicting — points of view, and anticipate their underlying concerns. Each functional group has its own product priorities, so each wants a different roadmap. Getting groups of stakeholders to “buy” the roadmap includes answering their unspoken questions.
Here’s a slightly stereotyped view of audiences and their questions.
SALES
Especially in enterprise/B2B, sales teams may have only a handful of major active accounts, each carrying a lot of revenue. A lumpy pipeline that depends on closing some specific deals. And those big lumpy deals inevitably include a few special requests. Salespeople sell their own credibility as much as our company’s actual product. (“I can get this really small enhancement done for you. Just sign here.”) They look at roadmaps from an account-level point of view more than a market-wide perspective. So first the question many salespeople are thinking while we present our next-quarter roadmap is…
“Why isn’t my strategic customer’s feature request included?”
Getting their specific enhancement might be the difference between their missing quota and President’s Club in Bali. It certainly feels that way. And we [product managers] are often too shy or subtle to give them really clear feedback about their requests. We talk about value and business cases and backlogs instead of bluntly saying that “this customer request is an outlier, so I’ll never put it into my plan.”
So when we walk a sales team through what’s really coming next quarter, we need to frame it correctly. “Our top two enhancements were requested by dozens of customers, including big players A, B, C and D. Working from your deal estimates, we think this should drive $8M of incremental sales. If there’s a feature missing that will drive similar revenue, please grab me right away.”
But telling salespeople NO doesn’t end the conversation. Their livelihoods are on the line and “it’s not selling until you’ve been told NO three times.” Sales teams that need a particular enhancement will escalate, increase their predicted deal size, or apply the same organizational tools internally that we pay them to apply externally to our prospects. Experienced salespeople will come back with…
“What were your specific selection criteria or algorithms? How did you choose what’s in plan?”
As introverted analyticals, we may think this is a chance get applause for our scoring, column weighting, and forecasting techniques – but there’s more going on. Good salespeople are trained to unpack their prospects’ decision criteria and RFP processes in order to tilt the buying process. (e.g. if we’re selling a product that’s more expensive but easier to use, then emphasizing usability over raw cost might win the deal.) So “show me your algorithm” is really about finding ways to make their specific deals score higher, or be reclassified, or to spot flaws that let them call into question the overall prioritization scheme. I always apply my own judgment alongside numeric sorting, so I avoid algorithmic deep-dives with sales teams. Instead, I emphasize picking improvements that large numbers of customers have requested.
MARKETING
Remember that outbound marketing teams are focused on generating interest among customers at the top of the funnel and in the renewal cycle. Webinars, social posts, third party analysts, product reviews, podcasts, and long-term email nurturing are anchored by new features and compelling use cases. So I expect marketing audiences to snooze past improved reporting and geeky back office efficiencies in order to ask…
“What’s new, interesting, or makes our customers look like heroes?”
Marketers need a steady stream of captivating headlines to engage prospects. Next quarter’s campaigns need a theme, and incremental improvements don’t generate much excitement. Marketers want compelling stories about how our product helps customers more than they need gritty details.
So I’m always reaching back to our original validation work about what’s new. (We did validation with lots of real users before jumping into development, didn’t we?) When customers told us about the problems they needed solving, what words did they use? When they explained how they would know that a solution truly worked, what words did they use? (“As a small business bookkeeper, I spend hours hand-editing accrual report to turn them into cash-basis reports. I often make mistakes. It eats lots of time, and I’m afraid I’ll get fired. An accrual-or-cash-basis option would save me 8 hours/week and I’d sleep better.”) Great marketers turn these into mini-dramas that tug at our audience’s heartstrings. When we’re stepping through a roadmap, let’s help them identify which product bits support good story-telling.
EXECUTIVES
Many company leaders came up through Sales or Marketing, so they may already be thinking about the questions above. But they have broader responsibilities, worry about company-wide economics, and are constantly pushed by investors for top-line growth. So I assume that roadmap reviews will surface deeper concerns like…
“Why aren’t we getting more done?”
It’s a rare executive who doesn’t push her/his VP Engineering or CTO hard on productivity, hiring ramps and fanciful notions about increased commitments leading to better outcomes. So this isn’t a roadmap-specific conversation, but an opportunity to re-raise concerns about development efficiency. I’m almost always shoulder-to-shoulder with my design/development team, who I know to be working their virtual-digital tails off, but an executive roadmap review isn’t the right forum for technical staffing justifications.
Instead, I usually defer to the VPE/CTO on the bigger efficiency question, and focus on prioritization choices captured in the roadmap. “Here are the out-of-plan items that were closest to the top. Is there something that we should pull into plan in exchange for pushing something out? A trade-off that you’d have made another way?” Notice that I’m not giving the executive team a free pass to put more into next quarter’s plan, only input on swaps.
In their defense, executives have been asking for a clear, simple, predictable metric matching development inputs to marketable outputs since COBOL roamed Cupertino, and IMO such a metric has never existed.
Which gets us to the other question that executives are thinking, but perhaps not voicing…
“Why aren’t we more innovative?”
This is a quagmire, since most folks in the room have conflicting ideas of what’s innovative: stuff that closes deals this quarter? Features the competition has announced? Whole new products or product lines? Anything that uses Big Data or Natural Language Processing or Augmented Reality? Innovation discussions are really about investment and process changes and entrenched corporate attitudes with major cultural implications (HT Alex Osterwalder).
My best in-meeting answers are about specific features or improvements that I believe are innovative, and why. (“We did a ton of market validation around new user onboarding, and this improved sign-up flow is 3x easier than our old version. That’s meaningful design innovation.” “Feature Z opens up a whole new segment for us, addressing a Job To Be Done that was unserved. We’ve beta tested with this new audience, and think it drives both innovation and new revenue.”)
If there are valid innovation concerns (and there usually are), strong product leaders get the key stakeholders together in a safe setting for constructive discussion.
SUPPORT
Our support and customer success teams spend their days helping current users get value out of our products, and stepping over whatever product holes we’ve created. They typically identify the right issues, and generalize well across the existing customer base. Importantly, most product managers don’t take advantage of what they know. So their question is usually…
“What about our frequently encountered bugs and UX/UI improvements?”
The tension isn’t with which bugs we’re fixing, but the fraction of development/design effort spent on current user versus new features and new revenue. My best response is to start with my “portfolio pie” model, show that we’re putting 20% or 30% toward customer joy and technical/workflow debt reduction. And within that, I’m happy to have Customer Success leadership help me re-prioritize what will make the most front-line impact. Sharing roadmaps with support teams is a feel-good opportunity for product managers.
DEVELOPMENT
Here, I’m combining the many folks who actually make what we sell: developers, designers, DevOps, test automation engineers, technical writers, security experts, process coaches. They pour their hearts into building great products, so I hear their biggest concern as…
“Convince us that we’re building the right things, which users will love.”
They want reassurance that product management is leading them in the right direction, toward adoption and customer joy and revenue, based on a ton of serous validation and shared context. They are mostly willing to accept our prioritization and roadmaps on the promise that their work will be appreciated by customers. Sub-questions might be…
“How does prioritization work? Criteria, algorithms, detail?”
where they are truly interested in the allocations and numbers and mechanics, to feel more secure about our decisions. And just maybe to tune our models a bit, to show us who’s smartest. They’ll often also ask…
“Can we shift more effort to tech debt and infrastructure?”
since development teams carry the weight of old code and poor tools and difficult release processes. In response, I ask for their help force-ranking tech debt based on perceived future velocity improvements. This becomes development’s answer to executives who want more productivity, as we trade off current quarter market deliverables against investments in next quarter’s efficiencies.
CUSTOMERS
Not to forget the most important people in this discussion, since customers give us their money, which is the real measure of product success. (Or don’t.) I find customers to be the easiest audience for roadmap presentations, since they usually understand that we have to serve a wide range of users/needs. Particularly in enterprise software, the underlying question rarely voiced by serious customers is…
“I’ve made an expensive long-term commitment to your company and product. Show me that you have a sensible plan that won’t embarrass me or force me to switch.”
That gives me, as the spokesmodel for my product, a chance to explain the 3-5 roadmap items which I think will deliver the most value to this customer. Assuming I know their use cases or got a good briefing from my sales team, this is a customized problem/solution tour.
(“There’s a lot coming next quarter that should be very useful. Specifically, you’ve been asking for better import/export tools to increase accuracy in your Treasury group: part of that arrives in February and part in April. And we’ve added cloud configuration widgets that have helped other customers cut their AWS costs by 15-30%, which should be a big win for your Virtual Pricing Models team. And we continue to improve the core product set, so you’ll get move value over time as part of your existing subscription. I know that you’ve been waiting for a currency conversion API: that’s turned out to be very challenging, so is still in the planning process…”)
In all of these situations, it’s important to know whether you’re looking for big strategic input (“yeah, OK, we could shift our entire platform strategy to make room for that new initiatives”) or presenting a mostly-locked-down plan with some room for adjustments (“good idea, let me bring that back to the development team for review”). Whether you’re prioritizing or selling.
Sound Byte
Roadmaps are a point-in-time capture of the current plan. Different audiences have different (often opposing) goals and incentives, which we need to understand and anticipate. That should shape what our presentations focus on and how we describe things.