The Slippery Slope of Sales-Led Development

Most product companies have a few things in their roadmaps that are specifically for single customers – I call these sales one-offs. But it’s easy for B2B/enterprise companies to fall into a sales-led development model where the majority of work is for individual customers – starving the core product of innovation, new features, quality improvements and technical resilience. I’ve talked with dozens of software companies that don’t know how they got here, or don’t yet recognize the problem they have, so this post takes us stepwise from best intentions to “we’re too busy to improve our base product or take on new customers.”

The end result can be frustration, uninspiring products, falling profitability, and an inability to grow the business. Fixing it requires product management to help executives understand the collective impact many individual choices, so the organization can take clear action. Let’s dig in…

First, an important distinction of mine between product companies and professional services companies:
Product companies build packaged, standardized products that they can sell many, many times to many, many customers with little or no customization – which lets them sell each unit for substantially less than it costs to build. Product companies focus on getting to break-even volume, after which each incremental sale is 90%+ margin. (For instance, they can spend $8M/year providing $50k/year enterprise licenses as long as they get past their 160 customer break-even point.) Product companies try to engineer away labor-intensive onboarding and customization, and don’t support multiple back versions.
Professional services companies take on projects for individual clients, and price each engagement for profitability: cost plus 50% or 70% or 100% margin. Good estimation and busy technical team are the keys to success. Services companies make more money when clients want something special, or different, since they invoice for effort and thrive on change orders. Each customer may get unique software, and pays the full cost of supporting that unique stuff over time. Services firms often start — but rarely finish — building repeatable products, since they repeatedly pull their product teams off to work on new custom projects that generate immediate profits.

So I see product companies succeed by shipping standard products, and selling those identical bits many times to many customers. I see professional services companies succeed by bringing in custom projects and marking up their developers’ time. But sales-driven enterprise software companies often stumble into a mixed model: charging too-low product prices for semi-custom work that consumes more and more of their development team until they can’t support any new customers. And they don’t break even, since one-off work is funded out of license revenue.

This can happen incrementally, invisibly, with no one noticing the accumulated impact of many seemingly small one-off commitments on product roadmaps and overall engineering priorities. Said more colorfully, sales one-offs are crack cocaine: pleasure-inducing, habit-forming, and generating barely-plausible explanations of why every deal is the last one we’ll do custom work for.

At root, this is about product economics and the inability of sales-led product companies to scale up, even though it may be described as a contest between product folks and sales teams.

A big thought, with several steps. So let’s break this down into:

How product/engineering makes roadmap trade-offs
Describing one “special enterprise deal, which needs just this tiny thing”
The cumulative impact across customers and quarters
What to do?

[1] PRODUCT-LED ROADMAPPING AND PORTFOLIO TRADE-OFFS

Good product managers know that we can’t invest all of our ever-so-scarce development teams in only new features, or only quality improvements, or only user-facing design, or only retiring technical debt. We need to keep our products healthy with a mix of investment in each category.

Once we’ve found some product/market fit, our technical investment portfolio might look like this:

Half of our story points (or developer-weeks or whatever) might be spent on customer-visible new features, usability improvements, competitive responses, and other things that users/customers directly ask for.
A quarter might go toward core product infrastructure and so-called “-ilities”: availability, scalability, security, regulatory compliance, and things that our customers assume we do, but only ask about when we fail (e.g. running out of shopping cart capacity on Black Friday).
A scant quarter might be spent on bug fixes, test automation, DevOps, paying down technical debt, and other supporting work that keeps the software process running.
10% or more should be devoted to front-end customer interviews, product/market validation, Jobs To Be Done, prototype design and technical work to deeply understand user problems – and possible product solutions. Hidden in this slice is innovation, since we must make time to think through and test and discard lots of plausible ideas rather than just pick winners and move directly into full development.

Note that it’s already hard to fit all of this into 100%. (BTW, pie charts have the wonderful feature that we can’t make one slice larger without making another slice smaller. This helps us reduce magical thinking.)

And every slice has its own constituency that wants more than we can allocate:

Marketing and Sales want more shiny features to boost retention and entice new customers. They’ll happily have us spend 100% on visible improvements this quarter, with a promise that next quarter we’ll get back to a balanced plan. (Which never happens.)
Engineering sees technical risks and platform shortcomings first-hand, so pushes us to invest more in architecture, tooling and refactoring.
Customer Support lobbies us to fix more bugs, improve onboarding/usability, and catch problems earlier through better test automation.
Our executives push us to be more innovative, even if they don’t associate that with the hard work of turning vague suggestions into validated, development-worthy designs. It’s easy to describe innovation as an attitude or an event rather than an investment in experiments and ongoing market-informed processes.

So there’s never enough to satisfy any constituent group because the backlog of worthy improvements is infinitely deep.

