How do you define a good PM vs. a bad PM?

Question

How do you define a good PM vs. a bad PM?

Asked at Google over a year ago

3.2k views

Leadership and Development

google

Meta (Facebook)

& 1 other company

Leadership and Development

Asked at

google,

Meta (Facebook)

& 1 other company

3.2k views

Top Google interview questions

What is your favorite product? Why?89 answers | 263k views
How would you design a bicycle renting app for tourists?62 answers | 82.5k views
Build a product to buy and sell antiques.54 answers | 66.8k views
See Google PM Interview Questions

Top Leadership and Development interview questions

How do you say no to feature ideas or requests?19 answers | 26.5k views
How will you manage a team where team members are more experienced than you and hence don't respect you?3 answers | 1.4k views
Tell me about a time you disagreed with engineering and what the outcome was.3 answers | 3.2k views
See Leadership and Development PM Interview Questions

Invite members
Invite by email

Add another

Vishal Shah · Answer 1 · 2021-03-13T06:11:15+0000

Interesting one. In my eyes, below are absoultely essential things for one to be a good PM:

1. Empathy for not only the customers but all the cross-functional stakeholders

2. Deep understanding of the domain (payments, cybersecurity, AI, APIs, Sponsored Ads, etc.)

3. Understands the company vision/mission, product's mission / vision, immediate business objectives, customer types and sub-types and their pain points.

4. Communication / Clear and succint documentation

5. Relationship building skills

While those are key essentials, it's also essential to have great Project Management skills.

productmanager1644 · Answer 2 · 2021-02-03T00:07:46+0000

In order to define a good v. bad Product Manager and to answer this leadership and development interview question, I'd first like to define what a Product Manager does.

Product Manager Overview: A PM guides every step of the product's lifecycle from development. To build the best solution, they advocate for customers and maintain a pulse on the external marketplace. PM work is an intersection of Business, UX and Technology.

Business: PM wants to help the team achieve business objectives by building the gap between Development, Design, the customer and Business.
UX: PM focuses on user experience and represents the voice of the customer.
Technology: PM maintains a close relationship with Technology and has a sufficient grasp of technical builds / functionality.

In order to do their job, the PM must focus on three main areas / themes: 1) Product Strategy / Vision, 2) Product Build and 3) Partner Management. Within each of these themes, I will discuss what traits of a good v. bad PM.

PM Traits:

Theme	Trait	Good PM	Bad PM
Product Vision / Strategy	Long Term Vision	Understands long term vision of product. Can come up with creative ideas for team that tie into vision.	No broader vision of how product evolves. Short sighted.
	Company Needs	Aware of how product ties into broader company strategy. Maintains grasp of where company is headed.	Unaware of how product ties into broader company goals. Does not maintain pulse on other initiatives across company.
	Customer Needs	Deep understanding of customer needs and behavior. Direct insight into customer. Acts of voice of customer.	No view of customer. Allows Sales, Customer Support, etc. to manage customer relationships in silo.
	External Market	Aware of competitors in market place. Understands what it takes for Product to be competitive.	No awareness of other competitors. Builds with tunnel vision.
	Focus and Simplicity	Understands power of focus / simplicity.	Always thinks more features are better.
	Data / Experiment Mindset	Balances need for data / experiments with a respect for vision, risk and intuition.	Either end of spectrum: only uses data with no risk / vision or only thinks about big ideas with no business case / metrics to back up.
Product Build	Build Focus	Understands outcomes / deadlines are necessary. Delivery mindset. Healthy balance for knowing when to focus on short term build v. longer term, more scalable build.	No understanding of deadlines. Isn’t pragmatic about delivery dates. More concerned with brainstorming features as opposed to building them. No concern about scalability of builds.
	Tech Understanding	Solid understanding of how product is built / function. Willing to get into the weeds to solve problems when needed.	Leaves all solutioning to engineers. No understanding of product functionality at high level.
	Build Awareness	Aware of similar builds or functions that exist in company or within Product that can be leveraged. Points out where there are duplications to avoid redundant building.	Unaware of other Enterprise initiatives. Too zoomed in on specific product feature to note when it may be redundant.
	Limitations	Understands capacity / resource constraints. Manages effectively.	Thinks engineers just need to work harder or more funding automatically solves problems.
Partner Management	Lead v. Serve	Understands when it is important to step up / lead a discussion but also acknowledges when they need to serve.	Thinks managing people means telling them what to do all the time and how to do it. Does not “get hands dirty”.
	Communication	Strong communication skills. Keeps all relevant partners up to date.	Poor communication skills. Partners are left in the dark / not aware of important updates.
	Expectations	Manages expectations. Knows when to say no but ensures people feel listened to / heard / respect.	Provides false promises with no intention of delivering.
	Roles and Responsibilities	Understands clear delineation between roles across team. Willing to support teams when needed but does not overstep.	Meddles in every area. Takes control of area they know best.
	Documentation	Keeps sufficient records of important decisions being made, reasoning, etc.	No documentation. Partners who join have no materials to review / little insight into what is going on.

Krishna · Answer 3 · 2024-06-29T19:18:14+0000

All answers are very good. Few points in top of them I would cover is

