How to Talk Dev-ish in a Product World

*This is part of an ongoing series from Rezilion titled Enlightened Engineering: Reflections From Rezilion’s Tech Team

By: Hadas Schlessinger, Product Manager, Rezilion

Picture the following scenario –  you find yourself in a room full of developers, talking about technical challenges regarding a planned feature and the potential solutions to overcome a challenge. You might wonder what the hell they are talking about when so many technical terms and abbreviations are mentioned  – leaving you with more questions than answers.

I’m writing this post because even as a past developer, I’ve found myself in this scenario more than once – even technical people don’t always understand and communicate fluently with dev teams.

Today I want to set out some practical ways to overcome the “I don’t understand” feeling, using my own experience as a past developer that currently manages the same product I used to develop.

The Problem – When Requirements and Outcomes Don’t Match in Dev

Let’s focus on some pain-points that are found in dev-product communication, especially when working in early stage startups.

The Gap Between Expectations, Requirements, and Reality

As a PM you think big, explore the market, and try to base your requirements on a variety of sources (which might be limited and biased.)

In reality, sometimes developing them will require time and resources you don’t have. You need to work with the dev team to understand what can happen, decide what the must-have items are, and how to deliver on time. This might result in a very long discussion, ending with and abridged version of your original dream.

You Don’t Always Understand What They’re Talking About

Unfortunately, it’s not always about the outcome, sometimes it’s about the journey on your way to reach the desired end state.

The dev team is a very smart and professional group. As such, they talk fast and think faster. You need to take an active part in a fast-paced discussion. Being the least technical person in the room feels like a disadvantage. Because of the limited time available for learning and improving technical vocabulary, you may feel uncomfortable, insecure and subsequently withdraw from the discussion.

As technical PMs, we need to communicate with developers to gain a better understanding. It’s not only about finding the right words, it’s about trusting each other and finding the best way to collaborate. This is what the next section is all about.

How to Talk Dev-ish

As a former developer and current PM, I’ve listed several points that will help leverage your communication and gain trust:

Motivation First

People don’t only care about what their goal or assignment is, but also about the reasons behind it. Setting the values and reasons driving the assignment can encourage motivation and improve the result of the feature.

This is key for gaining trust, as well as inspiring people to do “extra” work and think bigger. It’s also much more fun to work on something when you understand its impact.

Try sharing some of these:

• Why we’re doing this assignment
• Why it’s important
• What value it’ll bring to the company
• What will the user gain from it

Questions Are Your Best Friend – Search for, Learn, and Ask What You Don’t Understand

We will never know everything. No one expects us to. The trick is learning how and what to learn. Besides exploring online, you should also ask questions. You can ask anything – from technical terms to product behavior.

If something seems unclear, ask to dive deeper. If something’s not working, ask why it isn’t.

If you’re not sure about the limitations or stages, ask to verify.

It can be a developer you get along with, your group leader, or just someone that was active in the discussion. Find someone you feel comfortable with and ask. Using questions is an effective way to learn a wide range of subjects. From professional topics to communication, it’s important to keep a balance between what you want to ask and what you can learn on your own. This way, you can get the best of both worlds.

Don’t Be Afraid to Present Your Opinion

Although you may not understand everything, you probably have an opinion that originates from a product perspective.

This opinion should be presented.

By challenging devs you actually make the product better. You should take the time to listen, ask questions, verify your thoughts and learn, but you should also share your opinion, plans and reasons for choosing every requirement or feature. Communication is most efficient when it is bi-directional, and only by exchanging your thoughts, opinions, and knowledge will you build trust.

Be a Team Player – Consult, Make Room for Collaborations, and Get Ready for Changes

When it comes to bi-directional communication, listening is part of the equation.

No matter how great you are – no one wants to work with someone that only considers their own opinion. Being a team player is almost as important as describing the perfect roadmap.

My best tip is to share, consult, and give devs an opportunity to be heard. You will be surprised by the amount of great ideas you’ll get. Be open to changes based on the feedback you receive – not just as a gesture. You should adopt the ideas that empower the product. In addition to helping you communicate more effectively, it will also enable you to ask questions – which, as mentioned, are an important part of the process.

The Value of You

You should always be able to present “the value of you” – how you benefit other’s work and how you can help them succeed at their job. For that, there are four things you can do:

1. Master Your Field: The most important thing is to know what you’re talking about, base your decisions on data, and have reasons for every item you choose. You must know your users and market, always learning and broadening your knowledge. Then, leverage communication with reasonable explanations.
2. Make Room for Others: Remember, it’s not only about discussing your requirements, but also about being able to change them in light of other people’s suggestions. Consider involving other stakeholders in your design process before providing your final requirements. I suggest scheduling a short discussion and consulting with your team before the official handover. Even if you master your fields, there are things you probably haven’t thought about. Consult others.
3. Share Your Future Plans: It’s not only about knowing and learning, it’s also about sharing your plans with other stakeholders. It will get people onboard, allowing them to think wider and further in the direction you’ve presented. Without a clear vision and plan, people tend to create their own – and it might not be in the direction you intend. You should share your vision, roadmap, occasional research, and future releases on a regular basis. I suggest starting from a bi-weekly or monthly road map and releasing a presentation for every stakeholder. It shouldn’t replace the day-to-day collaborations, but rather make them more efficient as you are also keeping the future in mind.
4. Build Your Message to Suit the Stakeholders You Are Meeting With: You should know your audience. Since different personas have different things in mind and a different agenda, your message might differ too. Before presenting your goal, plans, features, and question to someone, think – What do you want to say? What is your goal? Why do they care about your message? What is their interest? How can they assist you? You should build your agenda in the framework of your answers, and deliver your own value (for them), along with your message.

Be A Communicator

Devs are not the only ones that you collaborate with. As a PM, you need to send messages to a variety of stakeholders. It’s all about how to communicate and formulate messages in a way that you can engage many stakeholders. Often, you have the same agenda or message, but it needs to be communicated differently depending on the audience.

This is a skill that PMs really need to master to be good at their job. The person who is the least technical in the room might be the best communicator. Define yourself a goal in order to master communication, think about the message and person you’re talking to, and communicate it in a way they will understand.

I believe that motivation, asking questions, sharing you opinions, bringing value, and most importantly, being a team player, are all core tenets for becoming a highly effective communicator.

In essence, it’s more about communication skills than technical knowledge. Remember to think about and share your agenda, to learn by listening, to ask more questions, and to bring the value of you to the table with stakeholders.

This is the time to become the communicator you are – irrespective of how technical you are.