Problem vs solution mindset

Problem vs solution mindset

When we hurry to launch an MVP, we are creating a solution for a problem. However, a very important step to create a good solution is the understanding of the problem.

It is human nature to jump into solution mode when we learn about a problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution and good chances are that this solution will be simpler and faster to implement than the first solution we think about.

Here's a great Albert Einstein quote: 

“If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.” 

Einstein believed the quality of the solution you generate is in direct proportion to your ability to identify and understand the problem you hope to solve.

Let me tell you a short story to illustrate this. During the space race, scientists were faced with the issue of writing in space where there's no gravity to make the ink go down in a ballpoint pen. Americans started their R&D efforts and after some time and a few million dollars, they built a pen with a small engine that pumps ink to the paper, even with no gravity. Meanwhile, Russians decided to use pencils, which can do the job of writing in no gravity environments.

That focus on solutions, without good understanding of the problem and the motivation to have this problem solved, can be quite harmful. It can make us spend unnecessary time and money to get to sub-optimal solutions. This is a cultural issue, i.e., a behavior that we can and must change. The first step to changing a behavior is recognizing it when it happens. When you, as a product manager or a product development team member, receives a request to implement something, ask the person who brought the request what is the problem that this "something" is supposed to solve and why there's a need to solve that problem.

Here some examples from the companies I worked for.

At Locaweb, a web hosting provider in Brazil, the hosting and email services may stop working due to external factors such as the domain associated with the hosting and email not being renewed.

  • Original solution: Registro.br, the Brazilian registrar for .br domains released an API to allow Locaweb to charge the customer domain on behalf of Registro.br. At first, the idea seems good, since Locaweb billing the domain looks like the easiest way to guarantee that the customer knows that it has to pay for the domain registration to maintain the hosting and email services functioning properly. However, when we analyzed deeper, we saw that this solution could generate some problems. The customer would be billed twice for the same domain registration because the Registro.br would continue billing the domain. What happens if the customer pays both bills? And if she pays only Registro.br? And if she pays only Locaweb? In addition, implementing a new type of billing where we will bill for a third party service was something new to the Locaweb team. New processes would have to be carefully designed.
  • Actual solution: we started to wonder if there would be simpler ways to solve the problem of helping our customer not to forget that he has to pay for her domain registration at Registro.br. Since it would be possible to charge for Registro.br services, it was possible to access the information about the about-to-expire domain. We decided to design a simpler solution: we will implement a communication sequence with this customer advising him of the importance of paying Registro.br to ensure that the email and hosting services continue to operate normally. This is a much simpler solution than implementing a double billing process. If Registro.br provides us with the billing URL, we can send this link information to the customer and the chances of solving the problem will increase even further. And a communication sequence is much simpler and faster to implement than a duplicate billing process.

At Conta Azul, a SaaS ERP for MSE (micro and small enterprises) we used accountants as one of our distribution channels and wanted to increase sales through accountants.

  • Original solution: batch purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their customers. A system to manage batch purchases would take around 3 months to be implemented since it should allow accountants to buy Conta Azul licenses in bulk, but should only start billing the accountant's customer when she actually activated the license.
  • Actual solution: accountants didn't care about batch purchases. What they wanted was to provide a discount to their customers so they could subscribe to Conta Azul with this exclusive discount provided by their accounts. The cost to implement this was zero since the system already had a discount management feature.

At Gympass, a fitness partner who was joining our fitness network requested us to present their waiver to everyone who check-in in their facilities.

  • Original solution: change our app to ask end-users who go to this fitness partner to read their waiver in our app and to check a box stating they read and are ok with it.
  • Actual solution: no change to our app. Use a customizable text field in the gym set up in our system that is normally presented to users who will check-in in that gym to present the following text: "By checking in, you agree with the waiver located at https://fitnesspartner.com/waiver". 

Don't get me wrong, it is really good that everyone brings solutions to the table whenever we want to discuss something to be done by the product development team. The more solution ideas we have, the better. However, we need to educate ourselves to have a deeper understanding of the problem behind that solution, so we have a chance to find simpler and faster to implement solutions. And it is ultimately the product manager and all product development team member's job to ask what is the problem and why we need this problem solved.

Digital Product Management Book

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? Check out my book Product Management: How to increase the chances of success of your digital product, based on my almost 30 years of experience in creating and managing digital products.

Product Management Book


R?mulo Pagnozzi

Machine Learning Engineer @Hotmart

5 年

Great post! Although I’m afraid I have to burst your bubble because the american pen x soviet pencil story is not exactly true. https://www.scientificamerican.com/article/fact-or-fiction-nasa-spen/

Luiz Figueira

CEO @ Smart Online | Making supply chain smarter | ex-BCG, Gympass, Nuvemshop

5 年

??????

要查看或添加评论,请登录

Joaquim Torres (Joca)的更多文章

  • Os 4 princípios de desenvolvimento de produto de sucesso

    Os 4 princípios de desenvolvimento de produto de sucesso

    Como já comentei por aqui, estou escrevendo meu 4o livro, e eu adoraria ler seu comentário e opini?o sobre um tema bem…

    2 条评论
  • The 4 principles of successful product development

    The 4 principles of successful product development

    As I already mentioned here, I am writing my 4th book, and I would love to read your comments and opinion on a very…

  • Layoffs and free coaching

    Layoffs and free coaching

    I have already written about the process of analyzing and planning a layoff and also about how to see a layoff with a…

    1 条评论
  • Layoffs e mentoria gratuita

    Layoffs e mentoria gratuita

    Já escrevi sobre o processo de analisar e planejar um layoff, e também sobre como enxergar layoff com um olhar de copo…

    33 条评论
  • New book: Digital Transformation

    New book: Digital Transformation

    I have already mentioned to some people that I am working on my 4th book. The theme of this book will be Digital…

  • Novo livro: Transforma??o Digital

    Novo livro: Transforma??o Digital

    Já comentei com algumas pessoas que estou trabalhando em meu 4o livro. O tema dessa livro será Transforma??o Digital…

    3 条评论
  • Princípios antes de ferramentas e frameworks

    Princípios antes de ferramentas e frameworks

    é comum ouvir comentários de pessoas que est?o conhecendo a área de gest?o e desenvolvimento de produtos digitais e…

  • Principles before tools and frameworks

    Principles before tools and frameworks

    It is common to hear comments from people who are getting to know about digital product management and development and…

    1 条评论
  • The top-down trap

    The top-down trap

    In my last article, I've discussed the differences between problem solver teams and solution implementer teams, why…

    7 条评论
  • Problem solver vs solution implementer teams

    Problem solver vs solution implementer teams

    Marty Cagan, a well-known reference in the digital product community, wrote some time ago an interesting article about…

    12 条评论

社区洞察

其他会员也浏览了