We’re not sorting good from bad suggestions as much as we’re sorting “so good that they made our list of 5 best improvements for this quarter” from “16 other customer-facing things really make sense, but didn’t edge out our top 5.” We ask our support teams to help us choose 6 or 8 bugs from among the 37 they marked as P1. We negotiate with our architects to identify a few high-value platform investments even though our last retrospective identified dozens. And then we weave these different kinds of work into a single prioritized backlog. An embarrassment of opportunities meets always-finite resources…

So we product managers make hard choices, leaving most of our favorites for the nebulous future. Then we do our best to “sell” this near-term plan to our executives. (Feel free to call this artifact a 90-day roadmap if you like.) We’re usually a little bit optimistic about engineering capacity because we can’t bear to drop that last marginal item, so the odds of finishing it all might be 70%. We collaborate with our engineering teams build in a little slack to address uncertainty and anticipate change — not to save room for random management requests.

Recapping:

A healthy development plan has a mix of different kinds of work: customer-visible improvements, infrastructure, development automation, paying down technical debt, and intellectually honest validation. Investing only in new features is a high-sugar junk diet that quickly leads to unstable products and architectural tooth decay.
There’s no white space or unallocated effort. No daylight to slip in just one more thing. Instead, we’ve picked a few winners from a long list of attractive choices, leaving many of our favorites for later (or never). And we invest in market/design/technical validation now to queue up valuable work for later.
We mostly pick items that target our broad audience: features and UX work and -ilities that will drive aggregate sales volume, reduce overall churn, or boost joy for average users. Single-customer requests rarely make the cut.

We may feel a sense of accomplishment, laying out a balanced plan for the quarter. It rarely plays out this way, though, because the enterprise prioritization game has just started. Within days of getting executive agreement the plan, one of our enterprise sales teams escalates an issue…

[2] FOLLOWING ONE ENTERPRISE ESCALATION

Customers for most software have lists of things they’d like added or changed or redesigned. In consumer and small business markets, we have thousands (or millions) of customers, and no one customer pays us enough to demand roadmap changes. We look for broadly applicable improvements that will drive widespread adoption, upsell and churn reduction among our target audience. Quoting my childhood hero, “the needs of the many outweigh the needs of the few. Or the One.”

Enterprise customers are bigger, and fewer, and our executives know them by name. Some represent 1% or 2% or 4% of our total revenue. And enterprise customers look at our roadmaps as the starting point for negotiations: assuming that we will deliver most of what we plan, but also identifying things on their individual shopping lists that we’ve intentionally omitted. Common requests are for data exchange with home-grown legacy systems; process-specific workflow changes; third party report-writers; and support for obscure test infrastructure.

Perhaps most importantly, we’ve assigned enterprise sales teams to our major customers. Enterprise sales folks have some essential skills that we hire, train, reward and promote them for:

Persistence, optimism, and terrific ability to form personal relationships
Narrow account focus: paid to keep one (or a very few) customers happy, buying and renewing year after year
Persuasive positioning: ability to describe our products/services as meeting the customer’s needs better than competitors or alternatives. For instance, they help rejigger RFP processes in our favor.
Ability to finding champions with the customer organization, escalating or rerouting decisions to allies and supporters
Very clear success criteria: teams that “close” go to President’s Club in Hawaii; teams that don’t are let go. (Coffee is for closers!)

(Full disclosure: I’m bad at selling, and deeply respect salespeople for their ability to do what I can’t. They coddle customers, creatively sell imperfect products, bring in the revenue, and are celebrated for doing it.)

So when a major customer asks for something that’s not in plan, the sales team dutifully asks product management to build it. And our sales team almost always gets a “No” or a “Maybe in a few quarters, let me put that in the backlog” answer instead of the enthusiastic “Yes, absolutely, what a great idea, we’re on it!” that they wanted. Most product managers think this is the end of the conversation.

But we’ve hired and handsomely paid our enterprise sales team to be persistent, persuasive, and to find champions within organizations who can help them succeed. And we’re (somehow) surprised when our salespeople turn those same skills inward, and persuasively escalate their key customer’s request up through sales leadership – eventually to the CEO or operating committee. Inevitably, executives hear that:

This customer is one of our largest, or otherwise strategic. The requested feature is essential to closing the deal and hitting revenue goals.
This particular request is pretty easy, probably only ten lines of code.
The customer knows exactly what’s needed, and has correctly spec’d the work.
Engineering is agile, so we can slip this into next week’s sprint.
This is a market demand, and not just a single customer demand. Everyone they talk with needs this very same thing. We should already be doing it.

All of these observations are plausible, and we all want them to be true. And from the viewpoint of an enterprise sales team that spends all of its time with one huge customer, they are true enough to run up the organizational flagpole.

