Product management is the process of making the right product, to solve the right problem, for the right person. The right person is the customer, who along with business and technology, make up the heart of the product management process. It is the process by which a vision or idea becomes a valuable product.

The product manager has the responsibility of analyzing the markets and watching the competition, and laying out the initial product vision based on his assessments. The project manager has duties that are both strategic and tactical, and must have excellent leadership skills. He must be able to bridge the gaps between the many different teams working on a product, from design and engineering, to sales and marketing.

However, bad products do happen. Just think of New Coke or Crystal Pepsi. What seems like a great idea on paper, or in a product meeting, can be a terrible idea in reality.

Some products end up not being useful, or perhaps they just don't work as they were supposed to. Maybe they were just too difficult to learn or understand, or they just didn't sell. It happens. Product managers and owners are human, so mistakes will happen and a good team will be prepared for the possibility.

However, sometimes things happen frequently enough that it can be said they contribute to bad products. Here is a list of the pitfalls that can kill a product, and the best way to avoid them.

1 - Confusing Customer Wants and Needs With Product Requirements

When it comes to the customer, the product manager wants the customer to be happy. He will talk to the customer and formulate a list of everything the customer wants and needs from the product. But the customer doesn't always know what they need or want. Or what they want is not possible or feasible.

Since customers don't necessarily know what is possible, they rely on you to inform them, whether they know it or not.

2 - Mistaking Innovation for Value

Innovation needs a purpose. There are tons of products on the market that exist simply because they can, not because they solve a problem, or because they are better than similar products.

What motivates one designer may not motivate another. Engineers love the challenge and will use new tech if they can, regardless of whether there is a need for the product. What is important is that innovation happens within the context of a vision and a strategy; that is the only way to provide customer value.

3 - Confusing Yourself With Your Customer

It can be very easy to consider yourself the target customer. This is always a bad idea, because you never want to consider yourself a proxy for your customer. We apply different standards to what we want, than to what the customer wants.

For example, you might be able to use and learn a new software program easily, because you work in the tech field. However, the target customer may not be so technologically advanced, and have great difficulty using the product. He or she might find it confusing or overwhelming. This means the product is unusable.

Or, as a product manager, you may get excited for new features and releases, while the customer may not even consider new changes or features necessary. They may not want to have to install a new update, or learn about the new features.

It's important that product managers put their products in front of the target audience, and that the product manager listens to their responses, keeping their perspective in mind. This is why product management teams should utilize usability testing.

4 - Confusing the Customer With the User

Remember, the customer is who BUYS the product, and the user is who USES the product. Who do you think you should satisfy first?

The person who buys the product probably has a different reason than the person who uses it. For example, ABC is developing software for XYZ Hotels. Is it more important that XYZ likes the product, or that the XYZ employees using the product like it?

Sales people usually understand the difference, but the product team often misses the mark. It is essential for the product team to understand the types of people that will be using the software.

Staples buys thousands of titles of software each year. However, the user is different from Staples, which is a large company. What works for Staples is totally different than what works for the user.

5 - Mistaking Features for Benefits

A feature is not always the same as a benefit. As the product developer, it can be easy to fall in love with your product's features, and neglect to think about what benefits those features may provide.

The product has to have a clear and compelling reason for being. The target market must be understood, and that market must see that your product solves a problem. It is also possible that the product is perfect for your target market, but the message is too complicated to understand. If a quick one-minute elevator pitch doesn't sell the target customer, then the message is wrong.

6 - Confusing Building the Right Product with Building Product Right

A development team can build the most perfect piece of software. It can be bug-free, fast, and work perfectly. But if the user doesn't see any value in the product, is the product still perfect? Of course not.

The product has to be implemented so that it works reliably and performs, as it should. However, you will have wasted a lot of time if the product isn't useful.

Software development teams must always keep these questions in mind when building out the product. Quality assurance usually helps on this end of the process.

7 - Mistaking Good Product With Good Business Model

