Geek Culture
Published in

Geek Culture

I’m a Product Manager and This Is How I Communicate Most Effectively With My Developers

DevSpeak for Dummies

Shutterstock Images

“S“So, what do you do?” Ah, the age-old dreaded question at dinner parties for every Product Manager.

“I’m kind of like a CEO,” I respond to prevent further questions, but it usually has the opposite effect where instead I am forced to deliver a spiel about what being a Product Manager means. Usually, this spiel is different each time because the answer to that question is,…well, the hell if I know?!

Product Managers are expected to be the unifying bridge between Sales, Engineering, Project, and Commercial entities across an organization(to name a few). However, the actual roles and responsibilities of a PM vary significantly across an organization spectrum depending on what product you are managing and within what structural bounds you are operating within. For example, currently, I am a Product Manager at the world’s largest beverage company and work with a team of Front-End Developers on an e-commerce B2B application. Two years ago, I worked with a full stack team of Developers at a Financial Services company on a cloud-based Liquidity management product. While this experience is vast and varied, one thing that remained constant throughout it all was my natural disinclination towards being considered a “technical person.”

I’ve always been a people person, gravitating more towards speaking with clients and talking big-picture strategy. I love solving problems and understanding what our clients want. So when I began a transition into a career in Product Management, I was forced to readjust my skill set to flex a different muscle — a technical one. Not only a technical muscle that needs to be strengthened but instead refined to incorporate the ability to the bigger picture. It’s hard to see the larger forest when you’re stuck looking up at a tree.

In my last four years in Product Management, here are the key lessons I’ve learned in how to communicate most effectively with Developers in a language that works for all parties.

1. Speak in synecdoche

I know what you’re thinking — ” Urvashi, what the heck does this mean?” At first, it may sound like I’m asking you to learn the regional dialect of a town in Upstate NY, but what I’m asking is for you to is to go back to grade school when you learned this figure of speech.

Synecdoche: Figure of speech in which a part represents the whole.

Features are rarely if ever, developed in one neat package. They are built piece by piece. Each toggle, button, and part of functionality has its own code, like pieces of a puzzle all being laid to put together a larger picture — so why shouldn’t the way you communicate to your developers follow the same framework? If you are adamant about sharing your grand vision to your full-stack team in hopes of inspiring them to do their best work on this feature — you need to check your audience. Developers are developers for a reason; they’re much smarter than you and need to understand the parts before they can understand the whole.

Save yourself (and your team) a lot of time by embracing the incremental and reacquainting yourself with the beauty of details.

2. Accept that the acceptance criteria will become your best friend.

It’s easy to forget that the level of exposure a PM receives, to not only the larger organization but rather the overall industry, is a unique function of the role. When you’re hopping on roadmap sessions and product roadshows with your stakeholders weekly, the big picture becomes an ingrained part of your process.

While it was essential to have ingested this information, it’s even more important to communicate it in a way that will resonate.

When writing user stories, making sure that the acceptance criteria communicate the context and exactly what the user experience should be is the most effective way to convey the larger purpose of the feature. It’s crucial to rely on your QAs to be the messengers and keepers of the keys to ensure that the feature aligns with your vision.

3. Accept responsibility when “defects” actually are “improvements.”

Owning up to your mistakes is vital. As a Product Manager, it’s important to never place yourself above others in importance — humility gets you very far. Miscommunications happen and although a “User adds SKU to cart” is simple, there could be many variations of this single action. Developers are militantly straightforward and color within the lines; that’s what makes them good developers.

If the final product is missing a piece you had envisioned, take a look at the stories. Did you specify the user funnel to get to that exact point? Are there any dependencies you overlooked? If so, take ownership and remember to utilize all communication resources available to you and your next team.

Do you have any suggestions on DevSpeak for Dummies? Drop them in the comments below!




A new tech publication by Start it up (

Recommended from Medium

Who is a product person, really?

Approaching the Project: Microfarm for Everybody

Tackling the Product Growth Question

Transitioning from Engineering to Product

Why Thinking Like a Product Manager is Not For Products Alone

What is the Jobs to be Done Framework?

What makes a good Sprint/Iteration review?

How to Not Suck as a New Product Manager — The 4C’s

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Urvashi Banerjea

Urvashi Banerjea

Social Impact enthusiast, lover of the written word, life long learner. Interested in all things Experiential, will work for Thai food.

More from Medium

7 Software Product Development Challenges

How to Plan, Build, & Run a Value Adding Web-App

Hacks and methods I used to accelerate my product development

Key 7 Stages Of New Product Development Process — To Know And Be Known

New Product Development Process