Ah, product management. The all-important liaison. The bridge. Bringing together many professionals and departments across the company, each with their own specialties, and threading together a team with a single goal: deliver a great product to the market.
But if you’ve been a product manager for any amount of time, you’ve probably discovered that in addition to all of the logistical difficulties in building a cohesive product team across many departments, there’s also a bit of a language barrier. Not because people speak different languages, necessarily, but because they speak different dialects of English. There’s Marketing-Speak, Sales-Speak, Executive-Speak, Investor-Speak, Product Management-Speak, Finance-Speak… and of course, Developer-Speak – my personal favorite.
This might partly explain why so many businesses default to focusing on money: At least numbers are universal. When we talk about revenue projections and costs and profits, we’re all on the same page. Everyone in the room always knows what’s being discussed when the conversation turns to GAR or QoQ or YoY or MQL or CAC or CPM or SQL or TAM or SAM or SOM. Right?
Haha! Just kidding.
Unless you spent your last decade in marketing land, like I did, you probably don’t know what all of those acronyms mean — and they all relate in one way or another to a single subject, money. That’s the point of this post. Every department in every business has its own ways of understanding even something as seemingly universal as money.
And by the way, see that “SQL” in the list above? We were referring to the Sales-Speak version, which means Sales Qualified Lead — not the one you were probably thinking of, the Structured Query Language used in Developer-Speak.
Tweet This:
“Your job as a PM is to unite diverse teams around a commonly understood goal.”
So, if your job as a PM is to bring all of these different teams together and get them working toward a commonly understood goal — but even a tiny three-letter acronym like SQL is going to mean something completely different to Sales and to Development — how are you supposed to succeed?
You’ll have to bridge this dialect gap.
Unraveling the details of the unique jargon and idioms spoken across your entire company is beyond the scope of this post. So let’s start with probably the most important dialect you’ll need to decode (pun intended!) as a product manager: Developer-Speak.
Translating Developer Speak: 3 Things Your Developers Will Tell You (and What They Really Mean)
1. “That’s not happening on our machine.”
What dev really means:
“Look, we can’t fix this. We don’t even know what problem you’re seeing. Good grief — are you even looking at the right screen? Maybe restart your computer? Let’s table this for later. Sorry.”
In most cases, your developers want to be helpful. They really do. They’re part of the team, after all, and they know that the product you release into the market reflects just as strongly on their abilities as it does on yours or anyone else’s in the company.
Tweet This:
How PMs can decode developer-speak: “That’s not happening on our machine.”
But if you get the “We’re not seeing that on our machine” statement from your developers when you try to describe to them an issue you’ve found, it’s often a signal that you have more than a failure in the product — you have a failure in communication.
Don’t get mad. Don’t get confrontational or short with your developers. Best advice here is to find another way to communicate the issue you’re facing. Ideally you’ll want to get everyone into the same room, so you’re all looking at the same screen.
If that’s not possible because of geography, take a screenshot of the problem (or a video recording of your user experience, if it covers more than a single screen) and send it to them.
2. “That’s not a defect; it’s a new story.”
What dev really means:
“Hey, you didn’t tell us to code it that way. So you can’t tell us now that it’s wrong.”
Again, your developers in this case are identifying something bigger than the defect itself. They’re pointing out a lack of detail in your written spec, and more generally they’re uncovering a failure in communication. And it might well be your fault.
This is yet another reason (as if you needed one) to build a clear strategic explanation of your stories and features into your product roadmap. Simply listing a story in a single sentence — “Customer clicks the Export button” — might clearly suggest in your own mind all of the follow-on steps that click will lead to, but it might suggest other steps in the minds of your developers.
Tweet This:
How PMs can decode developer-speak: “That’s not a defect; it’s a new story.”
What your developers are trying to tell you here, then, is that you need to do a better job of communicating to them exactly what you want them to build. And you can do that in your meetings, in your backlog, and by linking those stories to your product roadmap.
3. “That’s not exactly how dev works.”
What dev really means:
“Would you please just read The Complete Idiot’s Guide to Programming Basics? We’ll even buy it for you out of Development’s budget. Then we can have an intelligent conversation about what’s possible, what’s possible in the timeframe you’re requesting, and how many resources it’ll take to get it done. Just learn some basic coding first so it doesn’t sound like we’re speaking in Alien. Pretty please?”
A PM will often hear a statement like “That’s not exactly how dev works” after she’s said something to her development team along the lines of, “Well, this shouldn’t be that hard to code, right?” or “I can’t imagine this will take you more than a couple of days.”
Yes, sometimes your developers will exaggerate the difficulty or resource requirements of a given project because, well, they’d rather not work on it. And to accomplish that they might try to scare you off you with jargon: “Well, that’ll require an additional M1 instance” or, “We’ll need to hire at least two more C# experts to get that done.”
But it’s also possible that as a PM, you really don’t have the technical understanding to accurately estimate Development’s ability to get something done, with the resources they have, in the time you need it.
Tweet This:
How PMs can decode developer-speak: “That’s not exactly how dev works.”
So when you hear “That’s not exactly how it works,” you shouldn’t get defensive or frustrated. But you shouldn’t let them off the hook with a tech explanation that goes over your head, either.
Instead, slow the conversation down, ask your developers to explain the issue to you in layperson’s terms — no jargon! — and see where that leads you.
(Oh, and it might not be a waste of your time to actually read The Complete Idiot’s Guide to Programming Basics.)
Do you have any helpful (or fun) examples of translating Developer-Speak into PM-Speak? Share them in the comments below.
