Let’s Fire a Few of Our Customers

As product managers, we worry about market results – not just successfully shipping stuff on time, but growing our product’s revenue, user base and engagement. More is better, and much more is much better. Up and to the right!

In the enterprise space, sales are lumpy and a couple of deals may represent most of this quarter’s new revenue. So every prospect is strategic. We go the extra parsec on every opportunity; we see each proposal as a must-win. We’ve never met revenue that we didn’t want, and any technical challenge can be solved with a one-off fix. After all, there aren’t enough F2000 companies that we can chance losing even one to fussy product concerns.

But not all customers are created equal. At many enterprise software companies, I see one or two outlier customers consuming an inordinate share of support time, product management attention, engineering cycles and roadmap focus – hugely out of proportion to their actual revenue or market value. Maybe we should fire just those two, and free up scarce resources for dozens of more relevant customers.

Pareto analysis implies that 20% of our customers generate 80% of our profits. Philip Kotler suggests an even more unbalanced mix: that our top 10% of customers represent 150% of profits, and our bottom 10% account for minus 100% of total profit. (In other words, firing the right 10% of our current customers would double profitability!)

Read that last sentence again if you missed the plus/minus signs. Then read it aloud to your CFO.

These models are simplistic, of course, and our situation will always vary. Kotler was mostly referencing physical consumer goods, not software, and different economics apply. Directionally, though, this is a very powerful concept: some of our customers make negative profit contributions. And it runs counter to how most companies think about revenue and pay sales commissions.

Aren’t They All Just “Customers”?

Imagine sorting our current customers and hot prospects into a few buckets:

Happy Customers, Targeted Use Cases/Segments. These folks are enthusiastically using our product in one of our top few use cases or value scenarios. (Not sure which your intended use cases are? Look above the

fold on your home page to see what you’re telling the world.) Our best customers are generally getting value in ways we expected, applying our product pretty much as suggested, and might be sales references for new prospects. They are the customers we beg to speak at industry conferences.

Not So Happy Customers, Targeted Use Cases/Segments. Some customers are trying to use our stuff as planned, but not finding the value/engagement/love that we’d hoped. Onboarding is bumpy, or configuration is tough, or we’ve added too many features and users suffer from cognitive overload. These are the customers we have to make happy if we’re going to grow our revenue/brand/Net Promoter Score and shorten our mean-time-to-customer-joy. Product Management and UX/Design and Engineering should be following these folks around – interrogating them as necessary – to figure out ways to get the job done more easily. Let’s figure out if this is a technical problem, or workflow design problem, or pricing problem, or sales channel problem, or falling behind some key competitive feature, or whatever. We need to get them to group #1 above, or die trying.
Smart customers finding interesting not-as-expected applications. These are the trailblazer customers who are just a little smarter than we are, but still sane. They’ve used our product to solve an adjacent problem that they (and we) think is interesting and reasonable. (“Wow! I hadn’t thought of that, but it makes perfect sense that our grammar checker application could be used to grade job applicants on their writing skills.”) We suspect that our tech reasonably fits this new problem, that customers won’t get in too much trouble with it, that their systems fit our architecture, and that this is big enough niche to be worth evaluating for repeatable solutions. Let’s debate whether we’re yet staffed and ready to take on nearby problems.
Over-eager prospects trying awkward, unintuitive, failure-laden uses for our product. These make us physically uncomfortable: unfamiliar customers trying to force-fit our solution into complex new situations; prospects demanding references in an industry segment that we don’t understand; sales teams with a shopping cart full of surprise checklist requirements; head-scratching system architectures with obscure data flows. (“They could use our grammar checker to parse real-time conversations with airline pilots in order to identify training or security issues. Of course, we’ll need it to get FAA approval, find a couple of airline reference customers, port it to Airbus’ FlightOS, adjust for national/regional speech patterns, switch from batch to real-time processing, secure it to meet DOD 8500.01E and author new training/installation documents. But this is a huge opportunity and the customer really thinks we are a perfect fit.”)

Notice right away that #3 and #4 above may look the same to the outside world. (“Innovative customers push us out of our comfort zone and find ways to expand our market. All innovation is good, and all customer ideas are valuable.”) But as product leaders, we have to apply our own best judgment, experience and general spidey-sense to avoid the quicksand of solution overreach. We need to think about segments, not just individual deals. We know that resources and attention are limited. We remember that “give every customer more of everything they want” isn’t a practical approach.

Which Specific Customer Are We Talking About?

Our company might have one or two current customers lurching toward failure in category 4, and perhaps one big prospect in the deal pipeline. If so, everyone knows these specific deals by name, and there’s already hand-wringing or frustration being voiced quietly in the hallways. Listen for:

“What were we thinking? Who agreed to these requirements? I thought we turned this down in January because it won’t fit into our services architecture.”
“We’ve formed a task force with Product Management, Program Management, Engineering, Sales, Professional Services and Support to figure out what the customer actually needs. Bi-weekly meetings, authority to drop committed roadmap items. Our contract specifies hard deliverables in 60 days. Just give them what they ask for.”
“This is a fixed-price contract for less than our all-in engineering cost, but we can earn back the investment if we can just find 10 more customers that need exactly the same functionality. It’s a market we should pursue.”

