
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.
19 |
Create your profile
Only paying subscribers can comment on this post
Check your email
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to log in.