Only work on problems that matter

We’re in the business of solving problems. At a high level, we build products that solve problems for users. At a lower level, every ticket solves a problem. We have processes that solve our internal problems. Working on the right problems determines the success or failure of your product. And so you must find the right problems, articulate them, work on them, and stay no to everything else.

A powerful heuristic I used as a Product Manager was to always ask, “What problem are we solving here?” This reframes the question, “Why are we doing this?” But framing with problems tends to lead to more specific, less mushy answers. It forces you to dig a little deeper and do some critical thinking.

Product development is about doing productive things and not doing unproductive things. But it can be hard to know what “is productive.” It’s a bit abstract. Instead, do things that solve problems that matter, and say no to everything else. If you struggle to articulate what important problem a ticket solves, don’t do it. If you’ve forgotten why a process or meeting exists, cancel it.

People tend to describe feature requests and processes as solutions. I have read hundreds of requests like, “Put a button on this page that does ...,” or, “Build a report that shows ....” It’s tempting to take these at face value. But these tickets lack problem statements, and they stink. Why?

• I don’t have an intuition of why this matters or what problem it solves.
• I don’t know how painful the problem is, or how many users it affects.
• The suggested solution might not be the smartest solution.

I asked to chat with the client about this request for a report. After 10 minutes, I learned that they needed certain data for a monthly meeting. Also, I noticed that all the data they needed was available in the CSV download of their dashboard. I had a problem statement: One customer needs to see this specific data once a month for an internal meeting. We taught them to make their own report in excel, and we closed a big unnecessary project.

At the top of every ticket and project, write a problem statement. For a little bug, it can be as simple as, “When I press this button, I get an unexpected error message.” That sounds like a problem worth solving! Get everyone to do this. It is revealing, clarifying, and forces rigorous thought.

This also helps to cut down on processes. If someone wants to introduce a new meeting, ask what problem that meeting solves. Before suggesting some new bureaucratic solution, consider the problem. Ask provocative questions like, “We spend hours estimating tickets. Do estimates solve specific problems for us?”

Process work (meetings, scoping, estimating, planning) is categorically less productive than writing code. Do the bare minimum necessary to solve you process problems.

Just the other day, I was writing large, detailed project scoping documents for a client. I was in cruise control, because I always make documents like this. But this was a small team that communicated well. Between conversations and good tickets, everyone already understood the scope of the project. I wondered, “What problem does this document solve?” Without a clear answer, I set it down and focused on something else.

You will encounter problems that you shouldn’t bother trying to solve. Dave Evans and Bill Burnett refer to these as Gravity Problems. For example, “I’m trying to bike up this hill, and the darn gravity makes it too hard.” If you can’t do anything about it, it’s not a problem to solve. It’s a circumstance you must accept. Don’t spend any time trying to solve these problems.

I interviewed dozens of users for hundreds of hours at my last job. I wrote down every problem I heard, and sorted them by severity and frequency. This became the backbone of our product roadmap. But near the top of the list were some Gravity Problems:

• There’s a law that requires me to fill out a ton of unnecessary paperwork.
• My boss’s boss’s boss has a terrible strategy. He's also a jerk.
• Our industry is chronically understaffed, partly because revenue is low.

I’m not in the business of changing laws, my customer's boss’s personality, or their hiring budget. That's not in my sphere of influence or control, and it would be foolish for me to work on those problems. Write these things down. It’s good to know them. Internalize them, and empathize with them. These are important facts of life for your users and you. But do not spend your year trying to solve them. You’ll waste time, and make yourself crazy.

Writing down problem statements helps you see Gravity Problems, and work around them.