The Software Development Deli Counter

I’ve noticed a frequent executive-level misalignment of expectations across a range of software/tech companies, particularly in B2B/Enterprise companies and where Sales/Marketing is geographically far away from Engineering/Product Management. Let’s call it the software development deli counter problem. Here are some symptoms, root causes, and a few ideas to reduce the mutual frustration.

On the Revenue Side of the House…

Executives, particularly those from the non-technical side of the organization, see their role as thinking of new ways to drive revenue and growth. And they’re right. Opportunities, customer requests and possible partnerships come at them in a steady stream. It’s easy to forget, though, that almost all new products will need engineering work – plus participation from many others across the company – to generate revenue.

Likewise, sales and business development teams (especially in enterprise companies) are hired and paid and rewarded for bringing in large deals.  In fact, we fire enterprise sales folks who don’t close big deals. (First prize is a Cadillac…)  Major deals can  represent a sizable part of this quarter’s revenue, and often include requests for special features or custom services – so sales teams are strongly incented to deliver exactly what’s been asked for.

Revenue-side executives and sales teams spent much less time thinking about what’s already in the development pipeline than product managers or development teams do. In fact, many revenue-side leaders don’t know what’s currently being built. Which takes us to this chain of reasoning:

• “I don’t remember what’s in the development pipeline.”
• “I don’t hear much from Engineering/Product except when they are late delivering against commitments. Doesn’t seem like they’re working that hard…”
• “This is a really big opportunity, worth $M’s right now plus follow-on revenue.”
• “So it’s a no-brainer that Engineering should start on my thing right away.”

When the request/demand finally arrives, it can sound like a sandwich order at the local deli counter:

BigCustomer needs our enterprise ERP product by Friday, with a side order of custom reports, heavy on the APIs, please substitute on-premise deployment for standard cloud hosting, and hold the per-seat license model — since we’ll have special pricing terms.

Assumed, but unstated, is that we have idle engineers hiding behind the software deli counter waiting to assemble whatever customers order, and that no other work needs to be delayed/canceled to start this new thing. Also assumed: everyone with some budget, or a large deal, will get their request approved. (“Engineering can always bring in contractors.”)

I’m exaggerating, of course. Revenue-side executives and sales teams understand that there are priorities and strategies and resource constraints. But they aren’t necessarily interested in the inner workings of development.

On the Technical Side of the House…

Across the aisle in Product Development Land, we’re endlessly fascinated by the intricacies of building and releasing stuff. Revenue-side questions about delivery dates are met with long tutorials on Scrum vs. KANBAN vs. SAFe vs. AgileFall. With the audience walking away mid-lecture. (It’s like listening to audiophiles argue about LP vs. CD sound quality; or designers critiquing font kerning; or chefs gushing about pink Himalayan salt and grass-fed beef. Not as interesting to outsiders.)

We think of our product development process this way:

expensive, intricate, and based on complex reusable architectures. We consume lots of fuel even if the mission is just to deliver lunch to the ISS crew. We obsess about average velocity, rather than specific deliverables. And we look down on those less obsessed than we are.

What’s Happening Here?

Notice that this is a combination of incomplete information, poor communication, and opposing view about what’s important. Requesters are focused in their next new thing, and are unconsciously minimizing the effort. Engineering knows that it’s already overcommitted, and wants to ignore interruptions.  We’re often talking past each other. What to do?

I’ve had success helping product/engineering teams build out a very simple tool to address the underlying communication challenge. It’s a one-pager that shows things currently being built; things queued up for feature definition/design; and things queued up for customer/market validation.  Product/engineering reads it left-to-right, but sales/marketing may read it right-to-left.

Almost everyone on the Product/Engineering side thinks that revenue executives and sales teams know what’s on this list. But it ain’t necessarily so.  A weekly executive review of this simple, high-level chart* reminds everyone what’s actually underway, which lets us have more nuanced conversations.

The Product WIP chart becomes a frequent reminder of what’s underway. Product and Engineering leaders can now frame better questions:

• “If we move that great new idea right into development, which of our ‘In Development’ projects should we delay or cancel?”
• “We’re much more successful when we do solid design and feature definition, so that should happen before we start coding.  What design work is bumped for this new item?”
• “Customers didn’t buy some of our earlier seemingly-good ideas, so a few weeks of market validation might save months of development rework.”

This helps train the entire executive team to ask better questions and wrestle with OR decisions instead of AND demands.  Are we working on the most important projects? Which of the many good ideas should we validate first? How many new features can we productively build or launch at the same time? Will solid design work help us size development effort better? What’s the cost of canceling a partially finished project?

Because there are no engineers hiding behind the software deli counter waiting for their next Job to be Done.

Of course, that’s not the end of this story. Once we’ve all recognized the existence of a product/development queue, we might add:

• Technical/product reviews of major bids early enough to steer toward good solutions. Customers often ask for the wrong things, or misunderstand product architectures, or are unaware of existing features that could solve their problems. Having good product input early on saves us from triple-wasteful rushed implementations of wrong enhancements that crowd out useful work.
• Designing products with flexibility where most customers need it. Looking back at previous sales, we can spot a few areas where we need to build into options or configuration choices, thus avoiding many last-minute customer demands.

And so on. There are plenty of way to improve the product development processes.

Sound Byte

On the product/engineering side, we often assume that the revenue side is following our every update and is fascinated by our internal processes. Unlikely. Good decision-making depends on over-communicating and explicitly framing trade-offs.

* I’ve carefully avoided using the term “roadmap” anywhere in this post. Let’s unpack that another time, knowing that the revenue side of the house wants roadmaps to be five-year iron-clad commitments, while some agile developers deny the existence of roadmaps.