Relationship Goals: Ignite Your Dev-Product Relationship

Table of Contents

The R&D team at every company is made up of a variety of personalities- developers, tech leads, team leads, you name it. The Product team is also quite a diverse group and is usually made up of creative UI/UX designers and product managers. When you throw them together, you get a meaningful relationship that creates magical features for top-notch products. 

When I first joined Rookout’s product management team, I told myself that the job and working alongside developers would be as easy as breathing. As it were, I had been a developer previously before I decided to look for a career change. I found myself continuously reminding myself: “You used to be a developer, you’re a developer at heart, you know what developers want”. Sounds like a recipe for success, right?

Well, I quickly learned that having been a certain kind of developer at a certain company doesn’t mean that I know and understand all developers. Developers, much like snowflakes or McNuggets, come in different shapes and sizes. Understanding this was the easy part. The challenge, I soon came to understand, is to help your team understand it. 

The relationship between developers and product managers has been challenging since the beginning of time. There is a continuous dissonance- developers want to reduce tech debt and use cool technologies, while product managers want data and “boring” features that help sell the product. Relationships are hard and take work, patience, and a whole lot of compromise - and none more so than the relationship between developers and product managers.

Managing a product for developers, made by developers, can be even more challenging. Let me take you on a quick relationship therapy session and give you my tips on how to keep the love going. 

Understanding Goes Both Ways

When pitching a new feature design, the discussion and debate over it is sure to be kindled quickly. The most important thing to do when this happens is simple: listen to each other. 

  •  Each developer on the team has at least two opinions and is sure that this truth is absolute. As a product manager, you have to listen carefully to understand where developers are coming from. 
  • Product managers’ motives are not always clear to the R&D team, but it’s their job to make sure the developers understand the reasons behind these ideas. And truly, this goes both ways.

When working on a technical product, it’s important to remember that not all developers are the same. Some of them work in huge monoliths and some with microservices. Some devs are tech-savvy, living and breathing code, and some are familiar with just one language. It’s important to understand the type of developers you’re working with versus the type of developers the product is meant for.


The relationship can be damaged when product managers and developers don’t agree, or decide on a feature without any explanation for why. It’s critical to make yourself understood, no matter which side you stand on. 

That being said, remember that, unfortunately, you’re not always right. Understanding each other has to be followed with an open mind, and both sides have to accept the fact that sometimes someone else is right. You’re there to succeed together, and it doesn’t matter at the end of the day whose idea specifically was chosen. It sounds a little bit like a Sesame Street episode, but what can I say? Sesame Street is always right! 



Communication is key

Simply saying “this is my decision” doesn’t do much for, well, most people in general. 

Keeping the team engaged by introducing them to the user’s story - such as sharing quotes from meetings with them - helps them to understand the other side’s pains and needs. Presenting real conversations and telling the story with the user’s words creates a new dimension and depth to the story that can not be done in any other way.

Make sure to back your arguments with data. Show the users’ behavior and use tracking tools to display real sessions and share screen recordings from meetings with customers.Try to use numbers and facts. Ultimately- keep your team engaged. Spice it up! The more they know, the better they’ll be able to perform and work alongside you. 

It goes the same for all developers in the team. Simply saying “it will take way too long to develop”, or “it’s impossible” won’t do much to help product managers understand. Even if you are 100% certain that a specific feature is wrong to develop for technical reasons, the product manager doesn't always understand that. Oftentimes, they require a slow and detailed explanation. Relationships take patience and ultimately, it will help the team deliver faster.  



Pick your battles

Developing a product is much like arguing over what to order for dinner or whose turn it is to do the dishes.
When doing so, it is important to remember: you don’t always have to win the argument. Sometimes, it’s perfectly fine and actually recommended, to take the back seat and let someone else decide which route to follow.

Let’s take a look at a classic example that occurs, no matter if you are a product manager or a developer.  A new feature is coming up and the team needs to choose the right color tone for a very small icon on your ‘About Us’ page. It’s important, right? Definitely. It is so important that the room erupts as everyone voices their opinions, and it seems like anyone has its own five opinions. Everyone is, of course, 100% sure that they are right. 

Well, you can sit there and argue for hours, fight, and make sure that your specific idea will be the one chosen. Or, you can decide that there are more important things than winning the fight, and simply move on. Choosing to avoid this battle will actually help create a better relationship and help to gain each other's trust. 

And on that note, as with any relationship, it’s critical to earn your team’s trust and to earn yours. It’s not only easier but necessary, to pick your battles and fight for what’s really important. So leave certain decisions to your partners. This way, when something is really important, it will be quick and easy to get your way. It is a give and take relationship, so make sure you know what are the truly important decisions that are worth fighting for. Anything else should be discussed and decided together as a team. 

Make decisions together, as a team

Being a team player is not just something to write on your resume. It’s key to working together to create great products.

It might sound like a bad cliche, but it’s a true one: It's not a race, it's a marathon. You will continue to release features, fix bugs, and design together for a long time. When the decision is made by only one person, even if it’s the best thing to do if the whole team is not up for it the marathon will be harder to complete.

It’s important to remember that whether you are a developer or a product manager, you are a part of a team. Therefore, the team should be synced, aligned, and all should trust the final decision. Moving forward with the next steps and decisions will be easier if your partners are working arm in arm with you.  

Sometimes, someone else knows better 

Product managers have to know their users best. They need to be able to be familiar with their pain points and struggles and ultimately understand best what they need.

In every product, some decisions are made purely on a tech basis. As a product manager for a technical product, it's essential to be familiar with the technology, to know how developers work, what they do every day, and the meaning of using different languages, frameworks, and terms. 

Sometimes, the fact of the matter is that you’re not the most technical person - or most learned person - in the room. This even more so when you are managing a product and your persona is a developer. 

When the team decides to support a new language or add a new feature about a trendy, technical topic, it’s ok - and even recommended - to approach the dev team and say “your knowledge is way deeper than mine, can you explain it to me?”. It’s good to do your own research, but it’s also good to go and ask someone who knows better.

Much like if you had to cook an omelet with Gordon Ramsay around, you would definitely ask for advice, even if you are familiar with how to properly cook eggs. Same with developers- even if you know the language or the tech, it’s worth asking for deeper insights where you can.

And devs, we all know that product managers can oftentimes ask too many questions and usually at the worst timing. Sometimes, the questions don’t make the most sense. And yet, it’s important to take the time and help the product manager on the team to make sure every last detail is understood when it comes to new features. Don’t be the Gordon Ramsay of your team. Help the product managers understand how to make the tastiest omelets! 









Finally 


Well, for better or for worse, product managers and developers are in this relationship together. There’s no point in fighting over who's right or who's stronger. The journey is done together, hand in hand, and as long as the team is going in the right direction, it really doesn’t matter. 


Working together will not only create a positive workspace but lead to better relationships and improve your coffee break experience, which we all know is what truly matters ;) But really, it will also lead to a significant improvement in both developer and product workflows. By establishing good and strong relationships within your team, you’ll be able to increase velocity. This means that you’ll be able to deliver faster and fix bugs quicker, and thus help to guide your company in the right direction. 

Let’s be honest. At the end of the day, it’s all about speed and quality. And by keeping the love not only alive but thriving, between devs and product, you’ll make sure that your company is experiencing faster quality feature delivery than ever before- and you’ll guarantee a perfect journey together to a better product. Trust me, as someone who’s been there, it’ll be worth it.

Continue reading

No items found.
No items found.

Getting started is a breeze