The Chocolate Cake Problem

Richard Mironov -

In my experience, there’s usually a fundamental misalignment between two broad groups at software companies – especially B2B/enterprise companies — that I’ve been thinking/writing for a while.  One group (sales, implementation/customer success, professional services, account-based marketing) is trained and paid and rewarded to focus on one customer at a time, with current-quarter timelines. Get it done, and move on.
The other group (product, engineering, design, long-term support, product marketing) is trained and paid and rewarded to focus on overall impact for the whole installed base, long-term investments, and the need to support every line of code that any user has in production.  In aggregate, how many different customers will use the same exact bits to do X?  What will incent large numbers of customers to upgrade or renew?

On either side, it’s easy to assume bad intent or have this get personal.  Almost every (non-engineer) CEO I talk with tells me that their development team needs to be much more productive – or is lazy – and their product managers are unresponsive or don’t understand the business.  I hear this every day, in every sector, at every stage of growth.  So there must be something more systemic happening: all engineers and product managers and designers can’t be congenitally lazy or inattentive or financially illiterate.  (Hint: replacing everyone on those teams doesn’t seem to fix the problem.)

Likewise, I constantly hear from engineering and product teams that their (enterprise) sales and implementation/success teams don’t care about long-term costs or implications.  That they have the attention spans of squirrels, ignoring or forgetting existing commitments and agreed-upon customer targets and roadmaps.  That each week they leave a fresh gift (💩) for the tech side to clean up – displacing whatever was planned.  
But if we see this as a systemic problem, it can be less about individuals...  more about roles and timelines and executive-level incentives.

What Does That Have To Do With Chocolate Cake?

Imagine that in the morning, you set out a chocolate cake on your kitchen counter.  (And have some teenagers in the house.)  Somehow, mysteriously but inevitably, the entire cake is gone by the end of the day.  How does this happen?  One very tiny bite at a time. Each time one of us walks past, we grab a fork and have just a nibble, a crumb, a quarter-forkful.  We don’t count each smidgen, and rarely remember how many tastes we’ve taken.  But by dinner time, the plate is empty and our intended dessert is gone.

And just like our chocolate cake, it’s easy to miss the overall impact of “just one more thing” and “this one is small” and “we won’t make a habit of doing this” and “we’ll figure out a support plan later.”

Let’s dig in, starting with the account-at-a-time worldview.

Enterprise Sales teams (among others) see the world mostly as independent transactions: they work on only a few opportunities at a time, close them, celebrate, and move to the next.  They expect most customers to have some unique needs, and they fit products to customers – rather than vice versa.  When prospects say they need something, sales teams mostly take them at their word. Deep dives into obscure technical requirements isn’t the fastest path to a signature.

Similarly, Implementation or Customer Success teams are tasked with getting this particular customer deployed with the least time/effort.  By definition, the standard product isn’t sufficient, or the customer would already be in production – so implementation usually includes custom integrations, clever configurations, and creative twists on what features were designed to do.  Then, as quickly as possible, the team shifts to the next post-sale implementation.   Engineering-grade testing and code re-use are often discussed but almost never put in place.  And there’s no ongoing maintenance without a separate service contract.

From this side, we see the world one account at a time.  Sequentially, separately, quickly.  Our sales-side metrics and compensation systems encourage us not to worry about long-term burdens on other departments.  Coffee is for closers; third prize you’re fired.

Given the urgency to sign deals, implement, and move on… it’s typical for the account-at-a-time part of the organization to discount or ignore concerns raised by product/engineering (voiced by Sheldon Cooper) such as:

  • “Engineering is already overcommitted.  There’s no slack or excess capacity.”
  • “This new thing is less important than our committed/announced roadmap items”
  • “The product wasn’t designed to do that”
  • “It probably won’t work.  Your customer will be unhappy later”
  • “This incurs major technical debt”
  • “We’ll have to support that forever, even for this one user.”

Notice that these are all longer-term problems/costs which don’t relieve the pressure to close this deal right now, then get this customer into production ASAP, then move on.  The easiest responses are “you’ll figure it out” or “we can handle any issues later.”  Structurally, sales and implementation groups are rewarded for tuning out technical naysayers and parking problems with engineering.

Back to our chocolate cake, each CEO escalation and minor enhancement and workaround and customer-specific architectural review and “can’t we just extend the API slightly” is another nibble.  At the end of the quarter, we wonder why so few planned roadmap items were shipped.  Where did our engineering effort go?

