13 Oct A Three-Step Framework For Solving Problems

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

Answer the following question

• 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 we have solved the problem?
• Audience: Who are you building for?
• What: What does it look like in the product?

 Project Title 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?
• There are infinite problems to tackle — your goal is to feel confident that this problem is worth your team’s time right now.

 Success: How do we know if we’ve solved this problem?A few tips for this step:

• 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. How: What is the experiment plan?… Proposed timeline: When does it ship and what are the milestones?…
Step 2Problem 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:

1. I take a crack at Step 1 (but again, it can be anyone on your team that’s passionate about the particular problem)
2. 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.
3. If the feedback is converging and the team seems aligned, great. If not, pull everyone together and chat through disagreements in person.
4. 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.
5. 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 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:

1. 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?”
2. In every progress update to stakeholders, review the problem statement to make sure everyone continues to be aligned on the outcome.
3. Before finalizing designs make sure to ask yourself: “Am I feeling confident this is going to solve the problem we set out to solve?”

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.