Read on Twitter
As an early PM with 1-2 years of experience, one of the biggest challenges is to win the respect and trust of your devs.
Here are 3 simple points that might help you with it - I wish someone had told me this when I’d started back in 2012
Here are 3 simple points that might help you with it - I wish someone had told me this when I’d started back in 2012
**Learn their world & language**
In my experience, this is one of the best ways to start building rapport with devs. You will be pleasantly surprised by how often they oblige.
In my experience, this is one of the best ways to start building rapport with devs. You will be pleasantly surprised by how often they oblige.
Note - Be respectful of their time when asking for their help to explain underlying systems --
- When a customer clicks this button, which API is called?
- Which db stores this information?
- What are the other dbs that need to be joined to send back this response?
- When a customer clicks this button, which API is called?
- Which db stores this information?
- What are the other dbs that need to be joined to send back this response?
* If you are wondering if this is necessary, well it’s not. But know this - the real world (your customers, your colleagues, leadership) expects you to know this. They are always looking for an authority on the product. If it’s not you, they will find someone else
* If you have ever been part of a sales call, you know that clients come with their own wish list of “A,B are good, but can you also do Z”? More often than not, sales lead will either agree w/o knowing, or look at you. How can you know if Z is possible? By being an authority
* If nothing, do this “just” because other PMs won't do it. It will lead to huge information asymmetry → Incredible brand equity for you. I’ve seen PMs score brownie points with Nadiem(CEO Gojek) in meetings because they knew answers to his runtime questions, while other didn’t
**Justify their efforts**
Devs value their time. A LOT. Explain how their unit of work converts to a unit of value, either for business, or for your customers, or for team’s productivity. Don’t expect them to write code just because you asked them. They won’t (and shouldn’t).
Devs value their time. A LOT. Explain how their unit of work converts to a unit of value, either for business, or for your customers, or for team’s productivity. Don’t expect them to write code just because you asked them. They won’t (and shouldn’t).
* Give them evidence & context on why a particular feature is being built - give examples from competitors or from other teams. Show them research, or simple surveys that you had run to provide evidence of the problem....
...Get data from “a world without this feature” and point out the problems your users/business are facing in that world. Make them see that what you are asking isn’t a “blind” leap of faith
* Reporting how a feature did is often the simplest thing that you can do to build confidence. It is your job to update about how a feature fared, did it move any needle, did management/customers have any comments.. If you don’t do this, devs on your team will make you do it
**Include flowcharts**
Developers think about the world in a very different way. They love structure, sequence and logic
Any document that includes flowcharts allows them to read the content in similar ways. More importantly, it helps them ask more questions
Developers think about the world in a very different way. They love structure, sequence and logic
Any document that includes flowcharts allows them to read the content in similar ways. More importantly, it helps them ask more questions
* If your devs are not asking questions after reading your document, that’s generally a bad sign
* These flow charts are also super helpful & important for QAs who can easily extract test cases from them
* These flow charts are also super helpful & important for QAs who can easily extract test cases from them
Summary:
1. You can’t become an authority on your product if you don’t understand the world and language of those who built it.
2. Let your devs know how their efforts add real value to your users/business/team before you ask them to code.
1. You can’t become an authority on your product if you don’t understand the world and language of those who built it.
2. Let your devs know how their efforts add real value to your users/business/team before you ask them to code.
3. Include flowcharts in your documentation and stories. It speaks to them easily
4. Bonus point- Don’t offer solutions.This is very tempting because offering solutions makes us feel better and smarter about ourselves. However, as the champion of your customers and users out...
4. Bonus point- Don’t offer solutions.This is very tempting because offering solutions makes us feel better and smarter about ourselves. However, as the champion of your customers and users out...
...there in the real world, your job is to paint an accurate landscape of their problems.
If only I had a penny every time my enthusiasm was cut short in intense brainstorming sessions by a dev saying “Don’t solutionize” :)
/End
If only I had a penny every time my enthusiasm was cut short in intense brainstorming sessions by a dev saying “Don’t solutionize” :)
/End
