How Product Manager and Engineer Partnerships Lead to Better Outcomes

The story of a conflict I had in my early days at Amazon with a product manager, and my reflections on a Walk the Talk episode with the Head of Product for CloudWatch, Nikhil Dewan

My first conflict at Amazon was with a product manager. It was 2013, only a few months into my time at the company. I was on call when a script my team owned, the one that generated data for the weekly business review, went down. It had already been a tough day, packed with other high-severity service issues, and I was stretched thin. That evening the PM came down to my desk visibly angry that I still hadn’t fixed the script. I didn’t keep my anger to myself either. We had a tough exchange, my blood boiled, and I lost sleep over it.

I was frustrated that he insisted on the priority of a task I believed could wait until later that night. I didn’t take the time to understand that the script was generating business-critical, time-sensitive data and that the PM was blocked. I was also frustrated that he made it seem as if everything I had been working on all day was of lesser priority. I know that wasn’t his intent, but when trust isn’t there, each side assumes the worst of the other’s thinking.

Problems of a similar nature had come up a few times in my daily walks with engineers and PMs. That is why I invited Nikhil Dewan, Head of Product for Amazon CloudWatch, to record an episode with me. Nikhil and I have known each other for a long time and worked on many projects together. I have seen him cross the line between engineering and product many times.

What follows is that conversation, with some quotes lightly edited for clarity. You can also watch the video here.

Nikhil started our conversation with a great story. Working on an ambiguous project a few years ago, while he was preparing to meet customers, he had drafted a list of questions. Instead of treating it as a PM-only task, he shared it with his engineering partner. “We jointly put together the final list,” Nikhil said and continued:

The best part was the engineer was excited to join the customer calls. He didn’t see it as a PM responsibility. He wanted to directly hear the voice of the customer.

The collaboration grew from there. The engineer shadowed him, learning how Nikhil asked open-ended questions and avoided jumping to solutions. As the engineer got more comfortable, he began asking questions himself. After each call they debriefed together and compared notes. Over time they started to see patterns across conversations that shaped their design decisions.

Agreeing with Nikhil that this was a great example, I said, “Partnership is the key. If a PM or an engineer draws a line in the sand and says, ‘this is your responsibility, that is mine,’ that territorial behavior is not going to work.” I was pointing to situations where PMs or engineers expect the product to be fully defined by the PMs (in Amazon this means writing a document called a PR/FAQ, which defines the product as if we are releasing it to the public and answering customers’ questions). The same goes for expecting the engineer to own the entire technical design.

Nikhil agreed and continued:

The owner of the PR/FAQ is not just the PM. The lead engineer is a co-owner. And while I am not writing the technical design doc, I see myself as a very important part of it. These docs are not PM or engineering docs. They are docs we co-own.

He explained that he sees value in engineers developing product instincts too.

Something I am super passionate about is how to make the best engineer also a pretty solid PM. I love when an engineer can lead a customer conversation themselves because they are that close to how we gather requirements and dive deep.

Then Nikhil turned the question to me and asked if I had seen examples of strong collaboration. I remembered one: a PM who, after talking to a few customers, hacked together a quick prototype from existing parts. It was scrappy, but it showed the shape of the idea. That extra effort added to the momentum and gave me confidence we were in for a great partnership.

Nikhil nodded and brought the point back to trust:

What you are highlighting Mustafa is a core Amazon Leadership Principle: Earn Trust. Engineers earn a PM’s trust when they partner on customer requirements and think through everything from product definition to prioritization to adoption.

And for PMs to earn the trust of engineers, they have to be hands-on. It is a tough skill, but absolutely critical in a very technical company. At the end of the day, Customer Obsession means we need to know what the customer does, and what better way than doing it yourself.

When I look back at that conflict in 2013, I see it was never about priorities. It was about trust that had not yet been built. The PM didn’t take my word that I would eventually fix it later that night. I didn’t trust his word that what he needed was truly business critical. Over time that PM and I became great partners by making the effort to step into each other’s world.

What we touched upon in my conversation with Nikhil is something close to my heart: trust is earned, with intention and effort.

And when trust is established, the products we build are better.