What makes a good product manager?

Last Friday was my last day at Google. I decided to join Google last year after AltspaceVR was acquired. After working on a series of startups, I wanted to see what I could learn about building products from a fully scaled product organization. As I move back into startups (hello Decentraland!), I’d like to share my observations on what makes a good product manager (GPM) vs a bad product manager (BPM) whether at a bigco or startup.

I’m going to use the format of Ben Horowitz’s original Good Product Manager/Bad Product Manager. As Ben himself warns, “this document was written 15 years ago and is probably not relevant for today’s product managers,” so I’m hoping my list can serve as a refresh.

Importantly, the GPM or BPM isn’t a single person. All PMs have moments when they’re GPM and moments when they’re BPM. The goal is to be as GPM as possible each day.

GPM vs BPM

The GPM knows the product objective and sets the team up to achieve the objective. The BPM is unclear about the product objective and as a result, sets unclear goals, which makes evaluation of success difficult.

The GPM identifies areas of ambiguity and proactively resolves them. The BPM gets blocked by ambiguity alongside the team, leading to delays and wasted work.

The GPM involves all of the stakeholders required to make an effective decision and enable follow-through. The BPM sometimes involves too many stakeholders, wasting time and increasing the likelihood that meetings go off track. Other times, the BPM involves too few stakeholders, leading to poor decisions or inability to operationalize.

The GPM prepares for meetings. There is a clear goal for each meeting and the GPM increases the likelihood that the goal is met by thoughtfully selecting attendees, preparing an agenda, and doing prework to facilitate the decision. The BPM sets up meetings hoping that the attendees will organically decide on a goal and path forward during the meeting.

The GPM proactively guides meetings towards achieving the goal of the meeting whether it’s their meeting or someone else’s. They help the attendees by identifying and clarifying ambiguity, taking side-topics offline, and summarizing action items. The BPM doesn’t listen carefully and barrels through agenda items without addressing confusions or conflicts. Oftentimes, the BPM’s meetings go off track and attendees leave feeling like the meeting was a waste of time.

The GPM makes decisions with evidence and sufficient consensus from key stakeholders. The BPM makes decisions with gut and authority.

The GPM isn’t the visionary CEO of the product, they’re a pragmatic product leader that helps the team make great decisions. The BPM acts like a product visionary instead of a product leader. Instead of helping the team consistently make great decisions, they seek brilliant Jobsian insights and prefer unilateral decision-making.

The GPM gives away all the credit and takes all the blame. The BPM does the opposite.

The GPM creates useful artifacts like product requirement documents, FAQs, communication documents, analyses, prior decisions, etc. that improve communication and strategic alignment across the team. The BPM tries to keep track of decisions and statuses in their head and wastes time answering the same question multiple times. Worse, the BPM wastes the time of teammates by sending them other peoples’ questions instead of documenting the answer.

The GPM knows when and how to escalate when an unexpected issue arises. They involve the right people and make the appropriate changes as early as possible. The BPM sweeps issues under the rug and surprises stakeholders with problems when its more expensive to fix.

The GPM is trusted by the engineers to represent them because the GPM is an expert on both the non-technical and technical aspects of the product. The GPM has invested sufficient time and has a sufficient technical background to grok the engineering behind their product. The BPM doesn’t understand the technical details and resorts to hand waving answers when technical topics arise–inadvertently spreading misinformation. As a result, the engineering team can’t rely on the BPM to represent them and meets with cross functional stakeholders without the BPM.

The GPM is zealous about the accuracy of data because the GPM knows that decisions informed by inaccurate data are worse than decisions informed by no data. The GPM verifies assumptions about the underlying data and has a functional knowledge of statistics. The BPM accepts data and analyses at face value. Over time, the BPM loses credibility when errors in assumptions or statistical significance are discovered.

The GPM communicates clearly and concisely. The BPM thinks out loud, wasting time and causing confusion. The BPM stops getting invited to high-level meetings.

This isn’t an exhaustive list. What else do you think makes a good PM? Let me know in the comments.