You can have the greatest product in the world, but without a good business model, the product will fail. Think of the TiVo product. It was a huge success, since people generally do not like commercials. However, the TV industry needs commercials.

So TiVo worked with the TV industry and found a business model that worked. The customers liked the change, and were happy that they could still quickly move through commercials.

8 - Mistaking Adding Features With Improving Product

When a product is failing, the product team usually rushes to find new features that will hopefully fix the problems, and hope that the customer will purchase the new features.

However, this strategy rarely works. Adding new features can often make the problem worse, since it makes the product more complex for the user. A successful product team will continually improve the product, which means making the product more usable for a wider audience of customers.

9 - Mistaking Impressive Specifications With an Impressive Product

Many teams follow their product's lifecycle, and produce complete requirements and designs. However, these specifications don't necessarily mean that the customer will buy the product.

Especially with high-tech software products, users must be able to use the product and determine whether or not they want to buy it. Teams may place too much trust in specs and don't realize it is worthless if customers cannot figure out how to use the product, or don't even care to use it, because they see no value.

10 - Mistaking a Complete Product With a Sellable Product

If your company is not set up to distribute and sell the product, then the greatest product in the world won't sell. You must look at the company's structure and business model and determine whether the product can be supported in the current model.

It is easier to change the product to fit within the company structure and business model, than to change the company to meet the needs of your product.

This is important to remember, if there are any changes in the company business strategy.

11 - Mistaking Product Launch With Success

What is success? Success is not launching a product on time, or even getting great reviews. Neither are getting new customers or hitting new sales goals. Those things are great, but they do not equate to a happy customer, which is the ultimate sign of success.

It is very easy to care about what competitors are doing, or worry that a new technology will bypass you. But the most important thing is that you have happy and loyal customers.

In addition to these common mistakes, you want to make sure you don't fall into one of the many possible Scrum pitfalls. Here are 20 common Scrum pitfalls:

Common Pitfalls

Excessive Planning - Advanced planning is not needed with Scrum. A team can just start and use feedback obtained in the sprint reviews to change its plans.

Solving Problems in the Standup – The standup is not where solutions to problems should be discussed. The standup should be quick, less than 15 minutes.

Assigning Tasks – The product manager should not be assigning tasks. The beauty of the self-organizing team is that they assign their own tasks.

ScrumMaster is NOT a Member of Development Team – The ScrumMaster is tasked with making everyone understand the Scrum process, removing obstacles in their way, and keeping the team on task. They should not be tasked with extra work.

Product Owner Isn't Available – The Product Owner is a key member of the team and must be present for all Scrum meetings. The Product Owner also must be available during the workday. If the Product Owner isn't around, that isn't a good sign.

Stretching Goals – The development team decides how much work will be done in the sprint. They should not be pressured to do more work. This can cause resentment and, possibly, work of poor quality.

Playing the Hero – No one on the Scrum team should try to do more than tasked to them. Doing overtime or being the hero is not necessary.

Having the Team Manage Backlog – The team is not responsible for the backlog. It is the Product Owner's job only.

Product Owner Makes Solutions – The team is who should be coming up with solutions, and the Product Owner must allow this.

Interrupting the Team – Sprints cannot have interruptions. If a problem is urgent enough, the sprint should be canceled. Otherwise, the interruption should be added to the backlog and dealt with during the next sprint.

Assumptions - A team member solves problems, but it is critical to know about constraints. The feedback between the product owner and the team member must be ongoing throughout every day of the Sprint.

Don't Do Too Much - This can be difficult to prevent from happening, but it can become a habit for a team to become over-committed. Make sure that the team uses burn down charts and holds demos, even if they haven't completed all of their work.

Don't Rush The Demo – It takes time to prepare a demo. Make sure time is spent cleaning up the team space, setting up a demo environment, and ensuring that crucial stakeholders are prepared. These tasks can be part of the Sprint Backlog.

Software Is Not Shippable – The Scrum development team must attempt to make "potentially shippable" software right from the very first Sprint. Building prototype code will only delay the need to write production code.

