Lately, I’ve been writing a lot about entirely predictable goal misalignments between the maker side (product, engineering, design) and the go-to-market side (sales, marketing, customer success) of tech firms, especially at B2B/enterprise software companies. That includes short-versus-long-term tradeoffs and single-account versus cumulative impact focus. This post lays out a related challenge: finding a scalable way for product management to support sales organizations rather than individual sales opportunities.
The dueling complaints are:
- Sales: “Product never seems to get us the right information at the right time in enough detail that we can confidently answer our customers’ questions. Info is too general, too hard to find, usually out of date, and buried in technical jargon, and getting follow-up responses takes weeks. (Or forever.) Product isn’t helping us close major deals and bring in revenue.”
- Product: “We’re endlessly creating and updating demos, decks, product bulletins, release dates/roadmaps, FAQs, technical docs, checklists, cheat sheets -- but Sales hardly uses any of them, and still expresses deep frustration with us. Sales teams inundate us with urgent-but-repetitive ‘does product X do thing Y?’ questions that lack context, and expect 15-minute responses. Deal support is <5% of our job, but we could spend full time on this and still not satisfy them.”
Since this issue comes up with most of my CPO coachees and clients, it can’t just be about a few inattentive product folks or lazy salespeople. There’s something more systematic here.
Let’s paint this misalignment in detail, exaggerated for emphasis.
[1] “Product Needs to Help Sales Close Major Deals”
Enterprise sales teams are paid, rewarded, promoted, and measured on closing individual (big) deals. So it’s natural for them to expect everyone else in the company to have an account-level focus. Their daily discussions are about the details, needs, personalities, organizational structures, political issues, RFP committees, company-specific acronyms, and executive-level fever dreams of a handful of opportunities. From their side, it’s obvious that every employee should be as dedicated to closing their few large deals as the sales team is. “BNP Paribas is the largest bank in France. We need product management on every technical call, demo, use case analysis, RFP review, architecture discussion, and pricing issue so that they deeply understand the context and specific use cases and can answer any product-specific questions. This is a must-close.”
As shocking as it is to Sales, enterprise product managers rarely focus on individual deals. Product gets up every morning to validate and build repeatable products that can be sold in quantity to large numbers of distinct customers. (With nearly identical implementations and use cases.) Product folks spend at least half of their time with their maker teams (product, engineering, design) trying to build and ship software that’s of broad interest to the market segment. Plus time with Marketing (launch, messaging, product marketing content), Finance (packaging, pricing, forecasts), Support, Customer Success/Implementation, and broad Sales training and enablement. Plus frequent updates on everything for the C-suite. So a product manager might have 5% of their time in total for deal-specific sales support.
At scale, most enterprise companies have 10-20+ people in the sales organization for every product manager. So the math would suggest <1% of a product manager for each salesperson’s top deal. Sales’ expectation that Product can track the unique details of 10-20 deals isn’t realistic. And go-to-market-side execs tend to demand product coverage on “just this one big opportunity” without noticing that such escalations happen daily rather than quarterly. (See the chocolate cake problem.)
Of course, it’s not that simple or clean. If we haven’t yet found product-market fit or are chasing the first 4 prospects for a new offering, product managers must be hand-in-glove with those sales teams. Or at a company with minimal sales staff, product managers often step far outside their comfort zones as stopgap account managers. Or our largest customer has a P1 disaster that crosses functional lines and needs someone deeply connected to sort it out. But in general, the math can’t work.
That sets up a fundamental misalignment between “we need all hands on deck to close this deal, especially product management” and “products need to drive the larger organization to define and build and support products that can be sold in volume.”
[2] “But We Explained All of This in Sales Training”
Product Managers often have a simplistic view of sales training, particularly for technically complex B2B/enterprise products. And naïve assumptions about Sales’ attention to (retention of) deep technical info during periodic updates. The traditional approach is to have semi-quarterly ‘data dump’ sessions where a parade of product managers each get 30 minutes in front of the entire sales force to explain and position their bits of the portfolio.
Product folks spend every day wrestling with their roadmaps, their maker teams, release codenames, APIs, price lists, packaging options, and complex sets of market/technical/revenue trade-offs. So it’s easy for them to imagine that the rest of the company tracks this as closely as they do... that the world cares deeply about the details... that everyone remembers precisely what’s been shared once. (Say something once, why say it again?) Would that it were so.
Most sales teams have pretty poor retention for complex technical information that’s not relevant to today’s calls. Fat decks; convoluted use cases; obscure technical qualifiers that aren’t important to winning hearts and minds; version numbers; scalability limits… not interesting until they come up in a live customer conversation and might block a deal. So bulk training may make Product feel good, but often isn’t effective. (And Product’s hope that Sales will locate and replay recordings — or flip through archived PPTs — is mostly delusional.)
[3] “Product Is Stuck In The Weeds”
Enterprise buyers (and therefore enterprise salespeople) want simple yes/no answers to seemingly simple yes/no questions. (“Do you integrate with SalesForce?”) Product managers want to be more accurate and more complete, so respond with 2-4 paragraphs of specifics and caveats. (“We’ve supported SalesForce’s Account Engagement API in our main platform since v10.4a, which lets customers synch marketing data. We’re adding support for SalesForce’s B2C Commerce API in our Avengers/Q4 release to allow ecommerce storefront integrations. Their Commerce Einstein API for AI/LMM is under consideration, but only in our Gold Enterprise package in Europe and North America. No plans for SalesForce’s Financial Services Cloud API…”)
We also see this in RFP responses. We answer YES on HugeCorp’s form asking “do you support multi-factor authentication?” but get caught in post-sale implementation when they interpret that as “out-of-the-box support for Thales SafeNet Trusted Access” rather than Okta or Ping or Auth0. During the selling cycle, we want to be as brief and upbeat as possible. But awkward and technically complex answers can sidestep issues later. It’s hard for product managers to guess when short-but-incomplete answers are more appropriate than long-and-jargony.
[4] “This info is old. We need to confirm everything again with Product.”
Building software is as much art as science. There's no truly committed schedule or perfect spec: we keep learning as we design systems, discover complexities, stumble, invite early users to rip apart beta releases. Our customers (and sales teams) uncover fascinatingly new use cases. Tech evolves, competitors respond, maker teams add or lose key people, corporate priorities oscillate. So we expect delivery plans to shift... mostly 'later' and 'without that planned minor feature.'
As well, the more content that Product creates for internal and external audiences, the more certain that a few bits are incorrect or incomplete. The bigger our stack of demos, presentations, product updates, roadmaps, tutorials, qualification checklists, RFP responses and testimonials, the more inevitable that something is outdated.
Sales teams hate this. They want stable, predictable, still-true-three-quarters-later information — especially since prospects jot down out-of-context conversations and squirrel away roadmaps, beating Sales up later if anything changes. ("You told us last March that we'd have Twitter API access by this November 15th.") One wrong answer is much more memorable than forty correct ones.
So the more content and updates that Product provides, the more likely that Sales becomes suspicious of this mountain of material. It's reasonable to want to re-check every assertion that's crucial to their specific deal. ("Last week's tech note mixed up multi-tenant and single-tenant. We can't trust what's in these docs. We need Product to review Gargantua LLC's whole deployment plan.")
Deeply frustrating to everyone on each side, and undercuts our shared goal of empowering sales teams to succeed without product managers directly working lots of deals.
So What Can We Do?
Situations and organizations differ wildly, but here are a few starting places.
[A] Don’t Make It Personal
I’ve seen nearly identical challenges at dozens of companies, so I strongly believe this is something structural. Punishing product managers, talking smack about Sales, or firing folks don’t fix the root issue. IMO, this is about roles, organizational empathy, and expectations around response times.
[B] Create Sales-Side Product Specialist Roles
Enterprise companies with complex products and board portfolios often have Field Sales Engineers or Regional Product Specialists or something similar: technical people who report into Sales, are assigned slices of the portfolio to represent, and may be attached to major accounts or territories. This gives product management a smaller, more engaged audience for monthly (or weekly or daily) updates… and sales management can decide how to focus their energy. If Sales decides it’s short of FSEs or RPSs to engage technically with key accounts, they can staff up.
This dramatically reduces the repetitive interrupt problem for product managers. Good FSEs/RPSs handle 90%+ of incoming questions, and point the rest to the right person. They are better attuned to product-speak and the pace of change. They grow trust and camaraderie on both sides.
[C] This is a Content Problem More Than a Tools Problem
Every company seems to have two (or eight or twenty-three) old product wikis and FAQ boards and repositories – abandoned after months of half-hearted updates, full of outdated stuff. So buying another Intranet server or blogging package or indexing product leaves us with yet another under-supported heap of random aging content. As soon as a few entries are found to be old or inaccurate, trust is lost – so users abandon this newest repository and revert to urgent slack/phone/email requests. Sales teams remember a single blunder for years.
That suggests the need for a product-knowledageable person to curate content and drive updates/refreshes. (Product Librarian?) Perhaps every item needs an expiration date, official owner (who is still at the company!), searchable tags, and a predictable place in an information hierarchy. Product managers might owe a twice-per-quarter update plus same-week on major changes.
If there’s a need to centralize RFP questions and responses, nominate someone in the Sales organization with deep product knowledge. Someone who knows that “multi-factor authentication” and “two-factor authentication” might be the same thing, and applies some judgment to copying answers. Leaving this as an unmanaged process or a purely clerical activity isn't helpful – the same questions will be passed through to product managers, in quadruplicate, with tiny variations – creating the same overload and lack of response that we already have.
(Generative AI may help here, if we trust it enough to risk seven-figure revenue on the answers being correct. Hallucinations can be costly, and LLMs tend to be trained on aging content.)
[D] Have a Serious Conversation Around ICPs and Use Cases
Product folks have the strange notion that an Ideal Customer Profile (ICP) means that we’ll only sell to enterprises that almost exactly match our ICP qualifiers. And that supported customer use cases have to match a limited list that we’ve tested or believe will work. Product managers think about excluding markets and limiting use cases so that they can focus on a few high-volume segments and deliver the same great UX to everyone. (“Our health information system is designed for independent small-to-medium providers based in English-speaking pay-for-service countries, and who don’t have major in-house IT… so we absolutely won’t be selling to huge networks or in Latin America or to integrators.”)
B2B sales team, of course, will always add a use case to our list if the customer wants it. (“Of course we can make that work. Sounds like a great application for our product. That will put ColossalCorp way ahead of its competition.”) And big prospects (in the wrong industry) get big attention. If the deal is sweet enough, product shortcomings are a product/engineering problem. And if we have an Implement/Customer Success team empowered to extend our base products to create semi-custom solutions, every opportunity is a chance to generate revenue.
One view or the other will win out. And the sales-led approach generates an endless set of hypotheticals: “could we build a connector to this 1970’s-era database, and what would that cost?” or “how hard would it be to add 4 more fields to our master item database?” or “can we back-port the new features in v12.0 and stick them into v10.4 for MegaBiz, which won’t migrate until 2031?” These exploratory requests demand lots of technical/customer investigation, frequent shuffling of previous commitments, and generally grind the development cycle to a halt — a stealthy way to hijack engineering resources.
So it’s important to have real, honest, unflinching discussions about how our executive team actually behaves when a shiny new deal appears – rather than a “we said, they said” slapfest as each new opportunity blows up the roadmap.
Sound Byte
Assuming that Product will behave the way Sales wants, or vice versa, isn’t a great starting place. And assigning personal blame usually isn’t helpful. Getting B2B sales teams product information (when they need it, at the right level of detail, across a large portfolio) is an organizational challenge for Sales and Product and others to solve together.