I have had the good fortune of working with a terrific bunch of developers and software engineers on my team. I am well aware that my success as a product manager depends on how well I work with them. Overall, it is no different than any other working relationship, which thrives on context, trust, communication, and empathy. But I’ve learned a few things that, perhaps, others can learn from.
To influence a team smarter than me, I have to work hard. To convince them to spend tens of hours of effort into developing something, I have to do my homework well. There is a trick though: I don’t have to do the homework in isolation.
As a team we share every idea, every customer feedback, every complaint – and we do it early. New product features are borne out of these discussions. My job is to take the crux of this throbbing-thriving idea exchange and give it some structure – to discover, socialize, validate, prototype, rinse, repeat.
All this happens in front of the team and with their active participation. I take no product decisions behind closed doors. The team sees the idea take shape. It’s their baby, too, when it finally comes to them for development.
When and how we communicate is particularly important. While the team needs context, I do my best to be careful about separating referenceable information from actionable information. We use persistent chat tools for referenceable communication (Hipchat’s been our choice) so anyone can tune in or out as per their focus schedule. E-mail and Trello boards work better for actionable communication.
Ownership and handoff are critical. During the product design and validation phase, I’m the owner. The dev team provides input and recommendations, but the decision lies with me. The role reverses when I hand-off the product requirements for development.
This model works only when the team can trust that I have done my best, and vice-versa. I have to earn that trust – and only then can I demand it back. It is hard. For example, I did miss a few test cases on a couple of features, and we had to go back to the drawing board. But I gave my best effort, and the team saw it. We got better.
One more thing. Despite all our best intentions, things do go wrong. It is not the end of the world. In a high-pressure delivery environment we can’t make a trend of this; if that happens, it probably points to a deeper rot.
Thankfully, it is quite possible to rally back from most setbacks. Delivery dates do get missed. Bugs get shipped. Customers get pissed. Sometimes. We do a post-mortem, correct our course based on what we learn, and we move on.
I hope this post reaches product managers and developers who have had a far greater and varied experience than me. I’d love to learn from you. Please do share your experiences.
A plug for the wonderful developers who helped me understand their mindset better:
- Nitin, the swiss knife of a person. A developer, designer, product manager rolled into one package.
- Andrew, the builder turned engineer and probably the smartest person I have interacted with.
- My (past and present) Druva team – Chinmay, Sameer, Abhijit, Saurabh, Agni, Alok, Naveen. With folks like them, no wonder Druva produces the #1 product in a cutting edge market.
An earlier version of this post appeared on Sumit’s Suman’s blog.
Get a free trial of Druva’s single dashboard for backup, availability, and governance, or find out more information by checking out these useful resources:
