There’s a dog whistle problem with critical phrases that Engineering VPs (and product managers) repeatedly speak but which often can’t be heard by sales people or executives:
- “There is no slack in our development schedule. We’re fully booked.”
- “If we make this new customer commitment, we will have to pull technical staff away from projects we have already committed to customers. That means slipping project ABC.”
Notice that the two are logically identical, with one painting the big picture and the other reaching for concrete implications.
IMO, this results from a fundamental difference in worldview between those who develop software and those who need it. They are mostly talking in frequencies that the other can’t hear.
Non-technical execs, unseasoned sales folks, and less-informed customers see the development process as elastic and somewhat magical. They are focused on other things (managing a company, closing deals to earn commission, solving stubborn market problems, planning the next corporate re-organization). They want to be Don Draper, not Sheldon Cooper.
Wildly exaggerating their assumptions:
- This request (my latest wish list item) is really important and can’t be very difficult. Probably ten lines of code.
- Creating software is just writing code. If I see you typing, you’re working.
- Planning, architecture, collaboration, brainstorming and testing don’t look like work. Since I see people chatting, they’re available (so we can add one more thing).
- Development has time for things I don’t need, which we could postpone (and add one more thing).
In fairness, the development side of the house is often clueless about what salespeople, marketers and executives do – and why it’s sometimes so bloody hard. They believe in a rational universe mostly filled with left-brained folks. More Spock than Kirk, more Jonah Hill than Russell Brand.
Wildly overstating technologists’ core assumptions:
- Customers evaluate products based on actual features using standard criteria. Salespeople sell by objectively presenting this information to interested prospects. The best products win.
- Sales reps have a stack depth of one. (Translation for non-hardware folks: reps can only remember the last meeting they were in.)
- Marketing is mostly about artwork: putting product information and customer success stories into pleasingly formatted websites and brochures.
- Our corporate strategy is unambiguous. Decomposing it into product line goals and deliverables is straightforward and self-evident.
- Senior executives are really interested in details of how our software works, and why our algorithms are awesome.
This creates a classic conundrum: the non-tech folks who bring in cash and pay our salaries believe that we can fit additional projects into an already over-committed schedule… without much notice, analysis, or serious trade-offs. That we can “work smarter, not harder.” Our traditional responses, like the dog whistle, aren’t heard.
And their most urgent messages (“the market thinks our competition is out-innovating us,” “we can’t invest more in R&D without growing revenue”) aren’t specific and actionable enough for us techies – so whistle in one ear and out the other.
By the way, product managers and their bosses – Directors of Product Management, Heads of Product, Chief Product Officers, whatever – are natural translators between these groups. The good ones are bilingual, able to talk tech and speak customer. Able to whistle at low and high frequencies, so everyone can hear.
SO WHAT DO WE DO?
IMO, it’s important to attack this set of perception problems when there’s NOT an urgent interrupt already in the air. When executives and non-tech folks can listen, because they aren’t pitching.
I’ve seen some (limited) success shaping behavior this way:
1. Relentless reminding folks of what’s underway and next on the backlog. In senior staff meetings, over lunch, in customer pitches with the sales team present, in monthly sales update sessions, during budget sessions, endlessly. This serves dual purposes: it reminds the revenue side of the company that (in fact) development is working on a short list of critical items that customers have been clamoring for. It also builds anticipation for those specific items. If we’ve made good roadmap/backlog decisions with support from Sales/Marketing, most customer-facing folks will recognize their own needs on the list. We’ve undercut the “slack” myth – that we have unassigned capacity – and built support for the current plan.
2. When a new request comes in, compare it (respectfully) to the current list. Now that our requester has some chance of remembering (when prompted) what’s already underway, we can ask more useful questions. Instead of “what kind of ^%$# idiot are you, and why do you think this is a good idea?” we can try
- “Your new idea X is really interesting. Remember in last Friday’s senior staff meeting, when we confirmed that our top 4 priorities are A, B, C and D? Love your input on which of these we might delay to work on your item.”
- “I know that your customers 1, 2, 3 and 4 have been patiently waiting for A and B. What’s your sense of the revenue swing if we delay those for X?”
These are, of course, mostly non-answers to a sales person, who is paid to close individual deals. He’s not actually interested in your prioritization exercise, how the backlog represents aggregate value to the customer base, or company-wide revenue. He needs a YES to his specific prospect’s feature request. So plan to…
3. Engage sales management and executives in the discussion. If your current development plan is wrong, you need to change it. Most likely, though, this next request is correctly ranked deep in the backlog. Sacrificing major projects for a speculative, one-off feature is typically a mistake. So whistle phrases like
- “Jessica [CEO] says that getting Version 10 out this quarter is our #1 company goal, so your item probably needs to wait until next quarter.”
- “We should probably run this past Larry [VP Sales]. He agreed to the current plan and knows which deals depend on it.”
After a few weeks, see if your new audio signal is being heard. Behavior modification is all about repetition. When the same person comes back to you a third (eighth) time, don’t give your stock answer: ask him if he knows what you are going to say. Your message is being internalized when he repeats it back: “yeah, I know, you’re going to ask me what we have to drop from the current plan.”
BTW, no need to keep a pocket full of treats for the revenue side of the house. An appreciative smile and help closing deals are what motivate them.
SOUND BYTE
From outside R&D, It’s easy to imagine excess development capacity and forget what’s currently being worked on. Product managers (and Engineering VPs and many others) have to whistle the facts often/loud enough to be heard. And bring treats for the dev side.