ITKarma picture

From the author of the translation

At, each business unit initiates projects aimed at developing the company, and those that require changes in IT systems are necessary to be prioritized and agreed together with IT. During the next session of discussion of projects planned for the next quarter, an understanding of a simple truth came: the number of projects is always a multiple of resources in IT. And from this, two equally simple conclusions follow.
  1. We will never be able to take into work all the projects that we would like.
  2. You need to learn how to choose them correctly.

ITKarma picture

I am sure that the vast majority of food companies face similar problems. As a working tool to solve these problems, the approach described in the article by Lenny Rachitsky, product lead Airbnb.

It was 2012 when our team just joined Airbnb. Our task was to create the experience of “social travel” for Airbnb travelers. We proceeded from the fact that they are scattered around the city, and if we make it easier for them to meet and do something together, traveling with Airbnb will become much more meaningful for them.

Fast forward 6 months later when we launched the first version in San Francisco. The product turned out great, everything went like clockwork. The implementation was not so successful. A tiny percentage of travelers tried it. And all would be nothing, but it was absolutely not the result that we expected. We tried more than once, introduced some improvements, but a few months later completed this project.

ITKarma picture
The first developments of the launched product that enable Airbnb travelers to find events in which they can participate with other travelers

Personally, I learned a great lesson from this. But most importantly, this experience developed a habit and understanding in me of the importance of correctly formulating problems. Among the many reasons that influenced the failure of the project, the main one was the initial misunderstanding of the problem, which was to be solved. We noticed too late that the real problem that we had to solve was not “travelers want to hang out with other travelers”, but “travelers want to find interesting, non-travel opportunities for hanging out”. Hanging out with other travelers is just one of these opportunities, and not the most significant. Fortunately, another team identified this need and eventually launched the much better solution Airbnb Experiences a few years later.

ITKarma picture

As I noted in my previous article , to solve any problem, you must clearly identify it. It sounds deceptively easy. Doing it well is the superpower of the best leaders. Fortunately, this includes three simple steps.

  • Step 1. Crystallization of the problem
  • Step 2. Coordination of the problem with the team and stakeholders
  • Step 3. Constantly returning to the problem

ITKarma picture

First, a little context. This framework is most effective when applied to projects, especially new products or new features. In order for a project to be successful, complete these three steps before you get started.

If your team does not have a clear idea of ​​where you should go, or an understanding of the general strategy of how you will get there, stop to deal with these things first. Here , here and here to help you.

ITKarma picture

Step 1. Crystallization of the problem

Start by answering these questions about your project.

  • Description: what is this project?
  • Problem: what problem does he solve?
  • Why: how did we understand that this is a real problem and it needs to be solved?
  • Success: how do we know that the problem is resolved?
  • Audience: who are we doing this for?
  • What is this: what will the implementation in the product look like?

Description: what kind of project is this?

This is a brief description of the idea. People reading it can quickly understand the point. Be brief.

Problem: what problem does he solve?

The very statement of the problem is so fundamental that it is worth spending extra time on this. Think about the problem hypothetically. What problem do you think you are solving and why? You will add more context later.

We will name the key characteristics of the correct formulation of the problem.

  1. The problem is brief. The goal is to describe the problem in one sentence. The more explanations you need, the less clear the problem ultimately becomes.
  2. Focused. We have the only clear problem that can be solved by one team and in a reasonable time. It is often very useful to give a few examples of other problems that you DO NOT solve.
  3. Related to unmet need. Focus on the needs of the user or business. It is extremely useful here to use this framework.
  4. Includes answers to the question what and why. What is going wrong and why is this a problem? You may need to return here in the next section.
  5. It doesn’t depend on the solution. Suppress the desire to go too quickly to solve the problem.

Good problem statement examples

  • Lyft taxi drivers often reject orders because they are too far from the customer.
  • Airbnb homeowners are disappointed because they want to grow but don’t know how to do it.
  • Users leave too often at the final registration stage.

