10 Common Product Manager Mistakes to Avoid

I've been a Product Manager for well over 14 years now. I've made mistakes, experienced success & failure, learned, read and gained skills in this space. Also along the way, I've gotten lost and worked on things that moved the product but not in the right direction. This article covers my mistakes and perhaps you can learn from it and not do the same. 

My notes are short and to the point. I want you to read them quickly, and apply them to your work.

Follow me: Linkedin, Instagram

?? My latest project AudiBrow - listen to news from TechCrunch, Cnet, Reuters, Paul Graham, and more

1) Not knowing who your end-user is

Every founder knows this, and so should the Product Manager. Everyone is NOT your customer. Everyone is not going to use your tool/service/product. 

What you are building is most likely for a specific type of issue/problem, group, or community. Your product/service/tool does something to solve a problem or help perform something better than the current solutions in the market. Who is that person or company out there that needs to do that something but can't do it, or not it as well without your product? That's your customer, so focus on them. When developing your product over time, talk to them and keep providing them solutions.

There will be a point where you will enter new verticals, expand your customer base, at that point your customer is changing, and again you'll need to focus on them.  

2) Living inside your Jira/AirTable etc

It's very easy to get overloaded with the number of issues inside your project management tool. It almost feels safe and positive to know you are tackling everything reported into the tool.

But as a Product Manager, you should be spending a portion of your time with your customers. That can be done by sitting in on trouble ticket phone calls, client recap meetings, or visiting them in person to see & hear how they use your product and issues they face.

Doing the above adds the human element to your work and helps you empathize with your end-user.

BTW, I've made this mistake plenty of times. I have forced myself to do this, but each time I do, I feel more positive and energetic the day I get back to work.

3) Developing a feature you love but saying customers will love it.

This is mostly a founder thing. If the product initially started to help solve a problem they have and now other people are using it, it would be very easy for the founder to keep developing the product for their own needs. But... the product is no longer for just you, you have real customers using it who pay you. Make sure you improve the product for those who are paying you :)

4) Not prioritizing your work

I've heard of teams that have an excel list of issues. Engineers pick the items they want to work on. This is truly a bad idea, especially when you have limited resources.

Engineers are (most likely) not speaking directly to customers. They don't know how many people that particular issue impacts, or the scale of it. They don't know if a customer churned last week because a particular item was not resolved.

The Product Owner or someone who is close to the customer and business should balance the priority worklist. Also, Agile methodology can help significantly.

5) Focusing on the competition

This is tricky. You could be building a competitive product and need to be at least at par with the competition to gain customers. At the same time, you have customer requests coming in, defects to handle and are trying to innovate to beat the competition.  

How do you balance all of this?

Depending on your development resources the balance would change. For example...

Before you read, know this. This is not a cookie-cutter guide. Depending on your business, things can change. So, take my examples below as a suggested guideline.

If you are a startup with a tiny/small team, then build your MVP and get your first few customers to start using it. Focus on beating their expectations and making them say wow. 

Then start looking out at the competition and see where they have weak points. Sites like G2Crowd is great for this. They have recommendations and feedback that you can learn from. Start building better solutions for those problems and going after more customers or more customers with more advanced needs/expectations.

If you a mid-sized team, have an MVP proven product, the product is a bit more mature and your customer base is growing, then I'd suggest the following.  

You will have business requirements (product expectations set by management to grow the company), customer tickets with bugs, customer feature requests, marketing team demands and specs to solve for the customer things that your competitors are getting wrong/not doing.

At this point, you've got a lot on your plate. It's a good time to take inventory of your development resources. This includes your various tech stack developers, QA, and graphics. Then bring in your founder, or senior folks to help them understand the resources you have versus the demands for development on your list.  

What will happen in the other meeting is that the founder gets clarity on your limits. Which in turn could mean a) he gets you more resources b) he helps you prioritize what to develop c) you work with him to create a more doable release schedule d) he can work with other teams to curb their requests.

For large/enterprise teams, though you have more customers and more money, you also have business requirements (product expectations set by management to grow the company), customer tickets with bugs, customer feature requests, marketing team demands and specs to solve for the customer things that your competitors are getting wrong/not doing.

