If we search on Google for reasons why tech products fail, we will find many articles with many possible reasons explaining product failures. From 3 of these articles, I was able to compile a list of 26 reasons:
And the list can certainly grow bigger. The Verge put together a list of 84 biggest flops, fails, and dead dreams of the decade (2010-2019) in tech, including big failures from Amazon, Google, Apple, Netflix, and Microsoft.
Behind many of the reasons and failures above, we can certainly find a common behavior, going straight from problem discovery to solution delivery with little to no solution discovery. When talking with my clients about their product discovery, they normally describe situations like:
We did deep user research, and we found problem X, which users want to get solved to the point that they will pay for a good solution, so we decided to build solution Y, but now that we delievered solution Y we are seeing very low adoption…
This happened because they skipped the solution discovery, going from problem discovery straight to solution delivery. Let me repeat this because this is really, really important:
The most common reason for product failure is going straight from problem discovery to solution delivery.
As I mentioned in a previous article, discovery is a set of tools to help us mitigate product development risks. Discovering a problem is easy. Discovering a solution is hard and requires product managers, designers, and engineers to develop possible solutions. Then they need to assess the solutions to determine if at least one works and, if yes, and more than one works, which one has the greatest chance of success.
Sometimes the solution discovery confirms which product or feature we need to deliver, and the product – or feature – delivery is a success. However, there are other times when the solution discovery shows us that we cannot come up with a solution that has a chance of success, which is good. It is good because it will spare us a lot of time and energy from working on delivering a solution that will fail. We need to invest in solution discovery to avoid product failures.
Solution discovery can be a prototype, but it can also be other things like a landing page, where we draw traffic to understand if there’s demand, or a spreadsheet, where we assess the business viability of a certain solution. As I mentioned earlier, discovery is a set of tools to help us mitigate product development risks. There are many tools for the many types of risks in the product development process.
Last week I was talking to a client who had a very interesting solution idea to a certain problem that she discovered that the majority of her customers had. Still, when she decided to run some numbers, she understood that the solution was not financially viable, i.e., the amount of money she would receive from customers would not be enough to pay all the costs to serve the product. And this was good because she was able to spare all the time and money she would invest in building a solution that would become a failure.
When I was at Locaweb, the biggest web hosting and internet company in Brazil, around 2010, we discovered that some potential customers didn’t want to use the existing website builders and were looking for web design professionals, but without enough knowledge about how to manage the work with this type of professional. As we had experience building websites, we thought we could manage this relationship with web design professionals for the customer.
We were very excited about the opportunity, and we designed a solution. We were already having some discussions on how to deliver it. However, before delivering, i.e., building the solution, we decided to build a prototype to present it to some potential customers and learn from their reactions and feedback.
When we presented the solution prototype to potential customers, it put a dumper on our excitement. We wanted to be the middle person, making it clear that we would do our best to help the customer get a good website, but we didn’t want to be responsible for any misconduct from web design professionals. We wanted that the system became self-regulated through the common 1 to 5 stars rating. When we built our prototype – a one-week effort – and then presented it to potential customers, almost all wanted us to pay some fine for non-delivery or late fees in case things didn’t go as expected.
We made changes to the prototype to present the product in alternative ways to clarify Locaweb’s and the web designers’ roles and responsibilities, but without success. That’s when we decided to cancel the product development. We were very glad we did it, and we then learned how important it is to make solution discovery before putting energy and resources into delivering a full product.
Solution discovery is a very powerful yet simple and cheap way to increase the success rate of our product development efforts. However, many teams ignore it and go from problem discovery to solution delivery. If we had done so in this Locaweb example I just described, it would most certainly be a big failure. It would generate a lot of headaches for Locaweb, our product development team, and our customers.
I’ve been helping companies bridge the gap between business and technology through training, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.
I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:
You can also acquire the books individually, by clicking on their titles above.