It’s 2012 and our team has just joined Airbnb. We’re tasked with building out a “social travel” experience for Airbnb travelers. The thinking is that travelers on Airbnb are siloed across the city, and if we make it easier for guests to meet up and do things together, Airbnb trips would be significantly more meaningful. We work long and hard to design an amazing experience for travelers to discover fun local things to do with other travelers.

Fast forward to 6 months later when we launch the V1 in San Francisco. The product is beautiful and the experiences smooth. Adoption however…not so much 📉. A small percentage of travelers give it a shot, and it generally goes OK, however it’s far from the reaction we were looking for. We iterate a bit, make some incremental improvements, but a few months later we end it and move on.

An early design of the product we launched, giving Airbnb travelers an easy way to find fun things to do with other travelers — designs courtesy of Shaun Modi

I personally took many learnings away from that experience, but most of all it instilled in me the importance of getting the problem statement right. Though many factors contribute to a project’s failure, nothing is more certain to cause a project to fail than a misunderstanding of the problem you are solving.In the example above, we recognized too late that the real problem we should have been solving was not “travelers want to hang out with other travelers”, but instead, “travelers want to find high quality non-touristy things to do.” Hanging out with other travelers is one solution to this, not the actual problem. Luckily another team recognized this and ended up launching a much better solution, Airbnb Experiences, a few years later.

As I noted in my last post, I firmly believe that nailing the problem statement is the single most important step in solving any problem. It’s deceptively easy to get wrong, and when done well it’s a superpower of the best leaders.Luckily all it takes is three simple steps:

Step 1: Crystallize the problem you are solving
Step 2: Align on the problem with your team and stakeholders
Step 3: Keep coming back to the problem

“True happiness occurs only when you find the problems you enjoy having and enjoy solving.” — Mark Manson (The Subtle Art of Not Giving a F*ck)

A little bit of context first

This framework is most effective when you have a project in mind, either a new product or a new feature. Before you dive into design or engineering, go through the following steps to set your project up for success.

If your team doesn’t have a clear vision (i.e. where you’re going) or overall strategy (i.e. how you’ll get there), pause here and figure these things out first; this, this, and this will help.

Step 1: Crystallize the problem you are solving

Start by answering these questions about your project:

Description: What is it?
Problem: What problem is this solving?
Why: How do we know this is a real problem and worth solving?
Success: How do we know if we’ve solved this problem?
Audience: Who are we building for?
What: What does this look like in the product?

You can also use this handy 1-Pager template (copy it here). I find it most effective if a single person takes the first pass (usually the PM, but doesn’t have to be). Below is a bit more detail on question.

Description: What is it?

This is just a brief description of what you’re thinking, so that folks reading this doc can quickly grok what this project is all about. Keep it brief.

Problem: What problem is this solving?

The problem statement itself is foundational so spend extra time there. Think of the problem like a hypothesis. What do you believe the problem you are solving is, and why? You’ll add more context later. Key attributes of a strong problem statement include:

It’s short.Aim for a single sentence to describe the actual problem. The more you need to explain it, the less clear the problem ends up being.
It’s focused. It includes just a single clear problem that can be owned by a single team and solved in a reasonable amount of time. It’s often very helpful to add some examples of what problem you are *not* solving.
It references a “need” that is not being fulfilled. Try to focus this around a user need, but can also be a business need if necessary. The Jobs-To-Be-Done framework is especially useful here.
It includes a what and a why. What’s going wrong, and why is it a problem? You’ll need to back this up in the next section.
It’s agnostic of a solution. Resist the urge to jump to a solution this early.

Examples of good problem statements:

Lyft drivers are cancelling rides too often because the passengers are too far away.
Airbnb hosts are feeling frustrated because they want to improve, but are finding it difficult to figure out how.
Users are dropping off at too high a rate at the final step of the signup flow.

Examples of bad problem statements:

User growth is slowing. [Issue: Too broad for this process, see advice on approaching big picture strategy here and here. Also not user-centric.]
Build a loyalty program. [Issue: Assumes a solution. What’s the problem this is solving?]
Users are bouncing from the signup flow. [Issue: Not focused enough, and missing a hypothesis of the why. Go one level deeper.]

Why: How do we know this is a real problem and worth solving?

This is where you collect evidence backing up your problem statement, aka hypothesis. What initially convinced you that this was a problem? What makes it clear to you that this problem needs to be tackled?

Sometimes at this step you realize this problem isn’t actually worth prioritizing right now, or that you need to adjust how you think about the problem. That’s the whole point of this exercise, so don’t resist it. There are infinite problems to tackle — your goal is to feel confident that this problem is worth your team’s time right now.

A few tips for this step:

Look at both quantitative and qualitative evidence. Collect all data points that point to this being a real and important problem.
Quality over quantity.Three to five strong data points is far better than a dozen tangentially related points. Your case ends up being weaker with too many items because often you end up filling it with minor and unrelated data points to make it look like a lot of evidence. Your case doesn’t have to be perfect or air-tight.
Play devil’s advocate with yourself. Try to convince yourself that this isn’t actually a real or big enough problem. What gaps do you have in your evidence? Is the evidence truly telling you what you think? Push yourself here.

