As product managers, we’re trained to talk about benefits with customers/ prospects rather than features. How will this product help you, rather than how does this product work? Second nature.
But we (product leaders) often engage our C-level peers in development process discussions about why they can’t have exactly what they asked for, exactly when they’d like it. We talk inside baseball. We’re in “teaching” mode about sprints and business cases and backlogs and test criteria and technical debt and why the roadmap is 120% full.
[Have you ever been at a cocktail party and been trapped in a corner by rabid golf enthusiast, who lectures about players and courses and leader boards for 30 of the longest minutes of your life? That’s what so much of our product-side discussion sounds like to someone who’s not very interested in “how I built this.”]
Instead, we should be applying our product skills to understanding what matters to our C-level partners, and using that to build executive coalitions around key issues. Think of it as corporate anthropology rather than decision-making algorithms.
A Typical B2B/Enterprise Example…
Various B2B sales teams skip over product/engineering when they need something special/unique/bespoke for their biggest customers. Everyone on the go-to-market side has heard the CPO’s lecture about processes, analysis, justification, building what the larger market wants… and they are tired of listening to it. Product-side leaders are not getting their message through, especially since enterprise account teams know that they can escalate this week’s “only just this once, will never happen again, huge revenue, how hard could it be?” item to the C-Suite to override product objections. (And get paid handsomely for it!)
Sales is paid to get to yes, and identifying how to get prospects there. (Shockingly, they apply the same techniques internally, figuring out who will say yes.) And product/technical leads are often not in the room where it happens, or don’t have strong-enough voices to slow deals down for a bit of in(tro)spection. Thus the need for a coalition: other execs who could be persuaded in advance that most one-off demands are bad for the health of the company.
We can easily fall into lecture mode, “schooling” coworkers in excruciating detail about tech debt, development leverage, and how implementation/tiger teams leave deployed-but-un-QA’d code for someone else to support when they move to the next urgent “only just this once” project. How do we market the benefits of a single codeline that every customer uses? We need to understand departmental goals, metrics, success criteria.
- CFO/Finance: “You know that our investors value SaaS subscriptions at 6x-10x revenue, and one-time project work at 0.5x revenue, because that’s what the IPO/M&A values. So every dollar from our unmodified multi-tenant code line is worth 12x to 20x more than a dollar of one-off custom work. I know that you want to retire to Fiji at the end of our post-IPO lockup period… but every single-customer project delays that. Can I get your support the next time GiganticCorp demands something we don’t have?”
- CMO/Marketing: “Every quarter, you’re judged on MQLs… and how they convert to SQLs. And you’re appropriately all over Product and Engineering to deliver exciting new features every quarter to draw in fresh prospects. But the #1 reason we’re late on shiny tech is that we keep pulling teams off of committed work. Green-lighting another one-off for HugeCo means slipping something that your team is waiting for – to drive top-of-funnel and deliver more MQLs. The next time this comes up in E-Staff, could you ask what we’re postponing in order to free up people for HugeCo? That may reduce end-of-quarter blame shifting when Sales criticizes your lead quality.”
- Support: “I know that your team gets pummeled by our biggest customers (and therefore by Sales) when custom connectors or bespoke workflows stop working. Always on a weekend. And that you’re lacking key support inputs: docs, training, a repeatable test suite, help from the tiger team/implementation folks who built it. (They’ve moved on to the next project, or are no longer here, and no one in Engineering has ever seen that code.) The next time something similar is raised in E-Staff, could you cite a couple of ugly examples where we’ve gotten made-to-order egg on our faces?”
If we’re successful in coalition-building, there will be other voices round the exec table raising concerns about the next proposed roadmap interruption – before it’s approved. And we do that by identifying what’s important to each individual – in their words, based on their departmental challenges and metrics – just as we would for a commercial product. More Dale Carnegie, less Sheldon Cooper. More “no substitutions on the menu” and less “here’s why substituting ground beef for tofu in our veggie casserole, just this once, will create chaos in the kitchen and p**s off the chef.” More “here’s what’s in it for you” and less “here’s what I need.”
Sound Byte
Bottom-up data analytics and “derive from first strategic principles” arguments often work with our maker teams, but usually aren’t as effective with market-facing groups. We need to adopt different discussion styles and supporting evidence depending on our audience. And that may include “how will that help us?” or “what’s in it for my department?” narratives.