How Much "Dev Speak" Should Product Managers Know?

Software developers working on computers

Product managers need to be able to connect with the engineering team. But some product managers — and people in general — often feel excluded from the cultus of software development. I know because I am a software developer and I work with product managers every day.

Some engineers project the image of themselves as a sort of techno-priesthood — cloistered away from the common man, performing their holy rite of transubstantiating caffeine into code. Approach with coffee and brilliance, or not at all.

To outsiders, it may appear that the shibboleth that will allow them access and respect is to adopt some psuedo dev speak.

What is dev speak? It is a strange language that sounds something like this: “I just saw a great presentation on using Docker and NoSQL to web-scale our cloud.”

The expectation is that the engineering team will nod their head in agreement, extend the secret handshake, and welcome the new product manager into the fold. However, as a software developer I can tell you that using low-level development jargon does not foster connection — at best it only sounds slightly off-key and at worst disingenuous.

You sound like Steve Buscemi masquerading as a high-school student. Don’t be like Steve Buscemi. Don’t fall into the trap of believing that jargon is the secret password to any given group.

Don’t tell anyone, but here is a deep dark dev secret: We do not like jargon.

Programming jargon is a necessary evil. It allows us to communicate large ideas in the small space of our chat windows. It puts a handle on complexity, making it possible to communicate our intent — the mental house of cards of a program not yet written. But only bad developers use jargon to exclude others.

Someone might have told you differently, but developers are people too! And people do not communicate in code. If you want to “speak developer” you should really try to get better at “speaking people.”

We often refer to “hacks.” These are the shortcuts we take to achieve a desired end. Yet in building bridges between human beings — each of us an island — there are no shortcuts. Rather than memorize jargon, product managers should prioritize these four pillars of communication:

Vision is perhaps the hardest and most crucial thing that product managers must communicate. Without vision, the people perish. This is where we trust you to present a convincing case for what we are building and why. Nobody gets excited for yet another social, local, mobile app to help people buy more stuff. Think bigger, find the place in the world where we can pull our company’s lever, and we’ll give you a place to stand. Let us work together on a realistic timetable. And then, trust us with how to build it — it’s what we do best.

Respect is something that we developers hold especially dear. Programming is hard. We fail constantly, and we actually write tests to show us our failures to avoid doing so publicly. Programming has been called an art, a science, a craft. I call it living poetry. Respect our work. Respect the long hours we’ve spent to train ourselves, and ask us how what we’ve written really works. You will be awed. And we would love to explain it to you.

Developers and product managers want the same thing: to build an amazing product. We don’t write code for machines. We write it for you, for our customers, and, in tertiary measure, for ourselves. In some organizations, the walled silos make it hard to see the truth of that statement. (Hey product manager — tear down this wall!)

Enthusiasm should be shared. And camaraderie will beat out mistrust any day of the week. Are you excited to solve problems for our users? I assure you, we are also excited to find creative ways to make it happen. Ask us how we solved it. Tell us how you found out that our customers needed it. What did they think? How can we make them even more happy and make our product more lovable?

Is this approach harder than picking up a few bits of technological trivia? Of course it is. Bridging cultures has always been hard — it’s a common refrain throughout human history. But there is far more that unites us than divides us. We need each other.

So stop talking like an annoying engineer. Start talking like a great product manager.

Great product managers focus on our common ground. They are the eyes and ears for developers, showing us what our work is accomplishing. They help us see what’s coming on the roadmap and more importantly why it’s coming, so we can prepare for what’s ahead. And they communicate the vision that inspires us to create even more.

How do you speak with the engineers?

About Alex and Aha!

Alex likes to write code to solve problems. He is an Engineering Lead at Aha! — the world’s #1 roadmap software. Previously, he built both applications and infrastructure at two successful software companies.

Sign up for a free trial of Aha! and see why more than 300,000 users worldwide trust Aha! to build products customers love.

We are rapidly growing and hiring!

  • Customer Success Managers (product manager experience required)
  • Product Marketing Managers
  • UX Designers
  • Rails Developers

Work from anywhere and be happy. Learn about our team — see current openings.


  1. Rudra

    Developers should not be talking the implementation details in a forum where we have Product Managers. The Product Managers are experts of Business use cases and we should for the most part try to stick to the use case understanding and how an end user would use that product, either a enterprise user OR a consumer.

    Also talk with Product Managers should revolve around any competitor products that are in market and discuss about the pros/cons of that. A lot of times the developers tries to bring in Challenges/implementation details in a meeting with the Product Managers, which should be avoided.

    If the feature ask is something which is technically not feasible, the developer could have a one-on-one discussion with him and explain what is technically achievable and what is not.

    Developers should although give him a heads up on the overall flow of the system in use like any Cloud services that are being used, any third party tools(for licensing).

  2. Tina Rakos

    Great article! I find the magic words over the years when working with developers have been “I defer to your technical expertise and trust your understanding of how to technically implement to solution”. That is very concretely within their domain and you have to respect what they bring to the table.

    Additionally I have found taking their feedback on the business risks poised by technical debt and architectural age very seriously as I plan my roadmap creates trust.

    Last-most developers seem to be very data driven and analytical, so I bring back customer data and let them see what I am basing my judgments on, in some sense allowing them to crowd source the product management process with me, which creates a strong sense of trust. If I cant convince them of prioritization of a feature via data and customer feedback, I havent made a very good case for inclusion.

  3. Bernd Harzog

    If you have great developers (and we are blessed to have outstanding ones), then talking to them is simple. Just state things in terms of the problems that customers want to solve and how these problems are common across customers (making them into market requirements).

    Pay particular attention to how customer and market requirements will change over time. Always try to give your developers as much of a forward looking view as possible.

    If you tell your developers, “Here is this class of problem, here is the right now manifestation of that problem, here is how that problem will likely change over time, and here is how it relates to the other problems we solve in our product” you will empower them to architect and build a solution that elegantly extends over time.

    Which is exactly what you want, exactly what the customer wants, and exactly what they want.


Leave a Reply to Tina Rakos Cancel reply

Your email address will not be published. Required fields are marked *