Now let’s tell the story from a product/engineering worldview, emphasizing overall impact on the whole installed base, long-term investments, and cumulative commitments.

Product management is tasked with delivering products that many customers will buy as-is: identical bits, packaged for standard delivery, self-configured, with as little custom services or handholding or variations as possible.  The way software product companies make money is to build once, then sell those identical bits thousands of times with minimal human assistance.  Product managers know there is never any excess capacity in Engineering, so any new item must necessarily displace something already committed.  
And hard-won experience tells them that most customer requests are incomplete, poorly articulated, mis-architected, or just plain wrong.  Building exactly what (individual) big customers demand is a quick route to product/market failure.

Engineering carries the burden of supporting every line of code running at any paying customer –  which includes one-time work by implementation teams.  (When BigCorp’s CEO calls our CEO about an outage, it lands in our CTO’s drop-everything-and-fix-this-right-now-or-else queue even if core development group has never seen it.)   Designing for all possible use cases is impossible, so good software is architected for a short list of specific purposes.  And since each new feature adds complexity/surface area/test cases to the code base, there’s constant pressure to remove rarely used functionality.

There’s a collective focus on “how many” rather than “how much:”  are there 20 or 200 or 2000 different customers needing this particular improvement?  There’s also the sense that major deals appear and disappear (and appear and disappear) from the sales pipeline faster than we can thoughtfully build what each demands.  So there’s a strong tendency to discount or ignore the concerns raised by sales/implementation (voiced by Don Draper) such as:

• “This is a huge revenue opportunity”
• “Can’t be hard to implement… probably 10 lines of code”
• “There are lots of other customers who want this”
• “Don’t worry… they won’t really use that feature”
• “We won’t need ongoing support"

Sales’ overwhelming incentive to get to YES, expertise at escalating issues, and short-term reward structure mean that product/engineering is deeply skeptical of every claim.  And there’s absolute clarity about who is left holding the bits when it goes pear-shaped.  (Cassandra who was probably a product manager.)

In the background, our Board may be having similar arguments.  Longer-horizon SaaS-native investors may value license revenue at 6x-15x and services revenue at < 1x, so push-push-push for more frictionless deals and no specials.  Investors looking to flip the company within 18 months will push-push-push for top-line revenue growth even if it accumulates huge technical debt, since the new owners will bear the cost.  Different investment recipes, different cakes.

What Does This Look Like In Practice?

It may sound theoretical, or touchy-feely, but I see this fundamental misalignment creating real-world problems almost every day.  A few instances:

  1. Enhancement requests.  If we live in the account-at-a-time world, we assume that customer-driven feature requests are routine, urgent, and almost always approved.  Why bother filling out forms and justifying work, just to be told NO?  Sales brings in the revenue, and Customer Success delivers working systems.  We know what we need: just get it done.  

    In the aggregate-long-term-impact world, the cumulative demand for new features is typically 20x-40x our entire engineering capacity (not 20%-40%), so we’d have to reject 95%+ of all incoming requests even if we had nothing on our publicly committed roadmap.  Given that most items are really for a single customer and probably wrong solutions to misdiagnosed problems, our first instinct is to reject the whole lot and shut down the queue.  (See Why Product Request SLAs Fail.)  But that’s politically unfeasible. The two sides end up arguing about processes and responsiveness, neither of which is the real root issue.

  2. Cloud Migrations.  Moving a customer base from on-premise to multitenant SaaS is a long, complex, painful process.  Investors want it, operational and support teams scream for it, and there are big payoffs when the very last on-prem customer retires the very last supported copy of our on-prem software (See Major Migrations Are An Organizational Challenge.)  That’s when we can finally move our engineers onto something more modern.

    This is a slow-moving game, with product managers fighting for C-level agreement to formally announce an end-of-support date 2+ years away, sending monthly reminders to every remaining on-prem customer, and relentlessly dogging internal groups.  Long timelines, cumulative impact, most benefits at the very end.

    There are always laggards, though, and customers who are unexcited about change.  Our account-facing teams experience this personally: major buyers who want to stay on Version-Minus-20; customers with unique old integrations that don’t fit the cloud; security audits to rerun; user training and workflows which need updating.  At the account level, enterprises aren’t excited to migrate or change.  So sales teams escalate requests from just a few of our biggest customers to postpone or delay or get special dispensation to keep running on premise for a few more years.

    How will your CEO react when GiganticCorp demands a 6-month delay?  (And then another?)  Notice that we’re trading off one customer’s expected happiness against engineering/product focus and productivity and morale.  If we’re not really serious about 100% end-of-support for on-prem, let’s instead agree that we’ll have massive product sprawl and not go through the EOL motions.  A few more nibbles of the cake.

  3. The Sales-Led Roadmap.  Regardless of intentions, I see sales-led organizations quickly turn into development-for-hire shops.  We tell ourselves stories about how the world’s two largest banks (or airlines or healthcare systems or governments) have the same needs as the next hundred, but I’ve never seen it play out that way.  Old infrastructure, handcrafted CRMs, wildly inventive compliance workflows, dirty data, partially outsourced app development, on-prem-here plus on-prem-there plus single-tenant hosting plus five kinds of VMs… our largest customer’s architectures are archeological sites. Building for them doesn’t allow much re-use.

    The technical side dutifully creates a roadmap each quarter, but it's co-opted within a few weeks – major new deals crowd out everything else.  (These are whole slices of cake, not just nibbles.)  We don’t finish what we planned, and credibility plummets alongside enthusiasm.  Engineering falls into an order-taking mode. Product management becomes a revolving door, since the organization really wants proJECT managers instead.

