Photo by Tara Winstead: https://www.pexels.com/it-it/foto/arte-testa-pensando-consapevolezza-8378726/
A few days ago a colleague on my team who uses Claude Code shipped a feature that, back when I did his job, would have taken me more than half a day. He finished it in forty minutes, with quality and confidence. While I was thinking about it, I wasn’t thinking about how powerful the tool was. I was thinking about how my own career path—that transition from developer toward product ownership and broader leadership over the last few years—is turning out to be more prescient than I’d imagined.
I didn’t do it out of foresight, to be clear. I did it because at some point writing code all day stopped giving me what I was looking for. I wanted to understand the why of things, not just the how. I wanted to be in the room when the decisions about what to build were made, not just receive tickets to implement. It was an instinctive choice, partly self-interested. But in hindsight, it has put me in an interesting spot to watch what’s happening right now.
Value Migrates From the How to the What
The inflection point we’re at isn’t about AI “stealing programmers’ jobs”, the way the sensational headlines put it. It’s about something subtler: value is shifting. It’s migrating from the how to the what and why. And I see it every day, in conversations with the other professionals and managers I know, in hiring decisions that have already changed, in the way it’s now necessary to structure teams.
Companies don’t ask “how many developers can I hire” anymore. They ask “how do we maximise productivity with smaller teams and better tools”. It’s a radical change of perspective. In my role I increasingly find myself reasoning about how to integrate AI agents into existing workflows rather than how to scale the team. And that has enormous implications for anyone who today writes code as their main activity.
The autonomous AI agents we use daily aren’t glorified autocomplete. They do things that two years ago would have looked like science fiction: they take a poorly defined problem, decompose it, search the codebase for context, implement, test, iterate. We supervise them, of course. We correct them, often. But the volume of work they can produce, with the right guidance, is impressive. And that changes everything.
What I Look For in Teams Today
When selecting candidates or reviewing team performance, the questions have to change radically. I no longer care that much how fast someone writes code. I care how well they understand the problem we’re solving. I care whether they ask the right questions before starting, whether they anticipate edge cases, whether they can explain their choices in terms that make sense to the business. These are the things AI still can’t do well.
I know professionals who refuse to use Copilot or Claude Code because they “prefer to write everything themselves”. I get it, I really do. I come from there, I know that feeling of total control, that satisfaction of seeing the code emerge from your fingers. But from where I am now, I also see the risk. It’s a bit like the typesetters who refused desktop publishing because they loved lead. Romantic, sure. Economically sustainable, much less.
The transition from developer to product owner, or to any role where you define the what instead of implementing the how, doesn’t mean ceasing to be technical. On the contrary, in my experience it requires more technical competence, not less. But a different competence: I need to know what’s possible, what’s expensive, what’s risky, without necessarily being the one to implement it. You have to lead AI and agents the way a conductor leads musicians—you don’t play every instrument, but you have to know how every instrument should sound.
The developers I see making this transition well share traits I recognise in myself. They aren’t necessarily the most technically brilliant. They’re the ones who always asked a lot of questions, the ones who wanted to understand the why behind every feature, the ones who got irritated when they received vague specs. They’re the ones who always thought about the product, even when their official role was just to write code. If you recognise yourself in that description, you probably have half the work done.
Then there’s the matter of relational skills, and here I have to admit the shift was hard for me too. For years I avoided meetings with business stakeholders, treated them as interruptions of “real work”. Now they are my work. Translating technical language into terms a CFO can understand, negotiating priorities with a marketing team that wants everything yesterday, explaining to a board member why that “simple” feature takes three months: these are skills no AI can do yet, and maybe never will. They’re what makes me valuable today.
Specifying Is the New Craft
One thing I’ve learned in practice: the quality of the requirements you give the AI determines the quality of the output you get. It sounds obvious, but the implications run deep. When I write precise specs, contextualised, with the right constraints and the right freedoms, I get code that works. When I’m vague, incomplete, contradictory, I get garbage. That means the critical skill is no longer “can you code”—it’s “can you specify”. And specifying well requires deep understanding both of the technical domain and of the business one.
I’ve already seen small teams—five people max—produce output equivalent to teams of twelve, simply because they had someone who could define tasks the right way. I’m not talking about formal documentation, UML diagrams, or hundred-page technical specs. I’m talking about that ability to articulate what’s actually needed, to ask the right questions before starting, to anticipate problems. It’s a skill you can learn, but it requires a mindset shift.
The Leap Takes Humility and Courage
That said, I don’t want to paint too rosy a picture. The transition I went through wasn’t linear, and I see colleagues struggling enormously. It requires humility: accepting that something you knew how to do well is losing relative value, and that you have to invest in different skills. It also requires courage: stepping out of the comfort zone of code, where things are deterministic and controllable, to enter the ambiguous world of product decisions, where you always have incomplete information and stakeholders with conflicting agendas.
There’s also an ethical dimension here that worries and fascinates me. Using AI to accelerate development isn’t neutral. There’s bias in the models, there are implications for code quality, security, maintainability. You also have to be a little paranoid, you have to know when AI is doing something wrong even if it technically works. It’s a new responsibility, and it requires awareness and intention. You can’t delegate everything and hope it goes well.
The Bet to Make Now
What I see from where I sit is that technical leadership, product management, and tech strategy roles will be increasingly in demand and increasingly hard to fill. People coming from coding have an enormous competitive advantage over people arriving from pure business: they understand what’s possible, what’s expensive, what’s risky. But they have to make the jump. They have to stop identifying with the lines of code they write and start identifying with the problems they solve.
The false myth I hear most often from developers I talk to is “I don’t have time to learn this stuff”. But the time you save by using AI to write code—where does it go? If you reinvest it in further perfecting your coding skills, you’re optimising something that’s becoming a commodity. If you reinvest it in learning to think like a product owner, you’re building your future relevance.
The question I asked myself years ago, when I started this transition, was “what do I want to be doing in five years?”. The answer wasn’t “writing code even faster”. It was “having more impact, understanding the business better, being in the room where decisions get made”. That question is even more urgent today for anyone at the start of their path.
The future belongs to those who can define what to build, not only to those who know how to build it. I made that bet a few years ago, without knowing how relevant it would become. For anyone reading today, the advantage is that they can make it with more awareness. But they have to make it.
Key takeaways
The critical skill is no longer “can you code” but “can you specify”: the quality of requirements determines the quality of the output.
Time saved writing code with AI should be reinvested in learning to think like a product owner, not in polishing a skill that’s becoming a commodity.
The developers making this transition best aren’t the most technically brilliant: they’re the ones who asked too many questions and got irritated by vague specs.
Questions & answers
Why does a developer in 2026 need to think like a product owner?
Because the work of “writing code” has been compressed: a colleague with Claude Code ships in an afternoon what used to take a week. The bottleneck has moved upstream—understanding what to build and why. A developer who doesn’t develop product skills (problem framing, user research, prioritisation) becomes a substitutable executor. One who does develop them becomes more valuable than a classic product owner.
Isn't this a career change rather than a transformation?
No, it’s a layering. The developer-product-owner keeps deep technical knowledge—knows what’s feasible, where the risks sit, which trade-offs carry consequences. But adds a layer of product judgement: what deserves to be built, for whom, with what measurable success. It’s a rare and expensive combination, precisely because it requires two different ways of thinking.
How do you actually make the transition?
Three gradual moves: (1) start joining discoveries before sprint planning, not after; (2) propose success metrics before estimating the work—”how do we know this feature works?”; (3) say no (with alternatives) when a requirement looks wrong, not just when it’s technically nonsensical. Credibility built on those three behaviours accumulates and unlocks access to the conversations that used to be the PO’s territory.
Does the classic product owner become obsolete?
Not obsolete, but under pressure. A PO who doesn’t understand what AI can do risks asking for anachronistic features or drastically underestimating effort. A PO who understands how agents change the development rhythm stays central—but has to update their technical literacy. The role doesn’t vanish; the skill mix shifts.