Customers rarely hand you a problem statement. They hand you frustration: "This takes forever." "We got burned in the last audit." "My team doesn't trust the numbers." The product manager's real job is translation, turning that pain into a problem precise enough that engineers, designers and executives can all act on it.
Step 1: Separate symptoms from causes
A request for "a faster report" might really be about an auditor who arrives in two weeks, or a manager who can't explain a spike to leadership. I keep asking "what happens next?" until I reach the moment that actually hurts. That moment is the problem; everything before it is a symptom.
Step 2: Size it honestly
How many customers have it, how often, and what does it cost them in time, money or risk? A painful problem for three customers can still be the wrong priority. A mild annoyance for every customer every day can be the right one.
Step 3: Write a one-page problem brief
Before any solution, I write a page with five parts: the user, the situation, the pain in their words, the current workaround, and what success looks like for them. If the team reads it and can't picture a real person, I rewrite it.
Step 4: Go wide, then narrow
With the problem clear, generate several solutions, including ones that aren't software: a process change, a partnership, a default setting. Then pick the smallest version that would make the customer's next week noticeably better.
Step 5: Define how you'll know it worked
Agree on the signal before you build: a time saved, an error rate reduced, a workaround abandoned. Measure it after launch and be willing to admit when the first version missed.
A well-framed problem is half-solved. A badly framed one stays unsolved, however good the engineering.
I have used this loop on smart grid platforms, WiFi analytics, messaging apps and AI security products. The domain changes; the discipline doesn't. Clarity about the problem is the most valuable thing a product manager can give a team.
