Lying To Customers

I have a narrow, somewhat puritanical view about product manager conversations with customers and prospects: we should never lie to them. That might seem obvious or naïve, but recent conversations with several B2B/enterprise clients suggest that it’s actually controversial.

For context, enterprise tech companies tend to have a small number of large deals each quarter that really matter. (B2B is lumpier than B2C.). These are complex deals on the customer side with buying committees, unique integration requirements, internal champions for each competing vendor, and reputational risk for choosing the wrong product. On our side, we have expensive/talented/experienced sales teams that either close their few big deals this quarter or are put on notice. So there’s tremendous pressure to shade the precise facts (just a little) and land those major deals.

Product managers are often called in late in the selling cycle to address specific customer demands/requests or to position our product against competitors. Roadmaps are shared. Demos are shown. Unscripted Q&As happen. While we don’t know everything that’s been said during a 3-or-6-or-9 month sales effort, good sales teams will have briefed us on hot topics. It’s our job to answer those few issues and then step aside to let the selling continue.

We’re often asked to “position” an upcoming feature, or avoid mentioning a product shortcoming. Or promise an enhancement that’s not actually in plan. Or support a deeply fictional story about some magical AI capability that will instantly solve the customer’s bizarre situation. It can get murky deciding how far we should stretch what we say.

Why Does It Matter?

At some companies, brutally honest communication with customers is assumed, and reinforced by the executive team. At other companies, exaggeration is a cultural norm. Fussy product managers unwilling to follow their executives’ lead are sidelined or let go.

Aside from my finicky moralizing, here’s why I care:

We’re going to be working with this specific enterprise customer for a long time. They are probably smart enough to discover what we misrepresented, and force us to meet our commitment. Expect account-level distrust, bad blood, and a search for who’s to blame.
Sales teams learn from each other what’s acceptable, so there will be dozens of other untracked, unsized, unplanned, poorly defined promises that somehow surprise the development/product team. Each promise eventually creates its own bit of chaos: escalations, account reviews, executive interventions, demands for quick fixes to hard problems. Collectively, these crowd out what we actually planned for the quarter – putting us further behind on the few initiatives that would really matter. I see this as the #1 reason why enterprise engineering teams are viewed as unproductive.
Many of these unscrubbed demands or requirements are just plain wrong: confusion about root causes, ham-handed UX changes, interference with current features, privacy or legal violations, misguided workarounds. If we do exactly what each customer asks, we often make things worse.
Product managers thrive in a culture of honesty: we walk away from punitive or politicized organizations. After all, we have no actual authority — only moral authority and cross-functional trust. Our word is our bond. I’ve seen a dozen companies hemorrhage product managers (and developers and designers and support teams) when those folks decide they can’t do their best work.

So lying to customers is more than just bad form: it is also bad business.

All well and good, but there’s a lot of gray space between literal product truth and science fiction. Each company’s situation is unique, so here are some buckets.

Appropriate

We’re not robotic brochure-readers, and we really do want our products to sell. Much of our work is around positioning, finding good problem/solution fit, and helping customers succeed. So I don’t have any queasiness around:

Emphasizing the positive. “The real value of our forecasting product is in its filtering, where we dramatically outperform the market. Import/export is generic: we’re just as good — but no better than — similar products on that.” Point prospects toward our strengths.
Depositioning the competition. “While some security scanning products claim to detect a very long list of attacks, you’ll want to test that they truly can stop the top 6 or 8 threats first. Here are some independent test labs that have published their findings…” Especially if you know that competitors are over-hyping their own products, reference a less biased expert to prove your case.
Say we’re working on something (if that’s true). “We’ve done some design and technical architecture work on Z, and expect to get it scheduled in the next few quarters.” Be prepared for this prospect to ask for updates, a look at mock-ups, or to be a beta user.
Say that we’ll look into a feature. “We’ve had other requests for, so that’s on my candidate list for later this year.” That’s not a promise to DO it, but to CONSIDER it. Words matter.
Potential end-of-support. “We’ve talked about sunsetting this product, but haven’t made a decision. We’ve always given customers formal notification and two years’ continued support when replacing a product, so there would be plenty of time for migration planning if we made that decision.” A promise to treat them equitably.

Enterprise customers are sophisticated and (mostly) know how to listen to vendors. Treat them like adults, build a long-term relationship.

On The Margin

This will vary by company and product and lifecycle and situation, but be careful with…

“That ships late next month.” Building software is always uncertain, even if we’re close. Dates and delivery mostly move out, not in. So I like moderating phrases: “assuming we get through final testing as planned” or “that’s part of the larger v6.4 release train” or “we can get you the draft user docs right now, but those will probably change during internal UAT”.
“We’re the best in the market.” I prefer Marketing and Sales to own superlatives. We could instead be semi-quantitative with “our user base doubled over last year, so we’re growing much faster than the market” or “we scale 3x better than competitors, which you told me is crucial” or “8 months without an outage, even better than our 99.95% uptime SLA.”
“This upgrade will be painless.” Really? If we’re that sure, I’d prefer “I don’t think you’ll need to, but call me if there are any issues.”

We’re not just trying to address the issue at hand, but also setting good expectations.

Over The Line

It’s hard for individual product managers to push back when asked to mislead: they often lack the clout or political capital to say NO when an enterprise deal is at risk. So I frame this as a leadership challenge: how do we (as product leaders) let our product managers know what’s acceptable, and that we’ll intervene when needed? How do we help the rest of the executive team visualize the frequency, impact and accumulated chaos from lots of unvetted commitments? How do we help re-shape company culture?

I get my product team’s attention by saying that I’ll summarily fire any product manager who does the following:

Claim a feature exists that doesn’t (yet). “No problem: we have our Salesforce integration shipping, and a handful of other customers are using it.” If that’s a far-off future item, then we’ve more than embarrassed ourselves – we’ve created a cascade of demands for proof items from the customer. Even though it’s not designed yet, can we whip up a UX mockup? A video of someone pretending to upload data? A fabricated installation guide? A link to our salesforce partner listing? Names of imaginary customer references? This gets bad fast, very predictably. And fuels a cross-functional blame cycle.
Agree to a feature in real time, during a customer meeting, without engineering input or impact analysis. “That shouldn’t be hard. I can get it to you by Friday.” Unless we already know how to implement it or absolutely know it doesn’t require any development/design cycles, this is a big mistake. Otherwise, we sacrifice the trust of our development team. And may be forced to delay something already underway. And become just another creator of promise-first chaos – priorities be damned.
Trash-talk a competitor in public. If we have real ammunition, let’s give it to our marketing/sales teams and channel partners to share – long before we personally meet a prospect. If it’s irrelevant or flat-out untrue, we’ll lose customer trust when that becomes apparent. Product managers need some gravitas, some decorum, a way to remind customers that we have a longer-term commitment than just the current quarter’s revenue. We should sound more objective than we are.
Trash-talk our development team in front of customers or Sales. We have to be should-to-shoulder with our engineers and designers, especially in public. Disagreements and criticism are shared privately, respectfully, constructively. (We build and maintain trust.) So any product manager who dishes with customers that “I’d have this done already if my developers weren’t so lazy” wins a free résumé update.

As product managers, our words and our behavior matter. We represent the company beyond the current quarter, just as we nurture our products beyond the current release. Integrity, trust, and the long game are important. This is one place where personal honesty lines up nicely with job requirements.

Sound Byte

Product managers are the spokespeople for our products, our teams, our companies, our commitments, our culture. Quoting Warren Buffett, “It takes 20 years to build a reputation and five minutes to ruin it.”