I’ve written a lot about how we (as product folks) love to talk about how our teams build things: releases and sprints and backlog ranking models and product operating systems. (Oh, my!) But many of our colleagues and audiences are deeply uninterested in what happens in the kitchen.
Another way to frame this: we need to read the room to understand what a particular audience wants, before launching into lectures or presentations. And be prepared to adapt our content/message/engagement model/tone depending on the situation.
This shouldn’t be anything new for product folks: when we’re talking with real customers and prospects, we naturally shift between benefits and features and architecture and detailed how-to and individual support issues and pricing and product strategy and competitive advantages and heartwarming user vignettes depending on the situation. We are constantly reframing or repackaging our few essential messages so that our paying customers get it.
So IMO it’s especially helpful to take 60-90 seconds before walking into any internal meeting to ask ourselves some grounding questions:
- Who’s our (internal) audience? Are there different groups/needs represented in the room?
- What are they are expecting from this discussion or presentation? What do we need from them, if that’s different? Is there an agenda or intended outcome?
- Short or long content and attention span? Technical specs or customer war stories or architectural choices or content-light encouragement or in-depth usage tutorial? Visionary black turtleneck or just-the-facts-ma'am? What does this group know (or refuse to remember) so that we can cover what’s most important to them and us?
- Organizational or political context? Some meetings are free-wheeling discussions where we spitball lots of random suggestions and laugh about silly-seeming suggestions. ("There are no bad ideas") Others are buttoned-down justify-your-value-to-the-execs recaps of wins and company-level contributions, with extra points for sounding confident.
Or we’re in a C-level crisis of confidence. Or one participant routinely asks embarrassing questions and takes us off topic. Or we will close our doors if we can't book another £800k by Friday... we need to recognize the unstated political realities of many meetings.
A lot to consider. And it’s not covered in scrum class or lofty presentations about mythical product operating models. A real-world challenge that’s more Dale Carnegie than Jeff Sutherland.
So imagine that we are B2B/enterprise product managers hopping from a F2F maker team meeting to a discovery Zoom call to a sales rally to a C-level periodic update to a new customer pitch… with some exaggeration and caricature.
Roadmap review at annual sales rally
Audience: most of our sales force, go-to-market execs, lead/event-focused marketers, select channel partners, finance
Their expectations: high-level, upbeat, motivational (SHORT!) recap of what they can sell now and what’s new that helps them hit quota.
Their anti-expectations: product details, long demos, dense competitive analysis, pricing/packaging intricacies, internal processes, futures, how we apply agile, reasons things were late, engineering headcount and hiring challenges, complex explanations of why we’re not building something that some customers want. Or our nerdy theory that selling is easy.
Our goals: reiterate no more than 3 takeaways that are easy for current-quarter-revenue-focused attendees to remember. Show partnership. Not be pummeled for Product's perceived shortcomings.
Style: brief, snappy, graphics-heavy/text-light,
We might say things like “Our new cyber-protection module beats the competition hands down, and could save Chief Security Officers their jobs. Here’s a 60-second video testimonial from FintechCorp’s CISO explaining why she’s so excited to pay us $85k/year!”
“Our AI reporting engine isn’t revenue-ready yet, but will get large automotive and pharma customers excited. If an unpaid beta trial will help you close a six-figure deal, let me know.”
“Many of you have shared feedback that our Extract function is slow and incomplete. Agreed. We've made huge improvements this quarter – 2.5x faster and connecting to 5 new systems. Slack me if you want a product manager to talk details and demo the new version for your technical buyers/users.”
Growth marketing working session
Audience: growth marketers, lead gen team, marketing leadership
Their expectations: exciting new benefits, delivery timelines, laser clarity on customer segments or likely adopters, starter messaging, how to boost engagement or adoption
Their anti-expectations: how it works, development processes, architecture, detailed pricing
Our goals: help identify ways to boost interest in what we're already building
Style: upbeat, analytical, non-hierarchical, searching for calls to action
We might say things like “Our new cloud restore feature will be most relevant to current SMB customers who don’t already have a separate cloud backup/recovery solution. We think 40-60% of customers in our $2k-$10k packages need this.”
“Key benefits are trivially easy setup (< 4 minutes), huge savings versus stand-alone products, and support for EU privacy/cookie standards.”
“Activating paid users immediately after they sign up is critical to renewals. Let’s talk about campaigns to reduce churn.”
Feature-level concepting and design
Audience: maker team including product, design, engineering and perhaps UX research or product ops or product marketing
Their expectations: deep discussion of Jobs To Be Done, user segments or personas, economic value to us and users, strategies, OKRs/priorities, implementation choices
Their anti-expectations: taglines or marketing copy, company-wide revenue issues, product managers already having made most decisions
Our goal: get the best brains focused on our most important problems
Style: serious or playful collaborative ideation, all voices heard, many solutions rapidly proposed and retired. Good ideas beat seniority.
We might say things like “Walk me through your thinking. Love the idea, but I’m not clear on how that approach supports our goal.”
“On first blush, I like all three of these solutions. Let’s talk through each – in turn – looking for risks, opportunities, overlap, leverage with other work…”
“Since you (UX/design) did most of the end user interviews, how do you think we’ll be graded on this? What frustrations or emotional context is important here? Are buyers/users thinking with their hearts or wallets?”
“How might this fail (aka pre-mortem)?”
Triage for at-risk delivery dates
Audience: maker team including product, design, engineering and perhaps product ops or product marketing or support. Product and Engineering leaders may hover.
Their expectations: tough discussion about commitments, dates, work estimates, critical versus postponable capabilities, long-term costs of short cuts and tech debt. What can we push out or re-arrange and still ship a successful product?
Their anti-expectations: handwaving, executive opinions about what’s easy or hard, over-optimism, lectures about what was committed 15 months ago, revenue scolding, lectures about fictitious best practices at FAANGs.
Our goals: collectively find some reasonable options, get ahead of the blame game
Style: practical, collegial but pressured, quick elimination of unworkable choices, senior participants often drive decisions
“Our overall design covers 6 error conditions and 4 non-happy-path workflows. Could we postpone some? Which segments would be hit hardest? Implications for end users, data cleanliness, support tickets?”
“If we postpone those 5 features/capabilities, can our product meet users’ fundamental objective of doing X and Y? Do we need to push the release date? What's our guess about how many months?”
Progress/roadmap review with Board
Audience: board members, senior company execs
Their expectations: revenue forecasts, strategy, quarter-to-date revenue, how major products could contribute to the top line sooner, metrics, staffing, revenue. One very short customer success vignette. (And lately: an exciting AI strategy even if it’s entirely fake or irrelevant or requires a miracle to succeed.)
Their anti-expectations: cross-functional blame, process discussions (unless they think we have a process problem), revenue that’s a year away, explanations of why engineering throughout/velocity metrics aren’t meaningful, detailed how-this-product-works tutorials.
Our goals: identify revenue-related product progress, show product/engineering/design as critical to company success, not dwell unnecessarily on negatives
Style: clear, short, upbeat/assertive, high-level but ready with detailed answers to likely questions.
We might say things like “We’re starting to see real results from 3 quarters of performance/scalability investments. User queries are 1.4x faster than in January, we can inboard a new customer in 3 hours from 11 hours, and AWS costs are 35% lower per account. That’s €3-4M savings per year so far. We have another 1-2 quarters to go, with similar expected results.”
“Product, Marketing and Sales agree that our SuperWidgets shipped on schedule and work as planned -- but may not be targeted at the right segment. Lots of product/market fit issues at the high end of our SMB audience. Delivering 50-60% of the revenue we expected. So we want to shift messaging and outreach toward our smallest accounts, and focusing design/engineering on simplifying the sign-up process.”
“As agreed in January, our LLM shipping module was built to drive sales of our flagship ERP – not to make much direct revenue. Win/loss shows it contributing to 20-25% of current deals with a top-level of €50-60M. So we’re not applying Finance’s normal SKU-level ROI score.”
And so on.
Notice that we’re reaching for different parts of the overall product cycle and planning information. Curating it for each audience. Delivering news to that people can grasp and use and need. I could blather for hours (days, weeks) about what I want the world to care about, but that’s like building a product only because I'd be excited to buy it.
Sound Byte
An essential skill of product managers (and other cross-organizational roles) is to identify our different audiences and what those audiences believe they need to know. Then identify our own goals, structure the right kind of meeting, and communicate clearly in (their) appropriate language. We must learn to code-switch.