Ministry of the User
Ministry of the User

70. Die hard

4 min read Leer en español

THOSE PROBLEMS FOR WHICH you can’t identify the causes come back with different symptoms until you decide to eliminate them.

They change the face, but they are the same.

They don’t go away. They return. They always come back.

The key to speed is that it occurs within a frame of precision. Otherwise it’s just acceleration and wear. How can we be fast if we only eliminate the symptoms and not the causes of the problems?

The previous paragraph seems somewhat unnecessary:

  • Isn’t that something we all want to achieve?
  • Who would want to leave problems unsolved?

The truth is that the natural thing to do is to focus on the symptoms. Forgetting the causes. That bias allows us to have the feeling that we address the problems… until the problem returns.

There are two main reasons why we focus on symptoms:

  1. Because we ignore that we ignore the causes: we see the consequences and attribute the causes to the event closest to them.
  2. Because we don’t have the resources to address the ultimate solution:
  3. We see the symptoms, we understand the causes, but we don’t think we have enough time to be able to solve it.
  4. We don’t have the budget to dig deeper into the solution.

With regard to the first reason, “We don’t know that we don’t know”, we have two central tools to address it:

  1. Curiosity: or the instinct to know where to look.
  2. Dissatisfaction: understood as the intrinsic need to search until the last moment for the piece of information that allows us to put the puzzle together. Trust your curiosity and follow it until you are satisfied.

How do we develop these skills if we don’t think we have them?

The answer is, as always: “methodically.”

There is a technique that allows us to cultivate both curiosity and dissatisfaction to find the roots of the problems we perceive.

Sakichi Toyoda, founder of Toyota, developed a technique of extreme simplicity that allows us to focus on finding how problems originate and, therefore, what is the real problem that we must solve without being distracted by the symptoms.

The technique we are talking about is called: “The five whys technique”. This technique consists of asking up to 5 times “Why?” about the first problem, until we reach a definition that allows us to solve it thoroughly. Let’s understand it better with an example.

Let’s suppose that a user calls technical support in order to be able to whitewash the password with which they access our website. Here’s how we would apply the technique and its possible ramifications:

  • Why did the user call tech support?- Because they couldn’t reset their password.
  • Why couldn’t you reset your password?- Because you couldn’t find the option for you to do it without help.
  • Why couldn’t he find the option to do it on his own?- Because the design isn’t clear.
  • Why is the design unclear?- Because there was no time for the designer to analyze it and propose an alternative.
  • Why wasn’t there time to involve a designer?- Because the requirement came at the last minute.

Of course, the derivations can be diverse. Each reality is different and each interlocutor can lead us to different reasons. This is where we must repeat this technique with different people to find patterns and strengthen our conclusions.

You can also use this technique on yourself, as a way of introspection.

Here are two examples (exaggerated, by the way) for you to analyze for yourself. Every problem is accompanied by an erroneous but simple solution, therefore: frequent.

You can apply the “5 Whys” technique and imagine multiple possible solutions.

  • Problem:- “The product doesn’t sell enough.”
  • Misconception:- “We need to change the sales team.”
  • Problem:- “The user doesn’t understand the product.”
  • Misconception:
     — “All users are dumb”

There’s another technique you can apply to better understand a problem and its context: write and try to describe the problem, its causes, and possible solutions in two paragraphs or less.

Let’s follow the following method:

  1. Write: Write as much as you want about the problem, its causes, and the solutions you propose. He writes a lot. Fill your text with details.
  2. Complete: You’re likely to find missing information or some facts that need to be confirmed. Look for missing information and add it to your text.
  3. Synthesize: Once the initial text is completed, you should reread it to eliminate redundancies. The goal will be to be able to summarize the text in two paragraphs or less.

Writing about a topic allows us to transfer what we think in a sequential and somewhat more orderly way. It allows us to clearly see the facts that we have not confirmed and, finally, when synthesizing the text, we have the minimum expression that allows us to communicate the problem with the rest of our team.

As regards the second plea, “We don’t have enough resources” I’d like to touch you on the idea 59. Technical problems and political problems.

The user is king