If you are financially doing well, you have money to bring in full-time staff, consultant, contracts to start supporting these needs. However, at the same time because of your size, you may start working on projects that don't move your KPI needles. You also will tend to have longer release cycles, charters, or projects that aren't prioritized well.

This is a good time to have the right Product Managers in place. These are folks who are mini-CEOs of a piece of the product. Their job is to ensure their project is a winner for the customer, the team is working on the right projects and the projects are meeting business team requirements.

6) Waiting for perfection

Your product is a growing & evolving thing. It's going to have new demands, issues, growth in every phase, and technical issue. Your customers are going to use it in ways you never imagined and break your product. So, knowing all this, think about it, are you ever going to be able to build a perfect product? [Even the Matrix had issues ;)]  

PMs or founders who focus on perfection risk delaying the launch of their product and risk product/company growth in general.

Why are you looking for perfection? Don't let it be your own pride. Don't worry about losing your initial customers, you will get more later.

7) Not clearly specifying an MVP (minimum viable product) spec

Many founders or Product Managers get excited by saying "We are launching an MVP". But when asked what features/functionality will be in the MVP, their answer will vary every time.

But why? Because the didn't document exactly what they want it in and then close the requirements. They tend to keep it open and take in new items as they talk to customers, read about competitors, etc.

The definition of an MVP is clear: an MVP is a product with just enough features to satisfy early adopters in the market. It will give you the ability to interview and get feedback users, and additionally, check if there is a potential product-market fit. 

8) Getting over-worked

Product Managers are mini-CEOs of the product(s) they own. Between talking to customers, planning, writing stories, standups, business meetings, team meetings, reviews, JADs, etc, their work time/personal time gets completely destroyed. 

PMs need to balance their work and personal life. Yes, you may love what you do, but don't forget that you have responsibilities to yourself (health, learning, admin stuff), your family etc. If you start failing your personal life, your work life will also suffer. So, there needs to be a good balance. When you have a few days off, take it. Don't work. Go for a hike, watch a game, go biking etc. I assure you, when you come back, you will come back with a ton of renewed energy and you will perform better.

9) Expecting solutions from customers

Henry Ford famously said, "If I had asked people what they wanted, they'd have just said faster horses".

When you talk to customers you will learn about their pain points, wishes etc. Your job is not to solve that exactly that. Your job is to innovate to address their issues and build something that is better and will handle future issues. Don't expect customers to give you a solution, that's your job.

10) Scared to talk to other Product Managers or those can poke a hole in your plans

Product Managers have a high bar to maintain. That being said, many of them feel if they talk to other PMs about something they are working on, they may look less experienced than the other. Or they feel others will poke holes in their current solution/specs/stories and again make you look less skilled and unplanned.

The opposite is true. Sometimes it's good to talk to others. They may not be familiar with your product, or may, and can share their insights, thoughts, ask questions you didn't think of etc. PM's can think inside their world (box), and so it's nice to bounce ideas off someone who can have a different opinion. It's up to you to heed it, but at least it can make you think.

BONUS- Not spending enough time on the question "WHY"?

Depending on your seniority in the company, you may have product assignments handed to you, or you may have the freedom to come in early during the problem/solution research. Regardless, you need to spend time asking "WHY?"

Why: when you are working on sometime existing, improving something or working on something new, it's critical to ask WHY? 

- Why are you working on this?

- Why did the customer have an issue with this?

- Why is the company now focused on this?

- Why was this the solution we decided was best?

Spending time on WHY and asking questions gives you more insight and helps you think of the best way to address the issue or solution expected. If you are working with seniors in the team, it will also show them that you are not just taking their explicit instructions, you are asking questions to understand the issue.

Hope you found this helpful. If you have mistakes you've made and others can learn from, please share it here with me and I may add them to this article.

Lloyd

Follow me: Linkedin, Instagram

?? My latest project AudiBrow - listen to news from TechCrunch, Cnet, Reuters, Paul Graham, and more