Team Not Together - Even though Scrum doesn't officially require team members to be located in the same room, the truth is that any distribution of team members has a negative impact on communication, which hurts productivity and quality.

ScrumMaster Boss - The ScrumMaster must be the person who supports the team in learning how Scrum works. The ScrumMaster cannot suggest to a team member how to do their work, nor what task to work on next.

Roles on the Scrum Team - It's common for a company to create a Scrum development team without changing the titles and responsibilities of the people who are members of that team. Scrum teams have only three roles, which are the ScrumMaster, the Product Owner, and Development Team Members

Imposed Deadlines: Scrum is based in reality. If someone on the outside wants to have a deadline, it must be discussed with the team and managed within the sprint system.

ScrumMaster Isn't Present – The ScrumMaster must always be in the same work space or room as the team. Period. If the ScrumMaster is at another location, whatever can be done to have them in the same location must be done.

A Product Owner Who Has Little Power

Imagine a motorcycle with an engine that is underpowered. You wouldn't get anywhere fast would you?? The same can be said for the underpowered Product Owner. They must be empowered, and if they aren't, this could be because of several causes.

If the Product Owner doesn't get enough attention from management, he will be underpowered. If management doesn't fully trust the product owner, or doesn't delegate enough authority, this could also lead to an underpowered product owner.

This means the Product Owner will struggle to do a good job. He might be unable to align the Strum development team, the stakeholders, and the customers. This can cause delays hurt the team's confidence.

The Tired Product Owner

Being overworked is not healthy for anyone, and is not sustainable for the Product Owner. It can also lead to bottlenecking and causing the project to slow down. An overworked Product Owner can lead to a neglected backlog, missed team events, and not being available for the team, and being available for the team is crucial for the Agile framework to be successful.

Product Owners can be overworked for many reasons. One is because there isn't time to perform the role, and the second is because there isn't enough support for the team. This often happens when the product owner must look after too many teams.

If the Product Owner isn't getting enough support from the team, then there is a disconnect in the understanding of product ownership. To keep the Product Owner from becoming overworked, he should be assigned to just one team.

The Product Owner/Product Manager Split

Some companies will split the Product Owner role between two or more people, and have both a Product Manager and a Product Owner. The Product Manager handles all of the marketing and management, and also owns the product vision.

The Product Owner deals with the team and handles the sprints and team issues. In this case, the Product Owner is nothing more than the backlog writer. This approach can cause issues with responsibilities and can cause a waste of time and resources.

The Product Owner role shouldn't be split, and the organization should have one person in charge of all strategic and tactical product management processes. The company must investigate why it has chosen two managers, and determine what goals they are trying to meet.

The Product Owner in the Wrong Location

A Product Owner who works separately from the team is very difficult for the team, since it is strictly against what Agile and Scrum methodology is all about.

It is essential the Product Owner works with the team on site, preferably in the same work space. When there is distance put between the Product Owner and the team, problems start to happen. First the Product Owner moves to his own office, and next thing you know they are suddenly in different time zones.

When Product Owners and their teams are separated, there can be problems with miscommunication, mistrust, and slow progress. The key to success in Scrum in daily face-to-face communication, so all Product Owners should be relocated to be with their teams.

If relocation is not possible, the Product Owner should spend as much time as possible with his team, and must attend all sprint planning, review and retrospective meetings. When not in the same physical location, face-to-face meetings can still happen with teleconferencing and sites like Skype and Google Hangouts.

The Proxy Product Owner

A proxy Product Owner is someone acting as a proxy for a Product Owner. This can almost never be a good situation. Proxies are not invested like actual Product Owners are, and they can be distant and not a good match for the team. Proxies can often be overworked, since they are usually Product Owners for other existing products as well.

Using a proxy Product Owner should only be done in rare or emergency cases, when the actual Product Owner physically cannot be present for meetings and daily teamwork. If the actual Product Owner will not be able to complete the job, a new Product Owner should be found.