In the end it’ll be judgement call amongst many tradeoffs. Your job is to make the best case you can with the data you have. Continue refining the problem statement as you learn more.

Success: How do we know if we’ve solved this problem?

Did you achieve what you set out to achieve? How will you know? Answer that question and write it down in this section.

“Did I do that or did I not do that? Yes? No? Simple.” — Andy Grove

This criteria becomes incredibly important throughout the project because it helps you make decisions and prioritize. Does feature X increase the chances of achieving the goal you set? If not, cut it.

Ideally this is a specific metric, with a defined goal, that you can easily measure. Ideally it directly connects to your team’s KPI’s. Ideally it is based on hard data about the opportunity size, investment size, and a heuristic from past experiments. Rarely is it ever ideal. Here is some advice for defining your success criteria:

Try hard to make it a concrete number, e.g., 10% increase in X, 50% decrease in Y, 20% adoption of feature Z within 3 months.
Pick a goal that’s believable, but ambitious. What’s a goal that if you were to hit, your team and your leaders would be excited about?
If you don’t think a metric makes sense for your goal (think long and hard about this), write out what concretely the world would look like if this was a big success. Make that the success criteria.

Audience: Who are we building for?

This is pretty self-explanatory. It should rarely be for all of your users. Is it for new or returning users? Is it for casual or power users? Is it for users on mobile or web? etc.

What: What does this look like in the product?

This is where you take a shot at describing the solution to the problem.Depending on the way your team operates, and how much is already known, this can be very high level or very detailed. In my experience the key here is aligning with your designer(s) to figure out how much detail they want and what would be most helpful in the process.

Step 2: Align on the problem with your team and stakeholders

Have you ever seen those Chipotle billboards along the highway (pictured below)? Years ago my co-worker Peter pointed out the trick behind these ads — each of us is picturing our most ideal and delicious ideal burrito inside of that silver burrito. We all see what we want to see.

Problem statements are like silver burritos.Everyone on your team has a unique version of the problem in their heads. Sometimes they are nearly identical. Sometimes they are very different. The larger and more complex the project, them more likely they are different. Your job is to eradicate this misalignment early and often. Open up the wrapper and make sure everyone agrees on the burrito inside. Luckily we have a great document from Step 1 that will make your job 10x easier.

I usually approach this step like so:

I take a crack at Step 1 (but again, it can be anyone on your team that’s passionate about the particular problem)
Share the draft with the entire team that’ll be involved in this project. Ask for feedback (in comments, in email, or in person). Integrate the feedback, and re-share.
If the feedback is converging and the team seems aligned, great. If not, pull everyone together and chat through disagreements in person.
Once your team is aligned, share with your stakeholders. It’s extremely important that your team and the folks judging your success are aligned on the problem you are solving before you get too deep into design/eng.
Bring the team together for an in-person kickoff where you again review the problem statement, answer any outstanding questions, and make sure your team has everything they need to get rolling.

Step 3: Keep coming back to the problem

The classic Seinfeld clip below, where Jerry and Elaine attempt to get a car they previously reserved, is a great metaphor for a classic trap in product development.

We often start with great intentions and alignment, but when it counts most — when the work is actually being done — we often don’t hold on to the problem we set out to solve. And that’s the most important part of the problem.

A number of years ago I remember working on a project where we were building a dashboard for Airbnb hosts. The initial problem we defined and aligned around was reducing host response time —shrinking the average time it took a host to respond to a guest’s message. Our hypothesis was that hosts would respond more quickly if their unread messages were more prominent, and were also reminded that reply time impacts their search ranking. In the end we were right, but throughout the project, as the scope and complexity grew (pro tip: dashboards are a classic “silver burrito” problem), I found myself having to repeatedly remind the team what problem we set out to solve.Nothing helps reduce scope creep more than coming back to the problem statement and the success metrics.You can solve many problems in many ways, but you can also build a beautiful product that solves no problems.

Avoid this trap with a few good habits:

In every design review, make sure the designers start by reviewing the problem statement. If it’s not clear, ask “What problem are we trying to solve?”
In every progress update to stakeholders, review the problem statement to make sure everyone continues to be aligned on the outcome.
Before finalizing designs make sure to ask yourself: “Am I feeling confident this is going to solve the problem we set out to solve?”

A final note

We are all professional problem solvers—technical problems, interpersonal problems, organizational problems, etc. You won’t escape solving problems.

“Problems are constant in life. When you solve your health problem by buying a gym membership, you create new problems, like having to get up early to get to the gym on time, sweating like a meth-head for thirty minutes on an elliptical, and then getting showered and changed for work so you don’t stink up the whole office. When you solve your problem of not spending enough time with your partner by designating Wednesday night “date night”, you generate new problems, such as figuring out what to do every Wednesday that you both won’t hate…Problems never stop; they merely get exchanged and/or upgraded.”

— Mark Manson (The Subtle Art of Not Giving a F*ck)

Any time spent refining your problem-solving skill, in yourself and in your team, is time well spent. If you’d like to take this even further there are five books I highly recommend:

If you’ve found additional habits, tools, or docs that help you tackle problems more effectively I’d love to hear it — tweet at me.

Sincerely, Lenny

Big thank you to Sean, Brett, and Yelena for reviewing early drafts.