Woven throughout is the assumption of engineering surplus: that because we need this enhancement, there must be resources and room for it. Because this is one of our most strategic customers, we have to find a way. That account-level revenue planning trumps market-level product planning. (In other words, we pay our enterprise sales teams to subvert our product plans.)

Sales teams are smarter and faster at escalations than product managers are at responding, so this can be a one-sided discussion in the executive suite. What filters back down may be “just find a way to get this done.” Product folks miss the chance to present our counter-argument, which sometimes sounds whiny or defensive:

No, there’s really no unassigned resources or free space or excess capacity
We’ll have to postpone or cancel something already in queue, like X or Y
The customer doesn’t understand our architecture (or has proposed a poor solution), so we need to start from scratch with technical meetings and needs analysis. First guess is that it’s a big piece of work.
If this were truly a market need across the whole customer base, we’d know it. And we’d have put it near the top of our list. (Which the executive team reviewed.) We’ve already rejected this specific item because it’s of very limited use elsewhere.
We’ve pushed back on requests from this customer before, as they’ve churned through various short-lived demands, and deals still got signed. Not clear from the product side if this is truly a make-or-break item or a test of loyalty.

But as this is a very occasional thing, we grumble and fit it in somehow. With hope in our hearts, we anticipate a small impact on the current plan.

Typically, the request has been through too many hands – and arrives as a partial solution rather than a problem description. (“Add this report, make these interface changes, extend the export API, just add a couple of columns to the database.”) We wonder if this will actually solve the customer’s problem, and lack context about alternatives that were rejected. And we’d rather not pull people from work already in the design-and-build-and-test cycle.

So instead, we interrupt senior designers, developers and product managers who work on forward-looking stuff. We engage directly with the customer’s technical team to confirm the situation and figure out what options we have. We swipe from planned market validation and design thinking to implement this with least possible effort.

This shifts our engineering investment portfolio slightly:

Not a catastrophe this one time, if things go well… even though we’re borrowing (stealing) some time from planned validation, design and architecture.

And sometimes this does go well. (Product folks and senior developers can be just as optimistic as salespeople.) But usually, there are hiccups or surprises or serious issues. New workflows need new data elements and therefore new input streams; third party report writers lack supported APIs; customers’ legacy systems have security holes or performance bottlenecks; small UI changes muddy our carefully crafted UX. So we put in a lot of effort to deliver a tech-debt-heavy workaround by the promised date.

Which means the real impact looks more like:

Putting our best folks (or those least committed to already-scheduled development work) onto this has temporarily pushed aside all of our current validation and forward-looking design work. But we’ve met our commitment to this big customer and supported current-quarter revenue. The executive team is pleased and our sales team Instagrams lovely sunsets from Hawaii. Disaster is averted. Product, Design and Engineering are heroes of our own brief drama, and we get back to our planned work.

Except…

[3] EMERGENCE OF SALES-DRIVEN BEHAVIOR

This little fire drill had a good outcome, with rewards for both the executives and one enterprise sales team. In fact, our leadership team may have learned that Engineering and Product can fit in one-off requests despite all of the protests. (Nothing terribly bad happened.) And our other smart, persistent, well-connected sales teams are quick to identify a great tool for closing their biggest deals.

We’ve established a new behavior. We’ve rewarded single-account escalations.
Requirements for major deals are fast-tracked up the org chart. Commitments are increasingly made within the sales organization, and include delivery dates. Executives present lists of pre-approved projects to product managers, fait accompli. We shift from market-driven validation and analysis to account-driven decision-making. Big deals each routinely include just one special thing.

Can this grow out of control? Yes: I’ve seen a score of enterprise companies where single-customer projects now consume 30%+ of the entire development budget.

This incrementally squeezes out broad customer-visible features, -ilities, and support infrastructure.

Symptoms:

Product managers are frustrated and dejected, since they do less product planning and more project management. Incoming commitments don’t fit any particular strategy or architecture, so the products become less coherent over time. Target audiences and Jobs To Be Done give way to lists of narrow features.
Development teams are frustrated and withdrawn, since they are given customer-designed projects to implement instead of engaging in problem/solution thinking. They get little positive user feedback and fall out of love with their products.
Designers quietly give up on good design, incrementally changing interfaces to please specific customers as they lose control of overall user experience. Usability declines.
Sales teams are (again) frustrated as they discover that customer appetites for one-off projects are insatiable. The development queue fills up entirely with named-customer commitments, and there’s (again) no room for the next request. Onboarding new customers is delayed, since they have to wait for their own special projects.
CFOs see falling profitability. Since we’re selling semi-custom software at product prices, we’re not recovering the full cost of one-off project work. New accounts (with their own special requests) are queued behind current commitments, so revenue growth slows.
Executives are frustrated that new account sales fall off, as exciting improvements are crowded out – and competitors catch up. We talk a lot about innovation and culture.

