Product Management

Good vs. Bad Product Manager

This post is an attempt to uncover what makes a good product manager. How do they handle a difficult situation and seemingly move ahead? It will help us understand how the best startup product managers exhibit a relentless pursuit of the truth and value speed of learning over the speed of building.

Who is a bad product manager?

A bad product manager is simply a micro-manager.

The number one trait to avoid is saying yes to everything. Whenever the client asks us to do something, and the answer is always “yes,” then we will fail. If one shows such complaisant behavior, then they are a bad product manager.

Product management is about making decisions and trade-offs, and if someone is saying yes to everything, then they are not doing a great job.

What kind of things should PM’s be saying no to?

One of the roles of a PM is to prioritize. Not everything is important, not everything is urgent, and one has to know the difference between facts and opinions. Figure out how urgent or important a task is, find and the root cause of why something is happening. Bad product managers say yes too much and as a result, cannot prioritize effectively.

Then what are the good qualities of a product manager?

A good product manager has their playbook ready. They have a step by step plan and a checklist from the discovery phase to identify potential problems and their proposed solutions. They also makes the playbook available to the team.

So what’s a good way to get the clients on board with this checklist? What if they say, “let’s move faster? Let’s get building. Let’s go.” How do we pull them down?

It comes back to having a playbook at hand with which we can educate the client about all the steps we are going to take. When a client wants to skip some of the processes and some of the steps, we can remind them of our defined process. By having a process ready, we can show them the consequences of skipping some of the steps.

As mentioned earlier, a good product manager is someone who can make necessary trade-offs and ensure the clients understand the consequences. For example, clients may suggest features or solutions outside the scope, even though it will slow the development process to add something. It is the product manager’s job to educate them of the risks, such as losing speed and time. If the client wishes to proceed, we will, but they will fully understand the trade-offs they are making. Before going to development, a good product manager would make sure that we are following the right playbook and choosing the right feature to build.

In this example, a bad product manager would say yes to adding features, in addition to trying to build quickly for the client. Eventually, they will fail because they have skipped playbook steps and bitten off more than they can chew.

When we are adding more and more elements to the product, most of our sessions are spent on making the clients happy and keeping the team on track, but at the end of the day, it’s about the product and solving a problem. So how do you stay focused on that?

It’s always helpful to break down the project from a monolithic product perspective to the different user journeys and their stages. When you can write down the user journey from where they start, how they interact with the product, where they have to end up, and how users can get value, then you have set the foundation for the entire journey for the years. The problem becomes self-evident by using this method.

In general, we have to first keep the user in mind, and then lay out their journey, layout their stages, and have that be the basis for the product.

It’s really easy to get excited about how the product can scale and where it can go, but how do you keep it simple and focus on the first problem before solving other problems?

Use the user empathy map. We list all the problems at the beginning of the project as a product manager. Then we talk to the users and do some user testing. We want to know if the list of the issues we are solving are the top three problems in our user’s mind.

So a bad product manager would see the other solutions without focusing on what the user needs from the beginning.

In a situation where you feel like you’re not making enough and not being productive enough, how do you make sure you are on the right track? What’s easy to measure, and what’s hard to measure?

What’s easy to measure is sprint velocity. However, to know if you are solving a problem or not is tough to measure.

In the initial stage, you’re solving the problem for the first time; the product doesn’t exist. Once the product exists in the market, and it is at the growth stage. When you are in the earlier stages, you want to fake it as much as possible with the prototype or customer interviews, because you won’t have enough traffic to do the qualitative/quantitative test.

Talk to a minimum of 5 real customers and show them the prototype, iterate, and foster interest in the product. You can use these new findings to write a press release. You write until your solution becomes clear after each iteration. To feed your writing, you talk to your customers who have real pain points.

A good product manager is someone that can listen to customers and clients and is also a writer. They can take what they’ve heard and turned that into a clear, well-written document. They prioritize writing until everyone around them understands or everyone around them can also write down the same ideas.

Synthesizing information is the heart of product management. You have many different voices talking to you, and you have to channel them together to create one voice. How would you do that without writing?

Different people have different ways of saying things. You asked the same questions to all these people, and they all answer differently.

A good product manager can not only write well themselves but make writing the habit of everyone around them, right from clients to people on their team.


  • Bad product managers say yes to everything.
  • Bad product managers are not good writers, and they don’t think writing as an effective means of communication.
  • By not saying yes, you are asking the qualifying questions, and ultimately giving space to your team to maximize collective brainpower.
  • Product management is not a one person thing, so for collaboration, you need alignment and synthesis, and writing is a great way to align people.
  • your users or clients may not like hearing “no” at first, but with time they will appreciate it when they see the effectiveness of the playbook in action.

More in Insights

How to Run a User Test? Product Management

How to Run a User Test?

There are times when product owners with brilliant product ideas jump directly into turning it to reality. They invest time,

Read more
How to Implement the CIRCLES Framework into a Services Company? Product Management

How to Implement the CIRCLES Framework into a Services Company?

As product owners, we think of brilliant ideas that can create an impact. We strategically build a team and start

Read more
Product Roadmap: How do we effectively make use of this tool? Product Management

Product Roadmap: How do we effectively make use of this tool?

Product Roadmap, some people love them; some people find them useless. People have divided opinions about this tool. However, when

Read more