Dear Engineers: 3 Phrases to Make Product Managers Love You Right Away
Incorporate these phrases to work effectively with Product Managers
This is a follow-up article after writing Say These 4 Phrases to Make Engineers Love You Right Away.
Product Managers are responsible for the what and why behind solving a user problem. We lean on engineers to tell us how to make that happen.
Speak your mind. Don’t hold on to your questions and ideas. We want to hear your perspectives to ship great things.
These phrases are music to the Product Managers’ ears.
1. “Could you clarify what is the expected behavior when this happens?”
Why do Product Managers love this?
- Account for scenarios that we have not thought about. Even if the timeline doesn’t allow us to solve this, we can measure the likelihood of this happening post-launch. If it impacts a large number of users, we can plan and address it in future sprints.
- Demonstrate that you are engaged. We dread dead silence after spending hours walking through our specs. Did it make no sense to you at all? Even if the requirements are truly too vague, it sounds more positive than “they don’t make sense”.
- Show that you are just as excited about the problem as we are. Just like we are thrilled when you ship features that you spent days coding. Product Managers spend days researching and writing the specs. Who doesn’t want to see others getting excited about things that put a lot of effort in?
Want to be prepared and ask intelligent questions in backlog grooming meetings, read this post on how to pre-plan with your Product Managers.
What to do after you said it?
- Ask for designs or sketch them out. Visuals are best used for explaining interactions. For example, what happens after users click a button? Get the design of a success message. If there is an error, should we alert the users and stop them from proceeding?
- Explain how your code works and what you can implement. This helps the Product Managers understand the current possibilities without having to write extra code. If your code throws an error when users enter a symbol, we can add tooltips or prompt users to remove the symbols. If it takes you only half a day to implement something that accepts symbols, then the Product Managers won’t need to defer the feature to the next sprint.
2. “I can explain the technical details to you”.
Why do Product Managers love this?
Product Managers craves understanding the technical concepts so we can follow your conversations. We worry about looking dumb in front of all of you. We don’t want to have you spend hours explaining something to us when you could have been coding.
If someone offers, it takes away our fear and we will take up the offer any day.
What to do after you said it?
- Walkthrough the architecture and data model. Start at a high level and use flow charts to explain how systems and services interact with each other. To make it relatable for the Product Managers, use a feature that you two built together to explain how the data is received and processed from one service to another.
- Suggest any resources or documentation to read up on. This can include API docs or readings that you would give to junior developers who join the team. Offer a few keywords that the Product Managers can search for on their own.
Are you a Product Manager looking to be “more technical” without learning how to code?
3. “I can ship what you ask for — if I can do xyz”
Why do Product Managers love this?
Examples of xyz can be reducing scope, asking for another resource to purchasing another 3rd party tools.
Which Product Managers don’t want to get their features ship on time with fewer bugs? You know more about the codebase than we do. Speak up if there is an alternative way to implement this better.
What to do after you said it?
- Show the benefits — What would the Product Managers get if they follow your recommendations? Does it save time, improve quality ,or enable us to build other features on the roadmap?
- Explain your plan — A concrete plan makes your recommendation sounds more realistic. Are you decomposing the features into smaller tasks — so another developer can work on them in parallel? For example, someone builds the APIs while another person works on the front end.
Sum it up
I and any Product Managers want to help you be more productive and get the features into the hands of our users. If you are stuck or confused, we are here to “play defense, so you can run as quickly as you can”.
Want to work more effectively with engineers?
Check out these related articles:
Download my book How to work with Engineers