OK, So What Do We Do?

I see this as a behavioral challenge for organizations, starting in the C-Suite, not a procedural problem.  It’s about who’s in the room where it happens and how we make decisions.  About managing our collective appetite for chocolate cake.  So ticketing systems or business case templates or replacing the entire product management team won’t address the root issue: who decides, and how do we create a balance between strongly competing goals?

Here are some partial strategies:

  • Recognize this dynamic as fundamental and systematic — at least for enterprise software.   An ongoing source of tension and conflict, not just one person’s “personality fit” or “work ethic” problem.  We’re highlighting hard trade-offs and gray areas
  • Try to assume good intent on both sides.  Labeling our coworkers as lazy or greedy or unmotivated or short-sighted isn’t helpful.  If we can see this as a pattern across companies, we can stop demonizing the folks across the aisle from us
  • Have very visible C-level scorekeeping for sales-led specials.  If we set aside 40 engineer-hours (or 200 story points or whatever) each quarter for the most important deal, we should expect every sales team to claim that same allocation.  Each team turns out to have the biggest opportunity.  Too many forks, not enough cake.
    Here's a chance to partner with the CRO/VP Sales around scarcity: consolidating assorted demands from their various teams, since the CRO is rewarded for maximizing company-wide revenue.  I like to create a real physical token (plush toy or “magic bullet” shell casing) that they have to hand over to the CPO when making this quarter’s request… and therefore can’t use it again or claim to have forgotten.
  • Talk in detail about how your organization makes money, specifically around services versus packaged products.  I see this as the most critical choice we make, consciously or otherwise.  What do we (and our investors) want more of/less of?  Will a mountain of tech dept and product sprawl and unsupported code hurt our exit strategy?
  • Look hard at compensation plans.  If selling custom work to clients is easier than selling our out-of-the-box product (which it is!) and we pay the same commission rate for custom work as for SaaS licenses, we’ll sell a lot of custom work.  (Hint: sales teams do what we pay them to do, not what we want them to do.)  Imagine 120% quota relief for our absolutely-standard-vanilla-uncustomized-touchless packaged product and 5% on services.
    Likewise if we create an implementation/professional services team and reward them for billable hours, we can’t be surprised when incoming projects drive ever-increasing implementation staffing.  We have to align market-side incentives with corporate-level goals.
  • Partner your product company with a professional service company (or vice versa).  If we train up an external consulting group on our API and architecture and implementation model, we can then toss that work to folks who want it.  And we can recognize license revenue right away.  And we have incentives to reduce how much implementation/handholding/customization/specials our products require – since we’re no longer losing services revenue and can focus on scaling up sales.

Sound Byte

We want to have our cake and eat it too.  But short-term choices eventually add up, at the expense of longer-term choices.  Lots of nibbles now or a few big product slices later.  The frustration/friction between single-account-focused groups and aggregate-installed-base-focused groups can look like personal disagreements or lack of motivation, but are really burden-shifting between sales/implementation teams and engineering/product teams.  Especially at the leadership level, this calls for more empathy, pattern recognition, and cross-functional goal alignment.

This post comes out of a March talk at the Business of Software conference.  My thanks for their long-time support and encouragement.