A Product Manager’s Guide to Working with Developers (so everybody’s happy)

A Product Manager’s Guide to Working with Developers (so everybody’s happy)
4

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:

 

blog-banner-split-test-A-v1
Sumit-235x235

Sumit Suman

Sumit Suman is a product manager at Druva for inSync Share. Sumit has had a collaborative streak for a long time, which peaked when he started an online mentoring company, Mentii to help strangers guide each other's careers. He is a completely-recovered management consultant (so much that he hates PowerPoint now) and dabbled a bit in corporate venture incubation. Since he moved to Silicon Valley, he emphasizes his computer science and engineering degree, and tries to hide his MBA under the carpet.

4 Comments

  1. Dattatray Walunj 2 years ago

    I liked the ownership and handoff model.
    The awesome line – “I have to earn that trust – and only then can I demand it back.”

  2. Chandar Venkataraman 2 years ago

    Except for the word “handoff”, I like everything you say. I prefer not to view anything “handed off” in the 3-person-in-the-garage model.

  3. Mira Balani 2 years ago

    great stuff – completely agree!

  4. Sumit Suman 2 years ago

    Thanks Dattaray and Mira!
    @Chandar — yes, a few others have pointed out the same feedback. I agree that the PM should be involved concept to launch, and the bucks stops with him/her at every stage. However, Engineering team’s ownership cannot be understated. They live and die by the engineering design decisions and the quality of the code.

Leave a reply

Your email address will not be published. Required fields are marked *

*