Nowadays everyone claims to be agile and innovative. From small startups to large corporates, no one would ever say “Hey, I think that we are doing something wrong in our product development. We are burning our money really carelessly”. Even more, there are often excuses or explanations why they are not fully agile. So what are warning signs that you are working in a product organization that has a high chance of product failure?
Also, if you are interested in validating
But now, let’s get to the seven warning signs of product failure.
1. You ship and move on
Your organization sees the development of features as a one-off thing. You ship and move on. There is no time planned for improvements of the released features. The explanation is often that you are already shipping the “ideal” version of the feature instead of small increments.
The truth is that by default a lot of features or products will not be a huge success when you ship them. This is why it is important that you keep tracking them after your release. Also, get feedback from customers. Either directly or through your customer success team. That will allow you to adjust the feature and increase its chance of success.
2. The engineers are involved too late
If your company is making software products, then it is important to involve your software engineers as early as possible. I see often the mistake that they are only involved once the development starts.
Your engineers know your software better than most people in the company and they might have valuable input regarding the design of solutions. This is why it is important that you involve them already when you start creating a solution. By involving them earlier you will also increase their buy-in for the development of the feature. They will feel a sense of ownership and will feel respected.
3. All “ideas” come from top down
Your roadmap is basically a prioritized feature wish list from management.
Instead, you should focus on qualitative and quantitative customer feedback. Decide what do build by analyzing your user’s needs and behavior. Like that you will build a
4. Obsessing over ideas instead of problems
Companies of all sizes make one simple mistake: They obsess over ideas instead of problems. You for sure encountered this situation too. A customer or executive has a suggestion “I’d really like to be able to do X”. If you are a good product manager, you are now asking yourself “able to do X why”? What normally happens is that now everyone starts brainstorming ideas. People think about where the buttons should be placed and how the design should look like.
We love visualizing ideas and being creative. But this is not how you build good products. In this situation, it would be much more important to know WHY the user wants to do X, instead of what they want to do. The WHY answers what kind of problem the user has. Once you really understand the problem, you can start thinking of a solution. This will make the resulting feature so much better and reduce the risk of product failure.
5. No outcome-based goals
The goals of the company and especially the product team are not outcome based. Instead, they are about the
Goals of good product teams are outcome-based. For example “increase cross selling in the product to an average of 200 dollars per customer”. Now, it is not enough to just ship a feature. The outcome matters, not the output.
Read my post about introducing OKRs in product teams if you are interested in setting good goals for your team.
6. The product manager is only translating
Your role as a product manager is to translate someone’s feature requests into tickets for engineers. This is a typical sign for non-existing product management.
Instead, you should have the lead in figuring out what the best solution for the user is. You use quantitative and qualitative data to make decisions and determine how the feature should be built.
7. Too early business cases
Before you even know, what the solution of a problem might look like, you are asked to provide a business case. This might lead to not having enough time to implement the best solution for the user. When you start researching a feature, you don’t know yet what it will take to satisfy the users. Because of that it makes little sense to already have to provide a business case and give an exact estimate of the costs and time it will take to build the feature. Requiring a business case at such an early point also implies that your managers think that there will for sure just be one iteration and that you will immediately build the perfect feature.
Thanks for reading my post about the seven warning signs for product failure. Leave me a comment if you have more questions and I’ll make sure that I reply.
If you are looking for more tips on how to avoid product failure or how to become a word class product manager, I would recommend “INSPIRED” by Marty Cagan.
