Almost every task reaches an engineer already dressed up as a solution. "Add an export-to-Excel button." "We need a dashboard." "Add a date filter." It's convenient — there's something to pick up and work on. And that's exactly the trap: a solution is merely someone's answer to a question that was never spoken aloud. Build literally what you're asked for, and you build someone else's guess and pass it off as a product.
Product thinking starts with the reverse move: strip the request back down to the problem. Not "which feature should I build," but "what job is this person trying to get done, and what's getting in their way." Until the problem is named, any solution is a blind bet — even a technically flawless one.
A request speaks in solutions
People phrase their wants as ready-made actions, because that's easier to think about. An internal stakeholder, a customer, a colleague — they all bring not a problem but the first solution that came to mind. An "export button" is already a chosen mechanism. Hiding behind it is something like "I need to move this data to where I actually work with it." And "where" might turn out to be something other than Excel, and "move" might not be a one-off export but a recurring reconciliation.
The danger isn't that the person is wrong. They know their own pain better than anyone. The danger is that they've already taken a design step for you — chosen a solution — without seeing the other options and their costs. Accept that step as a given, and you inherit someone else's choice along with all of its blind spots.
How a problem differs from a solution
It's convenient to hold a problem as a triple: who, what job they're doing, and what stands in the way. "A seller is loading new inventory onto the marketplace and can't enter five hundred items by hand in one evening." Here there's a subject, their work, and an obstacle — and not a word about how to fix it.
A solution is already one of the ways to remove the obstacle. There are always several: importing a spreadsheet, loading via an integration with the accounting system, copying from a template, a temporary assistant on the marketplace's side. Each has its own cost, its own timeline, its own risks. The request "give me Excel import" collapses that entire fan of options into a single branch — and usually not the best one.
A useful lens here is to view the product as something a person "hires" to do a job. The user doesn't want a drill, they want a hole; they don't want an export button, they want the data to end up where they make decisions. The question "what job was I hired to do?" pulls the conversation back from the mechanism to the task.
Digging down to the job behind the request
The tool is simple and almost blunt: for every request-as-solution, ask "what are you trying to do?" and "what happens if it isn't there?" Two or three such questions in a row, and the wording slides off the mechanism and onto the job.
Take the running marketplace case. A seller asks for "bulk product upload via Excel." First question — what are you trying to do: "load the entire catalog when going live on the platform." Second — what's stopping you now: "one card at a time is a week of work." Third — what happens if I don't give it to you: "I miss the season and go to a competitor." The problem has surfaced: a new seller needs to stand up a five-hundred-item catalog in a reasonable time, or they don't launch at all. Excel disappeared from this framing — it was just one of the guesses. It might turn out the seller already has an export from their own system, and an integration would solve the job better; or maybe a template plus error checking is enough. The solution is chosen after the problem is named, not before.
The same discipline guards against the opposite extreme — bloat. When a problem is framed narrowly and honestly, you can see that half the "obvious" requirements solve not it but an imagined one. A named problem is both a list of what to build and a list of what not to build.
Why this is the product engineer's first step
Everything that follows in product work rests on this step. You can't choose an outcome metric if you don't know which problem you're measuring — you'll be left measuring feature output. You can't carve off the smallest valuable slice if you don't understand what actually creates value. You can't own the result all the way to the user if the result is defined as "shipped a feature" rather than "removed the pain."
For a product engineer this matters especially, because one person carries the whole path — and there's no one to back them up at the entrance. On a large team, a misunderstood task is sometimes caught by an analyst or a tester. When one person builds the product with AI, an error at the entrance passes through unobstructed. AI will quickly and eagerly build exactly the guess you gave it. The more powerful the executor, the more expensive an unnamed problem becomes — it will carry the wrong thing all the way to production.
That's why the first skill of the product specialization is not to invent solutions but to stop half a step earlier and ask: what job is this person trying to do, and what's getting in their way. Solutions can wait; the problem comes first. And you don't learn it at your desk but in contact with the user — which is what the next essay is about.