Not a happy situation. And ripe for cross-functional blame as we interpret this as individual failures or lack of commitment. (“If product management would just listen more…”, “If developers would put in some weekends and catch up…” “If sales would just sell what we have…”)

Instead, this is a systemic organizational problem: by investing first in single customer requests, we’re trading away our ability to plan and architect products for a broad market. We’re hiding custom projects in our licensing model. We’re paying employees to undermine our success. We’re failing to charge market rates for real value.

SO WHAT DO WE DO?

This is a hard problem, and one that individual product managers (or developers or designers or salespeople) can not solve themselves. This rests with the executive team, and may include some tough medicine:

1. Recognize the pattern, and decide if this is a problem.

Take a hard, honest executive look at the overall problem, not just the most recent win. Can we grow profitably? How are we incenting our sales teams? What does it take to successfully onboard and launch a new customer? Where are the company’s bottlenecks?
Get data. Enlist product management to look back at the last few quarters, and tabulate how much of recent development has gone into one-offs. (Test questions: which items that we shipped were not in plan at the start of the quarter? Which items are being used by only one or two customers, even if we predicted they would be of general interest? What projects skipped the validation step that we claim we always do? Did we win the deals that these were intended for?)

2. Decide if your company should be a professional services or product company.

Half-and-half answers, waffling, and our-market-is-different justifications won’t fly. In or out; yes or no; black or white; products or services. I see product companies skillfully juggle at 15% sales-driven, struggle mightily at 20%, and wander off the road at 30%.

3. If you’re a professional services company, act like one – and raise prices.

Letting individual customers define your priorities means extracting full value from every project. (There are no “strategic accounts,” only profitable clients. Giving away work trains customers to expect more free work.) Benchmark yourself against competing services firms, and mark up your team’s time accordingly.
Partner with some product companies that need your expertise to round out their packaged offerings.
If you want, assign a small permanent team to build platforms and tools that will improve your engagements (and don’t raid them for project work).

4. If you’re a software product company, manage the conflict instead of explaining it away.

Recognize that profitability and success for software product companies come from growing their user base and keeping customers renewing year after year. License revenue has to fund a steady stream of improvements and enhancements, mostly included at no additional charge, to keep buyers from churning off to shiny new competitors. Inspect aggregate business patterns as well as individual deals.
Decide on an absolute budget for engineering effort on all sales one-offs (<10%) and enforce it at the executive level. Give your Sales VP power to choose one or two small projects – e.g. up to two engineer-weeks of development – each quarter, with product/engineering confirming size and viability. That aligns company and account-level incentives, since your Sales VP is motivated to maximize total company revenue. Then have product managers redirect escalations back to Sales for adjudication.
Adjust your comp plan to reward the right behavior. Sales teams get 100% quota relief on standard product, and 20% relief (or maybe minus 50%!) on the actual cost of one-offs. Remember that we love our salespeople, but they do what we pay them to do rather than what we want them to do.
Accept that development is truly a limited resource. When pushing for something new, find out what will fall out of plan to make room. Respect that engineering and product leaders worry about the long-term health of products, and that some trade-offs may take quarters or years to become obvious.
Separate professional services work (and staff and budgets) from core product work. Force all custom projects to return 3x their costs. Don’t confuse “field-developed software” with supportable products.
- Even better, recruit some outside professional services partners. Keep license revenue in-house and pass all custom work along to companies that will charge market rates. Work on improvements to core products that let these partners absorb more one-off projects.
Task engineering and product with architectural improvements that reduce the need for custom work. Create documented reporting interfaces, intentionally designed white label options, integration with security standards, hooks to commercial DevOps tools… ways to offload customization.
Give product managers wide latitude to push back on “everyone wants this” arguments from executives and sales teams. In return, ask for market measures of demand (for upcoming features) and adoption (for shipped features). Shift discussions to usage rather than ship dates. Develop a healthy skepticism about feature factory teams that deliver lots of unimportant stuff on schedule.
Find ways to push your current customers onto your current product versions, no matter how much they (or your sales team) resist. If you’re supporting three (or six) back versions, there won’t be engineering left for obvious improvements or innovation. Double support fees for your one-back release, quadruple them for two-back…
Report monthly at the executive level on one-offs underway, pending customer commitments, and what (specifically!) has been postponed in their place. Name the customers who are waiting for in-plan improvements, including their renewal revenue. Increase the visibility of specials, highlight the costs and frequency of interrupts.

A tall order, and not for the faint of heart. But I’ve seen account-level feature demands cripple more than a few enterprise/B2B companies. Let’s get to work.

SOUND BYTE

Every enterprise company fulfills some single-customer requests. But more than a sprinkling of one-offs gets expensive and corrosive, and can undermine growth and profitability. Leaders need to see the broader pattern, then address the aggregate impact systematically.