Over the past year, I’ve done a half-dozen evaluations of product management teams at enterprise software firms. These include extensive interviews with a range of internal stakeholders. One pattern that’s emerged: Sales and Marketing teams usually tell me that Engineering is unproductive, inefficient, or just not working hard — and they attribute this to a lack of motivation. “If Engineering just understood how important these enhancements are to our customers, they would get them done.”
Underlying this is a pattern of clashing expectations that’s worth unpacking. I break this down into:
- The distinction between overall engineering productivity and account-level responsiveness
- Strategies for handling inevitable interrupts
- The need to “sell” the value of roadmaps and architecture to Sales
Engineering Teams Focus On Overall Productivity
Agile development teams think about productivity in terms of overall velocity metrics and backlog/roadmap commitment. How good are we at estimating stories and team capacity? How many story points have we completed in the last few sprints? Can we make commitments against the top 2-3 big roadmap items and get them done when we say we will? Are we improving DevOps repeatability, retiring tech debt, and shortening our release cycle? How do we increase predictability, eliminate drama and have fewer emergencies?
Productivity is about the long game: rigorously and methodically working through an endless backlog at a sustainable pace. With 52 releases a year, high-priority interrupts can be kicked to next week and all-nighter death marches should be rare.
Essential to this approach is a well-sorted backlog that lets engineering teams start-then-finish a couple of important things, start-then-finish the next few, etc. Product management defines a mostly-stable set of quarterly market deliverables that Engineering chops up, powers through, and reassembles into customer joy. And a notional medium-term roadmap is very handy, since it may take several quarters to build out some substantial enterprise value.
Product/Engineering builds repeatable solutions that dozens or hundreds of our enterprise customers can put right to work.
Enterprise Sales Teams Focus On Responsiveness
Sales lives in a different world. Enterprise account teams aren’t paid based on the company’s overall success in a market, they are paid to close individual deals with specific customers who often have unique variations on the generic problem. Throughout the selling and installation cycle, customers raise a variety of issues – real or imagined, correctly diagnosed or entirely misunderstood – that threaten revenue.
Ideally, most customer needs are handled by the current product. And a few more are in this quarter’s roadmap Inevitably, though, a handful are not. Sales needs Product and Engineering to review these ASAP.
So Sales grades Engineering on responsiveness: the ability to quickly understand, estimate, schedule and deliver a few key enhancements for this customer that were not already in plan. (Without dropping any commitments for other customers, BTW.) And this needs resolution in the customer’s favor right away, so that competitors don’t steal the deal. Product management, if involved at all, is just the official channel for Engineering to make commitments on behalf of Sales to the customer.
Different Timeframes, Different Granularity
Recapping, Engineering builds repeatable, reusable products that meet the broad needs of many clients. They want a consistent, thoughtful, low-drama process that lets them make commitments based on clear requirements, good estimation, and intentional architecture. Fewer interrupts means more productivity and happier teams and lower turnover. Success is about meeting the aggregate need of hundreds of paying customers.
Enterprise sales teams see the world one account at a time. Individually, their escalations and enhancement requests make perfect sense – therefore product management should be able to organize Engineering to get them done. If we can’t quickly handle a couple of simple enhancements for our largest accounts, there must be something fundamentally broken.
Scaled up, though, hundreds of “must have this quarter” demands collide with a fully committed Engineering team. Too many AND requests that don’t fit into an EXCLUSIVE OR development model. Product management is typically responsible for tracking all customer requests, evaluating/sizing/ranking them, adjudicating which are added to the development plan, and communicating decisions to all parties.
So How Do We Handle Sales Interrupts?
There are a few ways to address this systematically with the knowledge that we will never have enough development resources, and most customer requests will (in fact) never be met.
1. The Roadmap Is the Roadmap Is the Roadmap
We could choose to ignore all urgent customer requests/demands on principle. Our product managers or executives are visionaries – prescient and omniscient – and we understand what customers really want more clearly than they do. Our quarterly planning process gets it right and we deliver maximum value for the most customers with minimum interrupts. (Insert debunked Henry Ford quote here.) We’ll look at any incoming requests during our prioritization cycle for next quarter.
This might just work in some mass consumer markets, where millions of individual buyers have a nearly-identical need, and where no single customer is big enough to wield much economic leverage. If we’re making disposable razors or least-common-denominator chat apps for an audience of billions, we can’t possibly listen to each prospective buyer. (Good Lean practitioners will still remind us to carefully validate our Jobs To Be Done and initial designs before we scale up.)
But this won’t fly in the enterprise space. If Deutsche Bank might license our consumer credit scoring system for $1.2M/year or ConAgra is interested in a variation on our ERP solution, we listen. Intently. Enterprise selling is lumpy, with the CEO and CFO getting constant deal updates from the VP Sales. If Verizon needs us to integrate with some really old RADIUS server that we’d never heard of, we’ll probably do it. Product/Engineering organizations can’t consistently ignore their executive team.
2. The Sales-Driven Roadmap
At the opposite extreme, we could prioritize all customer requests and enhancements first, with any remaining cycles spent on planned features, architecture, technical debt and longer-term research. We force-rank all incoming items based on likely ROI and/or deal size, and work from the top.
A lot of companies take this approach, and the symptoms are easy to spot. They’ve over-invested in individual features for single customers, and neglected a coherent product architecture. The website lists dozens (hundreds) of kitchen sink features and configuration options, but it’s unclear exactly what the product actually does. Internally, there’s one (or two or three) code lines for each customer; testing has been starved; estimation is replaced with date-driven demands based on contract commitments; technical debt is piled to the ceiling; and every weekend is a “just this once we need everyone to come in Saturday and Sunday” exercise for developers. There’s no focus on the one or two Jobs To Be Done that make our product shine.
And we’re always a quarter away from catching up.
This is workable for a company’s first 5 customers, since we’ll do anything to succeed. But by customer #20, we’ve devolved into a custom/contract development organization. That means our economic model (4laws2) doesn’t work: whereas real contract shops mark up their developers’ time to make margin on every hour spent, we’ve adopted market-driven software pricing that only reaches breakeven when we re-use the identical software bits for thousands of users. (“Competing SaaS accounting suites are priced at $75-150/seat/month. We can’t possibly charge the $100k we’re spending on this one customer.”)
So I rarely see short-term sales/customer-driven feature prioritization succeed for product companies.
3. Budgeting for Interrupts
Looking for some middle ground, I’ve had success allocating a fixed portion of overall development capacity to urgent sales-driven interrupts. 10% to 15% of a quarter’s story points seems reasonable without derailing the entire engineering process. We set aside a small fraction of every sprint for major customer asks, worked alongside more strategic product content.
Note that this provides a safety valve for the revenue side of the house, but doesn’t erase the problem. We’ll be able to help two or three account teams on small issues, but dozens of other requests won’t be addressed. This provides a scaffold for some more rational processes:
- Intense lobbying by individual sales teams is deflected back toward sales management, since the VP Sales has only a few magic bullets per quarter. Product Management doesn’t have to decide which deals are small, fictitious, or non-strategic.
- With a strict capacity limit, quick request sizing becomes essential. A weekly triage by Product and Engineering rejects too-big, technically implausible, and badly conceived items.
Of course, we don’t spend 100% of our development budget on features. We probably put half of our time/energy into features and customer-visible design, and half into automation, quality, long-term research and overhead. The biggest danger in allocating a small portion to sales-driven interrupts is that we’ll unintentionally overspend. Week by week, pressure from the executive team builds for current-quarter specials. Unmanaged, our intended 15% portion has again mysteriously grown to 50% and we’re late on most of our planned work. Sliding into #2 above.
(What about using professional services teams or outsourcing? This looks like an attractive option: sales teams and field organizations fund their own third party development or borrow in-house professional services teams. Major deals throw off plenty of margin, paying for what core Engineering can’t get to.
I see this working, though, only for parts of the core product have been architected for third party extensions. A data extraction API lets outsiders feed analytics apps flexibly; a white label website layout gives partners an easy way to drop in logos and colors. Mucking around in core modules must be limited to the formal development team, though: otherwise we find ourselves with broken product architectures, untested code, no long-term owner for one-off features, and customer marooned on un-upgradable custom code branches.)
“Selling” the Virtue of Product Plans
Understanding this clash between productivity and responsiveness, between current-quarter and next year, lets us recognize it as typical. Put it in context, address it less emotionally. As product managers, we realize the need to “sell” the virtues of a semi-stable roadmap and medium-term commitments to our Sales stakeholders. By protecting most of Engineering’s time for planned items…
- We can confidently make commitments to customers. Rather than routinely bumping planned items out for deal-specific needs, our word is (once again) our bond. Yes means yes.
- Rather than just say no to individual requests, we can identify what customers are getting instead. (“That’s a great idea, and makes a lot of sense, but our #1 deliverable this quarter is still auto-configuration. All of your customers will be much happier, and we’ll save a ton of field SE time deploying upgrades.”) Relentless identifying the reasons behind our Exclusive OR choices…
- The decision method is more objective and less emotional. (“We’ll have room for three unplanned customer items this quarter if each is a week or less. The VP Sales has final say on which deals get priority.”)
- We’re clear about when outside resources would help. (“Last release, we added an API for external management tools. So feel free to marshal third parties, professional services teams, or customer developers to build to that. We’ve gotten out of your way.”)
And we can recognize this as an inevitable part of enterprise product management. It’s not about being courageous or obstinate or grouchy or charming, it’s about seeing how different incentives shape the behavior of key players. Call it organizational anthropology.
Sound Byte
Enterprise sales teams want engineering responsiveness to support their complex, account-level revenue focus. Engineering teams want consistent productivity and no interruptions. Product Management sits between, mediating this with an eye toward company-wide success.