Focus on the problem

It is human nature to solve problems. Whenever we hear about problems, we almost immediately switch to problem-solving mode: searching for solutions. However, suppose we first have a better understanding of the context in which the problem occurs and the motivation to solve it. In that case, there are greater chances of finding simpler, easier-to-implement solutions.

It is common to see other departments asking the product development team to implement features A or B because we need it to close a deal or retain a major client. A common example I have heard lately is, “We need to implement Apple Pay and Google Pay as a new payment method.” The issue here is that while we are discussing solutions, we end up losing focus on the problem that gave rise to this solution.

The main advantage of focusing on better understanding the problem is that the more time we invest in it, the easier it will be to find a solution, and there is a good chance that this solution will be simpler and quicker to implement than the initially thought-out solution. Here’s a great quote from Albert Einstein:

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

Einstein believed that the quality of the solution you generate is directly proportional to your ability to identify and understand the problem you aim to solve.

Let me tell a short story to illustrate this. During the space race between the United States and the Soviet Union in the 1960s, scientists faced the problem of writing in space, where there was no gravity to make ink flow in a ballpoint pen. The Americans initiated their R&D efforts and, after some time and millions of dollars, developed a pen with a small motor that pumps ink onto paper even in zero gravity. Meanwhile, the Soviets decided to use a pencil1.

This story is a good example of how jumping straight to the solution can lead to unnecessary time and money spent on incomplete or exaggerated solutions. It’s a cultural issue, a behavior that we can and should change. The first step in changing a behavior is recognizing when it occurs. When a product development team member receives a request to implement something, they should ask the person making the request what problem “something” is meant to solve and why it is necessary.

Real-life examples

I’ll provide some examples from the companies I’ve worked for. At Locaweb, a web hosting provider in Brazil, hosting and email services could stop working due to external factors, such as the non-renewal of the domain associated with the hosting or email.

• First solution: Registro.br, the Brazilian domain registrar, launched an API to allow Locaweb to bill the customer’s domain on behalf of Registro.br. Initially, the idea seemed good. Locaweb billing the domain appeared to be the easiest way to ensure customers know they must pay for domain registration to maintain hosting and email services. However, upon deeper analysis, we saw that this solution could generate problems. The customer would be billed twice for the same domain registration because Registro.br would still charge for the domain. What happens if the customer pays both bills? What if they pay only Registro.br? What if they pay only Locaweb? Additionally, implementing a new type of billing, where we charge for a third-party service, was new for the Locaweb team. New processes would need to be carefully designed.
• Real solution: We began to explore simpler ways to solve the problem of helping our customers remember to pay for domain registration at Registro.br. By being able to access information about expiring domains from Registro.br, we decided to design a simpler solution: implement a communication timeline with the customer, reminding them of the importance of paying Registro.br to ensure email and hosting services continue to function normally. This is a much simpler solution than implementing a duplicated billing process. If Registro.br provides us with the billing URL, we can send that link’s information to the customer, increasing the chances of further resolving the issue. A communication sequence is much simpler and quicker to implement than a duplicate billing process.

At Conta Azul, a SaaS ERP for SMEs (micro and small enterprises), we use accountants as one of our distribution channels and want to increase sales through them.

• First solution: bulk purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their clients. A bulk purchasing management system would take about 3 months to implement, as it needed to allow accountants to buy Conta Azul licenses in bulk but should only start charging the accountant’s client when that client actually activated the license.
• Real solution: Accountants were not interested in bulk purchases. What they wanted was to offer a discount to their clients so that they could subscribe to Conta Azul with an exclusive discount provided by their relationship with us. The cost to implement this was zero, as the system already had a discount management feature.

At Gympass, a fitness partner entering our network requested that we present their waiver to all users checking in at their facilities.

• First solution: change our app to prompt users who go to this fitness partner to read their waiver in our app and check a box indicating they have read and agree.
• Real solution: no change in our app. We used a customizable text field in the configuration of a gym in our system, a field normally presented to users checking in at that gym, to display the following text: “By checking in, you agree to the terms and conditions located at http://fitnesspartner.com/waiver.”

Don’t get me wrong: it’s great that everyone brings solutions 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 the solution so that we have a chance to find simpler and quicker-to-implement solutions. Ultimately, it is the product manager’s job and the responsibility of all product development team members to ask what the problem is and why we need to solve it.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
• Chapter 1: The so-called digital transformation — Project and Product
• Chapter 2: Uncertainty and digital transformation
• Chapter 3: Types of company
• Chapter 4: Type of company vs digital maturity
• Chapter 5: Business models
• Chapter 6: Agile, digital and product culture
• Part 2: Principles
• Chapter 7: Deliver early and often — Measuring and managing the productivity — Case study: Dasa Group — Case study: Itaú Unibanco
• Chapter 8: Focus on the problem

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing 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 books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products