How to Move From Solving Problems to Owning Them
You get handed a brief. Somewhere upstream, someone has already decided what the problem is, why it matters, and roughly what a good outcome would look like. Your job starts after that. You scope it, you build it, you deliver it well, and the people who defined the problem move on to the next one.
This has probably been true for most of your career, and it has probably worked. Good execution earns trust. Trust earns bigger problems. But at some point the pattern stops moving anywhere. You keep getting better problems to solve, and you keep solving them well, and your influence on what gets solved in the first place stays exactly where it started. Somebody else is still deciding.
It is easy to assume that continuing to solve harder problems will eventually turn into strategic influence on its own. It rarely does, because solving and defining are different skills, exercised at different points in the process, and only one of them shapes what the organisation spends its time on.
What separates a contributor from an owner
A contributor receives a problem definition, usually in the form of a brief, a ticket, or a stakeholder request, and produces a solution. An owner produces the problem definition itself: what should change, what the work does and doesn't include, and how anyone will know whether it actually worked. That definition determines what gets built, what gets left alone, and what resources get committed before a single hour of execution happens.
This is not the same as seniority, and it is not the same as managing people. Plenty of senior people never move upstream, because their authority is used to approve decisions rather than to shape the questions those decisions answer. And plenty of people without a management title do it constantly, in small, unglamorous ways: asking what a request is actually trying to achieve before agreeing to build it, or noticing that a problem as stated will not survive contact with how the organisation actually works.
Problem definition has three parts, and they rarely get made explicit. There is clarity about what will actually be different once the problem is solved, which is not the same as what gets shipped. There are boundaries, because a problem left unbounded tends to expand until nobody can finish it. And there is a way of judging, afterwards, whether the thing worked, that does not depend on someone's opinion in the room. Most requests arrive missing at least one of these. Owning the problem means supplying the missing piece before agreeing to solve it.
A request that wasn't quite the request
One of the clearer illustrations of this involves a product manager whose company was about to lose a large customer over a missing feature. Sales had escalated. Leadership wanted a scope and a delivery date. On paper, the assignment was straightforward: build what the customer asked for, as fast as possible.
Instead of scoping the feature, she asked the customer what outcome they actually needed. It turned out the request, a full cross-system data integration, would only ever be used by around thirty percent of the customer's users. The rest ran an entirely different workflow that the feature wouldn't touch. The original ask would have taken four months and mostly served people who didn't need it.
She proposed something narrower: a lightweight integration that solved the same underlying workflow problem for the segment that actually had it, delivered in three weeks instead of four months. The customer took the faster option. Usage confirmed her estimate. The account stayed, at a fraction of the original build cost.
What made this an act of ownership rather than good execution was the order of operations. She didn't scope the request faster than anyone expected. She questioned whether the request, as framed, was the right thing to build at all, and she did it before resources were committed rather than after. The feature ticket described a solution. Her question uncovered the actual outcome underneath it, and the outcome, not the ticket, was what determined the right amount of work.
That distinction is worth sitting with, because it explains why some very capable people plateau at execution. Somewhere between forty and something-more percent of built features, according to the book this idea is drawn from, solve a problem that was defined incompletely in the first place. They work as specified. They just don't move the thing the organisation actually cared about, because nobody checked what that thing was before building started.
Where this actually shows up in your week
You don't need a mandate to start doing this. You need one recurring category of request where you already have enough context to ask a real question before accepting the framing that arrives with it.
That might be a recurring type of project brief that always specifies a deliverable without specifying what changes once it exists. It might be a stakeholder who habitually asks for a report, a dashboard, or an analysis, when what they actually need is a decision made easier. It might be a request that keeps arriving with a solution already attached, "build me X," when the honest first move is to ask what X is supposed to achieve and whether it's the only route there.
The shift is not to interrogate every request that lands on your desk. Most requests are well-formed, and treating each one as an invitation to relitigate scope will make you exhausting to work with rather than valuable. It is also not a licence to second-guess decisions in areas you don't understand; problem ownership depends on having enough context to be right, not just enough confidence to ask. The people who do this well pick their moments. They notice the pattern where framing keeps costing the organisation time or money, and they intervene there, specifically, rather than everywhere.
What tends to happen next is gradual rather than dramatic. You get consulted earlier, before a decision has hardened rather than after. Your framing of a problem starts influencing what gets prioritised, not just how well the eventual solution gets built. Conversations shift from "can you solve this" to "should we be solving this, and if so, how." None of that requires a new title. It requires the organisation learning, through repetition, that your read on a problem tends to be worth having before the problem gets locked in.
None of this makes execution less important. Somebody still has to build the thing, and building it well remains genuinely valuable; the point isn't that solving is beneath you, it's that solving alone has a ceiling. The people whose influence keeps expanding are the ones who occasionally step back from the request in front of them and ask whether it's the right request at all, and who have earned, through judgement rather than authority, the standing to say so before the work begins rather than after it's finished.
David Taylor
Interested in going further?
The AI-Ready Career develops this shift in full, showing how upstream problem ownership builds on the decision credibility and redesigned contribution covered earlier in the book.
Ad · Amazon affiliate link.
