Seven things great product managers do

...and you can too!

I have worked in and around product management throughout my career — across marketing, tech, and leadership roles. I have hired, trained, and learned from many product managers during my time at Amazon. I can tell you: great PMs are made, not born. They develop certain habits—and then practice them consistently.

A senior colleague who took on a Principal product management role recently asked me, “What’s the job really about? How do I become a great PM?”

This is the list I shared with him.

1. Get out of the building

I have conducted over 500 interviews at Amazon, and some of the best answers start the same way:

“I rode with the delivery van for three days…”

“I visited the construction site to see how they are using our materials…”

“I sat with the planners to watch their workflow…”

Great product managers get out of the building. They observe customers “in the wild”. They ask questions. They watch and learn. They don’t invent features in the ivory office tower — they scribble ideas on the train ride home from a customer visit.

Early in my career, I worked for a startup that built a document management system. Users complained it was too hard to use. Our developers disagreed — they thought the product was sleek.

I wasn’t a PM then — I was in sales and marketing. One day, my boss asked me to deliver a user training. That experience changed how I thought about the product.

I went to the customer office and noticed that the product users were middle-aged women, working on small, low-res monitors. They could see maybe 60% of the product page on their screens and had to scroll for seconds to find the “save” button (!). Watching them struggle was painful.

Back at the office, I asked our head developer — sitting in front of two giant monitors — to switch to 800x600. “Oh man, this sucks!” he said. We made everyone do the same, redesigned the interface, and the complaints vanished.

2. Dig deeper

Henry Ford once said that the secret to success is seeing things from someone else’s point of view. PMs know this in theory. But in practice? We show biased prototypes, ask leading questions, and interpret data through our own lens.

During my MBA, I interned at a medical device company, building a training portal for doctors. I presented a prototype of my product in a workshop to senior physicians. I got good feedback and lots of suggestions. But my internship would finish in six weeks, so I couldn’t implement everything.

During a coffee break, I asked, “Out of all the suggestions you made, if I could only do one thing for you, what should this be?”

The group paused. And then one of the doctors said, “Actually… you have one great app you use to train doctors. Could you integrate it into the portal so that we can teach our patients?”

The others nodded. That app hadn’t been mentioned until this moment.

After the workshop I found out that the app wasn’t patient-facing due to legal hurdles. I worked with legal, adjusted the terms and conditions, and got the approval for patient training.

Developer time? Zero.

Doctor satisfaction? 100%.

3. Bring the problem, not a solution

You may have heard the saying, “Don’t bring me problems — bring solutions”.

Scratch that. A PM’s job is the opposite. Bring the problem — well-researched, clearly defined, and deeply understood. The team will find the solution together.

Say, you discover that 50% of users drop off after first week of using the product.

A solution-first mindset says: send automated reminders in week two to bring them back.

A problem-first mindset says: let’s find out why. What’s broken? Are there bugs, crashes, slow load times? When do new users get real value? Walk through the signup flow with fresh eyes. Are we delivering on our marketing promises? What does the data say about Day 2, Day 3 retention? What features do loyal users love? Still unclear? Talk to ten churned users. Then to five who stayed.

The problem space is on you.

The solution comes from the team.

4. Think like an owner

If you owned the business and your receptionist called in sick, you’d greet customers yourself.

Great PMs show the same ownership.

Sit with developers. Push back on senior leaders when necessary. Kill your favourite feature if it’s not adding value.

I once took on a short-term technical debt: Amazon absorbed the cost that customers would have had to pay. It let us meet a hard launch deadline and was the right thing to do. Tech team committed to solve it in a quarter after launch.

Post-launch, I reviewed the data. We had overestimated the actual cost — by 20x. Fixing the tech debt no longer made financial sense (developers had bigger fish to fry).

My boss wanted to clean it up anyway. “The dev team will never know,” he said.

But it felt wrong.

I shared my numbers with the tech lead. We ran the cost-benefit analysis together. The fix would only pay off in five years — and the system might not even exist by then.

If this was my business, I wouldn’t waste the developer time. So I didn’t.

5. Develop good intuition

Great PMs rely on data—and intuition.

There comes a moment mid-sprint when an engineer says, “I’m stuck. Can we brainstorm?”

There’s no time for user research, data analysis, or manager approvals. You’ll go with your intuition.

How do you build that intuition? Do the reps.

Every user interview, every A/B test, every prototype you’ve seen—that’s training. It all builds intuition for these high-leverage moments.

Sometimes a 30-minute whiteboard session between a Principal PM and a senior developer saves weeks of engineering effort.

6. Delete and simplify

Elon Musk pushes his teams to simplify. Delete what isn’t needed. Cut costs in all components that are not adding value.

When developing the Model S, Tesla team required a battery test controller which cost $1M. Musk thought that was insane. He told the engineer to build one himself. The engineer ended up building a test controller for just $10K, using off-the-shelf components and clever design.

Recently, a Principal PM on my team tackled a complex data query. Prior to his efforts, the query took 8 hours to run and often timed out at the end. It wasn’t a bad query, it just had lots of data to handle. PM re-factored it using a new tech stack and some clever AI prompting. Now it runs in 10 minutes.

That’s a 50x improvement—and serious savings if we apply it across the board. (Wait… I need to talk to our Head of BI!)

7. Do great quality work

Prototypes can be messy. Final products shouldn’t be.

Great PMs ship quality. They allow time for testing. They design to scale. They sweat the details—even the kerning.

But quality doesn’t have to mean slower or more expensive. Done right, it’s efficient and robust.

I once had a small PM team delivering a high-stakes tax compliance project. Twelve tech teams dispersed from Bangalore to Seattle. A launch date on midnight January 1st (thank you, regulators).

This meant that they had to develop during peak season when retailers do the most sales and new tech feature launch is not allowed (this is called “code freeze”). Each tech team had different code freeze date, multiplying the complexity. Every week brought new scope creep or a roadblock. The PM team got so accustomed to surprises that when a week passed with none, they went looking for some. In essence, this wasn’t not the best environment to launch the best quality product. The team re-prioritized, took on tech debt, cut to the bone. There was quite a lot of duct tape holding it together.

They launched on time. Zero bugs.

More impressive? The system held up for years. No problems.

I’d trust that team with my life.

8 (bonus one) - Bring the donuts!

Want to win hearts? Bring donuts. Enough said. 🙂

***

That’s it for today. Thank you, as always, for reading and sharing your feedback—it means a lot to me!

If you know a PM who’d enjoy this, pass it along.

If you liked it and want to get more every other week - subscribe.

Additional resources:

A couple of books I always recommend for PMs:

Inspired by Marty Cagan – the PM bible. It covers every aspect of building great tech products, in a comprehensive and light-weight way. One fun detail: all the PMs in his examples are women. Men usually don’t notice this. Women do. Thank you, Marty.

Influence by Robert Cialdini – product managers must influence without authority. This book explains how—and why—it works.

Credit for the picture for this post goes to Dean Peters and his cool Product Manager image prompt.