In other words, we’ve been over-investing in a questionable opportunity, and haven’t found a way to get to NO. This investment is often invisible to the execs – it doesn’t show up on financial reports or quarterly goals. Instead, this has metastasized into a corporate commitment with too many players and a hugely expensive treatment plan. Best case, we have an awkward status report when the product team reports lack of progress on previously committed roadmap items.

Too Hot to Touch?

The phrase “internal politics” should have popped into your head ten paragraphs ago. Our sales team gets paid to bring in individual deals – huge ones, if possible – and Finance has probably forecast this one into next quarter’s revenue. It’s rare for sales teams to work a big opportunity for a year, then shrug and walk away because product management doesn’t like the details.
(BTW, let’s never disrespect or belittle our sales organization. We hire, pay, promote and celebrate salespeople who refuse to take “no” for an answer. And selling is hard, in a different way than engineering and product management are hard. Probably why great salespeople make twice what we do…)

If you’re the VP Products, CPO or Director of Product Management, this is a chance to earn your stripes. To show leadership on an unpopular topic, to say out loud what others need to hear, to act for the greater good. To show by example that trade-offs are hard and resources are limited. To be a hero for all of your other customers who need what’s already on the roadmap. (If you work for the VP/CPO/Director of Product, please talk this through with her behind closed doors before doing anything on your own.)

We expect significant push-back from our account team. So let’s do some executive-level coalition-building, helping our peers identify critical trade-offs:

The VP Support, whose team is ignoring escalations from core customers in order to staff this task force
The VP Engineering, who may slip our major quarterly update as developers are pulled from planned work. Or who may have to subvert our product architecture. BTW, there’s already grumbling in the engineering ranks about throw-away projects and management’s inability to stick with a plan.
The CFO, who is worrying about revenue recognition and margin. If our one-off custom development doesn’t perform (or we can’t book revenue until the deployment is ‘live’), we may have an earnings issue.
The VP Marketing, who sees customer dissatisfaction reflected in social media. Core users are tweeting indignantly about mainstream features, yet we’re diverting effort to a likely-unsuccessful, never-referenceable customer.
The VP Sales, who should be thinking about maximizing medium-term revenue across all sales teams, and not consuming precious technical resources on just one deal. In order to satisfy demands from this outlier, we’re stealing other pre-sales technical resources and risking credibility on earlier commitments.

Frame Our Most Critical OR Choice

Note that we’re thoughtfully framing an argument about EXCLUSIVE OR resource decisions in every department. IF we expend extraordinary effort for this outlier opportunity, which is likely to fail and embarrass all of us, THEN we necessarily divert time and attention from existing customers and targeted prospects and most-often-requested features. There’s no pool of idle people to assign: an all-hands-on-deck effort inevitably means letting other things slip. Presenting clear trade-offs helps the executive team avoid magical thinking – the fiction that we can always squeeze just one more thing out of Development.

Take the Lead with the Customer

Once we’ve sold the idea of firing a customer internally, we have two other big tasks: designing an equitable “out” for the customer/prospect, and having an uncomfortable discussion with them. I expect product management to lead on both.

If we want to walk away from an agreement or promise, what do we reasonably owe the customer? Remember, our internal motivation is to avoid a long slog toward product failure and public embarrassment – so that we can redeploy our scarce talent toward generating revenue elsewhere. We’re not trying to minimize disengagement costs: we do want to treat them fairly.

If the deal is still in the selling cycle and we haven’t taken any money, then we can withdraw our proposal or otherwise drop out. Maybe also suggest products/services that would serve the customer better, or offer architectural insights, or recommend trusted third parties who build custom solutions, or introduce them to CIOs who thoughtfully solved similar problems. Here’s our chance to provide real help.

If we’ve already cashed the check, unwinding our relationship could be more complicated. Refund some or all of their fees? Export their data and help migrate to an alternate platform? Offer discounted licenses to other related products of ours? This won’t be a win for anyone, but all parties should walk away on speaking terms. At this stage, we’re minimizing the damage to our reputation.

And if I’m the most senior member of the product management team, I should be willing to lead the discussion with the customer. Humbly, honestly, respectfully. A few months back, I led a series of such customer calls, and opened each call with “I’m disappointed that our product isn’t meeting your needs.” They had been telling us this for months, but were surprised to hear us repeat it back. Clearing the air, we were able to discuss options and fallbacks. Ultimately, they thanked us for not pushing a solution that would have embarrassed everyone.

Internally, a big sigh of relief plus a round of applause from Engineering. A clearer focus on customers that we can help. And demonstration that the executive team thinks strategically.

Sound Byte

Outlier customers misapplying our products can waste tremendous amounts of time and attention. Sometimes, we have to fire one or two to serve our core customer well.