1. A good PM networks a lot, inside the organisation and outsie the organisation and keeps tabs on whats going on froma ground level this way. By talking to internal teams, a good PM can maybe uncover how problems are solved in other places and if they spot any functioniality which is already solved by others, they could discuss with those internal team on how best to make use of it so that i gives maximum ROI with minimal effort
2. A good PM would rally everyone to achive the goal rather than ordering teams what to do. He raliies by making clear the vision, objectives and companny objectives that will be met by this product.

3. A good PM never says NO without proper diagnosis and always complements whoever brougt the feature requests even if in the end those features dont end up on the roadmap

Clay Nichols · Answer 4 · 2022-03-30T15:03:17+0000

Let's start with by defining the PM's job (or outcomes)

The PM is there to help everyone else work better together. Be so helful they ask for more help.

The PM also has the responsibility for knowing about the exeternal and internal environment for the Product:

Internal
1. Business needs
2. Needs of each departement (marketing, etc.)
External
1. Competition
2. Technology ecosystem
3. Customer needs

There's a lot to that, and I'm happy to elaborate on the above, but software skills are often missed because they aren't explicit. Can I focus on software skills?

Interviewer: Yes

PM Analogy:

It's kinda like spinning plates (that are spinning atop poles). The plates just need a little touch here and there to do their job. A big part of this is helping the team communicate. Reminding everyone of the big picture goals and then stepping back to see who needs help. Pms also often have very little authority. So you have to help in a humble supportive way.

I'll start with the Bad PM because it's easier to spot the failure modes.

Bad PM

I'm formatting this as:
Symptom. Result. Cause

Neglects parts of the Big Picture and gets to involved in ground-level detail stuff. This might be "stepping" on the engineers' toes, and also distract the PM from "big picture stuff". More comfortable with previous role (as software engineer) so tends to get "in the weeds" and does programming. May not understand the value (or be comfortable with) sticking to the big picture.
Critical and points out errors team is making.
Team doesn't feel safe in taking risks (like learning/using new technlogy). Feels insulted or embarassed. Afraid to admit a mistake. She feels her job is to find areas of improvement for team. I.e, pointing out errors. Doesn't assume everyone already wants to do a good job and mistakes happen. And people may be self-conscious about their weak areas. Pointing them out makes them feel more self-conscious. You have to feel safe to admit you have a weakness before you can focus on it to improve it.
Doesn't communicate WHY things are being done.
Team loses their sense of purpose. Might thing (some of the) work is meaningless. Might disagree with decision. Might have a better way to address the WHY but doesn't suggest it because they don't know the WHY.
PM may not understand the WHY. Maybe it wasn't explained to them. Or doesn't think there is time. Or feels she "doesn't need to justify why ..."
Overcommunicates. Gives too much detail.
Team is ovewhelmed by too much communication. The PM sends long emails. Then reads them aloud to the team.
PM may feel she has to JUSTIFY everything. May ot have clarified her thoughts before communicating.
1. SOLUTION: Limit the length of communication. Make it clear what part you really want them to read and what's optional. Or leave out the optional part but let them know you're happy to answer questions.

Good PM

Takes a "coaching" approach whenever possible.
Make sure everyone understands the goals and the user. Communicates how everyone is impacting the user (and when needed: each other)
Treat everyone like a reponsible adult who's trying to do a good job.
Doesn't interfere or micro-manage.
If someone doesn't seem be be "delivering" then investigate with curiosity. Communicate, gently, what the expectations are. Once they realize they aren't meeting expectations, be a sounding board to help them improve.
EXAMPLE:
1. Ideally, have an escalation in mind:
  1. Hey, can you take a look at the spelling in these user messages in the code you checked in?
  2. What did you find?
  3. Are you sure they're all spelled right?
    (Might double check now)
  4. If mispellings continue, repeat #1 once or twice. Keep close eye on it.
  5. If problems persist then sit down make sure the understand the importance of this ("Mispellings might confuse the user and just makes the program look less professional)
  6. Let know (gently) that we're still getting spelling errors. Any ideas on how we could improve this?
  7. Let them try to come up with ideas. Be there only to answer their questions. Let them take the lead.
Aware of everyone's emotional state (as best you can). Noticing if folks are having a bad day. Let them know you notice but don't intrude : "Hi jane, you seem frustrated today". That opens the door to let them share if they want to (or correct you if you got it wrong).

Would you like me to elaborate more on the what other information the PM should have? (like competitor analysis etc.)

Interviewer: No, that's good.

NanZRH · Answer 5 · 2022-02-22T01:40:33+0000

I see this as an ice-breaker question. This is the first answer that came to my mind. I chose to keep it high level and allow the interviewer to dive in, if they feel its necessary:

A PM needs to build the right thing, at the right time for the right cost.

The right thing is one that is useful, usable, feasible and viable. For this, the PM works in a cross-functional team to understand the user, align with business strategies and build for the real world with the design and technology teams.

There will be plenty of creative trade-offs along the way and a good PM is one that isn’t afraid to learn through the product, admit they’re wrong, say no and step in to do whatever is necessary to get the job done, while always having an eye on the vision and strategy.

A good PM imparts energy and ensures that everyone is moving in the right direction. They have empathy and curiousity, and strive to understand the motivation of the users and those around them. A good PM listens and is a great communicator. They maintain the team's health and motivation and encourage everyone to grow with them. They inspire.

The only PMs that are bad are the ones who aren’t learning along the way.