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.

With AI agents, this becomes sharper. An agent executes a given task faster and more precisely than ever — and that's exactly why the cost of a wrong framing grows. If before you could still catch a mistaken task during the slow grind of manual work, with an agent "the wrong thing" is in production before you have time to doubt. Digging down to the problem before handing a task to an agent is not bureaucracy — it is safety engineering.

Speed of execution doesn't cancel the need to think. It amplifies it.

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.

The opposite also happens: someone frames the task so broadly that you can't get a grip on it. "We need analytics" or "make it more convenient." That's not a problem either — that's a direction. The job is the same: through questions, reach the specific obstacle blocking a specific person from doing a specific job. Without this, "more convenient" becomes an endless list of tweaks with no clear definition of done.

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.

A good check: write in one sentence whose specific pain it is and exactly what it is. If the sentence runs longer than two lines or contains "and" — there are probably two separate obstacles in there. That doesn't mean both don't matter; it just means you need to take them one at a time, otherwise it's unclear what exactly you're verifying after the release.

How this looks: one person with an agent

A concrete situation. You're maintaining an internal tool for an operations team on your own. A sales manager sends a message: "I need an export-to-Excel button on the client report." First instinct — hand the task to an agent. But before that — one question: "What do you do with that data afterward?"

The manager replies: "I send a weekly client summary to the director." Second question: "How do you do that now?" — "I take screenshots and paste them into an email. It's awkward." Third: "Does the director then open the spreadsheet itself, or just look at the numbers in the email?" — "No, just looks at the numbers."

The problem has changed. The person doesn't need Excel — they need to send the director a readable summary once a week without manual work. That could be an automated email sent straight from the system.

Now the task to the agent sounds different: "Build a weekly email report on clients with key metrics, sent on a schedule every Monday morning." The agent handles this task quickly — it's concrete. The result closes the real need, and the manager stops taking screenshots every week.

If you give the agent the original request — "add an Excel export button" — it will build it. Build it well: correct cell formatting, headers, error handling. The manager will say thanks, download the file, open it, copy the relevant numbers into an email — and keep doing exactly what they did before. No pain removed; you've just added one more step to the same process.

Sometimes resistance comes up at this stage: "I know what I need, just do it." That's not a reason to give in — it's a reason to compress the questions down to one: "Fair enough, and how will this be used?" One question rarely causes irritation. The answer to it is usually enough to tell whether you're picking up the right task.

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.

A good check before handing a task to an agent or starting implementation: can you state the problem in the name of a specific person, without mentioning any technical solution? If yes — you can move forward. If not — it's worth stopping and asking one more question. And you learn the problem not at your desk but in contact with the user — that's what the next essay is about.

What this means in practice

The skill of digging for problems is a muscle built through practice. At first, two or three questions feel awkward and unnecessary. Over time it becomes automatic: a task arrives — the first question is already in your head. Three minutes at the start saves three days at the end.

Common mistakes people make most often:

  • Taking the solution for the problem. "We need an export button" is already a chosen mechanism, not a job. If you take that literally, the work is pointed the wrong way from line one.
  • Asking one question and stopping. One "why" strips the top layer but rarely reaches the core. You need two or three steps in a row — that's when the wording slides off the mechanism and onto the job.
  • Stating the problem too broadly. "Users find it inconvenient" is not a problem, it's a feeling. A problem: a specific person, a specific job, a specific obstacle.
  • Delegating the digging to the agent. An agent is good at executing what it's given but can't challenge the framing. If the task is wrong, it executes the wrong thing quickly and well. You do the digging; the agent gets the verified task.
  • Forgetting to write down the problem statement. You dug down to the problem, explained it to the agent — and the next day you don't remember exactly what you agreed to build. One sentence with the problem statement at the top of the task saves questions and rework.

What's next

A named problem is still a hypothesis until it's been checked in live contact. How to arrange that contact — in "Contact with the user". Once the problem is confirmed, the next step is to find the smallest working way to close it: "The smallest valuable slice". All the product discipline described in the "Product engineer" section is built on top of this first step.