We are in the business of solving problems. Products solve problems for users. Tickets solve problems. Processes solve problems. Working on the right problems is the single biggest determinant of whether a product succeeds or fails.
The most useful heuristic I ever developed as a PM was to always ask: "What problem are we solving here?" It's a reframe of "why are we doing this," but it produces less mushy answers. It forces specificity, and it surfaces the things nobody had a good reason to be doing in the first place.
Don't take solutions at face value
People describe feature requests as solutions, not problems. "Put a button on this page that does X." "Build a report that shows Y." A ticket with no problem statement stinks: you don't know why it matters, how painful the underlying problem is, or whether the proposed solution is even the right one. At the top of every ticket and every project, write a problem statement. For a bug it can be as simple as "when I press this button, I get an unexpected error." Get everyone to do it. It is clarifying, and it forces rigorous thought.
Apply this to process, too
The same question cuts through process bloat. If someone wants to introduce a new meeting, ask what problem it solves. Ask the uncomfortable ones — "we spend hours estimating tickets; do estimates actually solve a problem for us?" Process work is categorically less productive than writing code. Do the bare minimum needed to solve your actual process problems, and no more.
Gravity problems
You'll also encounter problems you shouldn't try to solve. Dave Evans and Bill Burnett call these gravity problems: "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 isn't a problem to solve — it's a circumstance to accept. Write these things down. Internalize them. Empathize with them. But do not spend your year trying to solve them. Writing down problem statements is what helps you spot gravity problems so you can work around them instead of smashing your head against them.
Previous
Be ahead on tickets. But not too far ahead.
Coming soon
Next
Don't solve non-problems.
Coming soon