Start with the problem, not the solution

Any time you do something new, it’s important to be clear about why you’re doing it, and to ask whether this action is the best way to achieve your goal.

This sounds obvious, but most people tend to jump straight to the solution rather than explicitly articulating the problem, which doesn’t always lead to the best outcome. 

Here’s what I mean: Your sales team tells your marketing team that they need a specific new glossy PDF. Your marketing and design teams work hard on it, finally unveiling it to the sales team. A month later, you find out: no one actually uses it, and the whole thing was a big waste of time.

There was an actual underlying problem embedded in the sales team’s request, but you failed to discover it, and your attempted solution didn’t actually solve it. For example, perhaps the underlying problem is: customers don’t know about Feature XYZ, and we’d like them to. Sales collateral is one way to achieve it, but it’s possible that the more effective solution would be revising the sales pitch to consistently talk about how valuable the feature is.

The point is: If you aren’t explicit about the problem, you can’t determine if your solution is the best way to solve it. 

If you explicitly specify the problem, you can enumerate many possible solutions and discuss their tradeoffs, selecting the best possible solution from that set.

To take this to the next level, you should understand that you’re actually engaging in the scientific method. You have a hypothesis about the world: “We think that if we do thing Y, it’ll lead to outcome Z.” Ideally, your outcome is measurable: “We’ll improve the win rate by x%” or “Customer satisfaction will improve by Y points.” The more objective you are here, the easier it will be to grade down the road.

This is an unnatural motion for most people.

As an example, a startup I was chatting with is trying to build an online community, and wanted to hire an engineer to build an app that the community can use to engage.

Here’s what I asked them:

• What is the problem you’re trying to solve? Why is it important to solve?

• What will you actually build (or do) to solve this problem?

• What does success look like? How will you know if it worked?

• Is there a lighter-weight way to test this?

In the case of this startup, they realized they could start to validate that same hypothesis in a lighter-weight way via a Facebook, Slack or Discord group. If it turns out people love it but there’s a specific thing that they want but can’t do on those platforms, then they’ll build the app. But if they can’t get anyone to join their group, they’ll be happy they didn’t commit the time and dollars to building the app from the get-go.

In sum, most people like to jump straight to the solution—hire a person, build a thing—without articulating what the problem is. Explicitly stating your assumptions will bring clarity about what you’re trying to do and whether or not it’ll actually work.