Bad Problem Statement

  • The number of users is growing slowly. [What's wrong: the problem is too wide. You can read about the strategy for approximating the big picture here and here. In addition, the user's needs are not taken into account.]
  • Create a loyalty program. [What's wrong: this is a solution. What problem do we want to solve?]
  • Users do not reach the end of registration. [What's wrong: lack of focus, missing the alleged reason. You need to go down one level.]

Why: how did we understand that this is a real problem and it needs to be solved?

At this point, you gather evidence supporting your problem as a hypothesis. What initially convinced you that this was a problem? What makes obvious the need to solve this problem?

Often at this stage you understand that this problem is not at all priority now or you need to adjust your ideas about the problem. This is the meaning of the exercise - do not neglect it. The number of problems is endless. Your goal is to make sure that this problem needs to be resolved by your team right now.

Some tips for this step.

  1. Examine quantitative and qualitative evidence. Collect all the data that indicates that this is really a real and important problem.
  2. Quality is more important than quantity. From 3 to 5 direct facts are better than a dozen indirect ones. In the second case, your conclusions will be weaker, since they will be based on secondary and irrelevant facts that look like a bunch of evidence. Extra perfectionism is also useless.
  3. Play the devil's advocate with yourself. Try to convince yourself that this is a completely insignificant problem. What gaps are there in your evidence? Is the evidence consistent with what you think? Check yourself.

In the end, you will receive a verdict based on many compromises. Your job is to make the best decision based on available data. Continue to refine the wording of the problem as you learn more.

Success: how do we know the problem has been resolved?

Have you achieved what you planned to achieve? How do you know? Answer this question and write down the answer.

ITKarma picture

This criterion becomes incredibly important throughout the project, as it helps to make decisions and prioritize. Does feature X increase the chances of achieving a goal? If not, don't do it.

Ideally, this is a specific metric that is easy to measure. Ideally, it is directly related to the KPI of your team. Ideally, it is based on reliable data on available resources, investments and the results of past experiments. Rarely is ideal.

A few tips for determining success criteria.

  • Try to get a specific number, for example: 10% - an increase in the indicator X; 50% reduction in Y.
  • The goal must be attainable, but ambitious. Achieving what goal will delight your team and leaders?
  • If you could not come up with a metric for your purpose (you need to think long and hard), describe how the world will look if the project is successful. Make it a success criterion.

Audience: who are we doing this for?

Everything is pretty obvious here. We rarely do something right away for everyone. Is it for new or returning users? Is it for casual or regular users? Is this for site or mobile app users? And the like.

What: what will the implementation in the product look like?

At this stage, you need to briefly describe the solution to the problem. Depending on how your team works and how much is known about the project, this can be a description at a very high level or as detailed as possible. In my experience, the key point here is to synchronize with the performers, finding out how many details they need and what will be most useful in the process of work.

Step 2. Coordination of the problem with the team and stakeholders

Have you seen the Chiptolle billboards along the highway (picture below)? A year ago, my colleague Peter pointed out the trick of this ad - each of us presents his ideal burrito inside the foil. We all see what we want to see.

ITKarma picture

Understanding the problem is like burrito in foil. Each member of your team has their own version of the problem in their head. Sometimes they almost coincide. Sometimes they are completely different. The larger and more complex the project, the more often they differ. Your task is to eradicate these discrepancies as early as possible and as often as possible. Open the package and make sure that everyone agrees with the burrito inside. Fortunately, we have a great document that we created in the first step. It will make your work 10 times easier.

I usually approach this step like this.

  1. Take the document created in the first stage (this can be done by any member of your team involved in this problem).
  2. Share it with the whole team. Gather feedback. Modify the document based on the feedback received and submit it again for general viewing.
  3. If the feedback converges and the team looks synchronized - great. If not, get everyone together and discuss the differences.
  4. When agreement is reached within the team, synchronize in understanding the problem with stakeholders. It is important that your team and the people who will evaluate the results have the same understanding of the problem you are solving before you begin to work closely on the project.
  5. Assemble the team and review the problem statement again. Find answers to unresolved questions and make sure that the team has everything you need to get started.

Step 3. Keep returning to the problem

The classic Seinfeld episode, where Jerry and Elaine try to get the car they reserved, is a great metaphor for the trap in project management.


We often start with obvious intentions and all necessary approvals, but at the right time, when the work is in full swing, we are moving away from the problem that we planned to solve. And this is the most important part of the task.

I remember how a few years ago I worked on a project to create an admin panel for homeowners in Airbnb. Initially, we solved the problem of reducing the response time from the host, namely, reducing the host response time to the guest’s message. Our hypothesis was as follows: the hosts would respond more quickly if unread messages were more visible to them. In addition, we would remind them that the speed of response to messages affects their search ranking. In the end, we were right. But throughout the project, with its scale and complexity, I constantly found myself reminding the team what problem we had to solve. (Professional advice: admins are a classic burrito problem in foil.) Nothing helps better from blurring the project’s focus than constantly returning to the original setting of the task and success criteria. You can solve many problems in many ways, but you can also create a great product that doesn't solve any problems.

Good habits will help you avoid this trap.

  1. For each review of the project, make sure that the contractor begins by posing the problem. If this is not obvious, ask the question: "What problem are we trying to solve?".
  2. With each project progress report, return to the statement of the problem to the stakeholders. Make sure everyone has the same understanding.
  3. Before finalizing the project, ask yourself: “Do I feel confident that we are ready to solve the problem that we planned to solve initially?”.

And in conclusion

We are all professional problem solvers: technical, interpersonal, organizational, etc. We are unable to refuse to solve problems.

Problems are constant in life.
When you solve a health problem by purchasing a subscription to a sports club, you create new problems: get up earlier to come to the club in time, take a shower and change clothes for work, after you sweated for 30 minutes on an elliptical trainer, because you don’t want to stink to the whole office.
When you solve the problem of lack of time to communicate with your partner, setting the evening of the environment “date of date”, you create new problems: how, for example, to think up what you will do every Wednesday, which you will soon begin to hate...
Problems never end - they only change and/or modernize.

Mark Manson. The subtle art of indifference

Time spent on improving problem-solving skills is time spent usefully.

Highly recommend reading the following 5 books.

ITKarma picture

  1. Deep Work (Cal Newport. Head to Head. Success patterns from an IT specialist)
  2. The Subtle Art of Not Giving a F * ck (Mark Manson.The subtle art of indifference)
  3. Good Strategy, Bad Strategy (Richard Rumelt. Good strategy, bad strategy. What is the difference and why this is important)
  4. Measure What Matters (John Dorr: Measure the most important. How Google, Intel and other companies are pushing for growth with OKR)
  5. Lean Analytics (Not translated into Russian at the time of writing)

From the author of the translation

I can add on my own that in my practice I have come across absolutely all the situations described in the article: disappointments from unsuccessful projects, a catastrophic difference in understanding the most obvious, as it seemed, things by different people, loss of focus during the work on the project, and therefore I’m ready to subscribe under every word.

ITKarma picture

Took the framework into service. For ease of use, I developed a form to crystallize problems.

I express gratitude to our journalist Tatiana Anisimova and art director Alexey Zabegalov for their help in editing and writing the article. .