Product Developer: The Job Behind the Code
Earlier this month I wrote that writing code was never the point. The obvious question is the one I left unanswered: if the code isn't the job, what is?
I've been a developer for about twenty years. For most of them, I would have described my job as building things well. I still care about building things well. But the longer I do this, the more I think that was only half of it.
The phrase I keep hearing is that a product developer is a full-stack developer who also talks to product. It sounds reasonable. It is also wrong in a way that matters.
What I've learned is that the job is not to produce code. It is to own an outcome. The code is one of the consequences.
I'm writing this for people who might hire me — and for developers who already do this work without the title.
The title that explains nothing
For a long time I thought the role was additive. You take a good developer, add some product skills, and get someone who can move between the two worlds. The assumption was that more surface area meant more value.
The more I did it, the less it looked like a sum. It looked like a transfer of responsibility. A developer is accountable for the implementation. A product developer is accountable for whether the implementation was worth doing.
That distinction sounds minor. It changes almost everything: which meetings you need to be in, which questions you ask, what you do when the answer is "we shouldn't build this", and how you feel when the metric doesn't move after launch.
It also creates a tension I've stopped trying to resolve. Am I an engineer who understands product, or a product person who can build? The question assumes I have to pick a side. The role lives in the fact that I don't. I need enough engineering judgment to know what is possible and what it will cost, and enough product judgment to know whether it is worth the cost.
So no, it is not that I do more things. It is that I am accountable for more things.
What I actually do
Three things, mostly.
I decide what not to build. Most requests arrive as solutions. The job is to find the problem behind them, and then to be willing to say that the problem does not deserve a feature. The most valuable decision I make in a week is often a no.
I negotiate scope. Not to protect the team from the business, but to make the trade-off explicit: this is what we can do now, this is what it costs, and this is what we lose by doing it. A scope conversation that ends with "we'll do it all" is usually a conversation that hasn't happened yet.
I answer for the outcome. The work is not done when it deploys. Did the support tickets drop? Did the metric move? If nothing changed, what did we learn? Owning the outcome means being around for the part where the answer is uncomfortable.
What I don't do: replace a PM, design the interface, know every layer of the stack, or act as the cheap full-stack hire that patches a headcount gap. When the role absorbs those things, it stops being product development and becomes an organisational workaround.
There is no typical week, but there are two modes. Discovery weeks are conversations, data, options, writing. Execution weeks are prototypes, code, review, measurement. If I had to put numbers on it: 40% talking and deciding, 30% building, 20% reviewing, 10% discovering. The numbers matter less than the principle: where the uncertainty is, that is where my time goes.
The week isn't measured in hours of code. It's measured in uncertainty reduced.
This only works under three conditions: a bounded domain, identifiable users, and the right to decide. Without them, the role degrades into coordination. I've seen it work in a large company — Lingokids — because the domain was clear: billing, pricing, accounts. A large company doesn't kill the role. Distance from the problem does.
It is a senior role, but not because of years. It is senior because it requires judgment under ambiguity and the willingness to be accountable for things you don't fully control. You can teach the craft: how to talk to users, how to write a decision, how to measure. You can't teach the context; that is earned. It is not an entry-level job, but it is not a promotion by tenure either. It is a change of responsibility.
The case: account merging
The clearest example I have is account merging.
For years, support had a recurring case: "I forgot which email I signed up with." Behind it was a product problem. The same person could end up with two identities, and the product had no way to reconcile them. Support could not fix it. Engineering could not fix it with a better password reset, because the problem was not the password.
We decided to merge accounts. Not to improve the login flow, not to add another recovery path — to accept that a person could have two identities and make the system able to reconcile them.
That decision opened questions that were not technical in the narrow sense. What happens if one account has already been deleted? What happens to a subscription that lives in one store while the purchase history lives in another? What do we do with the data we cannot merge? Each answer changed the shape of the product.
We also decided not to build a support console that merged accounts by hand. It would have shipped faster. It would also have turned a product problem into an operational dependency, and it would not have scaled to ten thousand tickets. The capability had to live in the product.
Over the engagement, account merging closed roughly ten thousand support tickets that previously had no resolution path.
The hard part wasn't technical. It was deciding which problem we were solving. That is the job I'm describing.
What changed
The economics changed. Building software became cheaper. AI is the most visible reason, but not the only one. Better tools, better platforms, and a lot of boilerplate that no longer has to be written all push in the same direction.
It is easier to produce a first version, explore an idea, wire two systems together, learn a new stack. It is harder to decide what deserves to exist, verify what was produced, keep a system coherent, say no, and live with the consequences. It is harder to read code you didn't write and tell a plausible answer from a correct one.
It's easier to produce an answer. It's harder to know if it's the answer.
AI doesn't change the definition of the role. It changes the mix, and it removes the excuse that the job was writing code. AI doesn't change what I am. It makes the job I was already doing impossible to avoid.
What's still essential is contact with the problem. What's obsolete is the handoff — the model where product writes the spec, design designs, and development implements. The handoff was always a way to avoid accountability. Now it is also a way to waste the cheapest part of the process.
I wrote about this in "AI and me": the interesting development isn't that machines write code; it's that being wrong became affordable. This post is the other half of that argument. If being wrong is cheap, the scarce resource is knowing which wrong answer to pursue.
How I know it's working
I don't measure my work by what I ship. I measure it by what changes and what I stop having to put out.
Three signals. The metric moved — conversion, retention, support tickets, revenue. The operational friction disappeared — support stops fighting the same fire. The decision still holds up — six months later I can defend why we built it, and why we didn't build the other thing.
The last one is the most uncomfortable, because it is the one I can't put on a dashboard.
What I'm looking for
I'm not looking for a title. I'm looking for a problem.
A scale-up or a consolidated product with real users. A small or medium team. A senior IC role with ownership of a domain, not a coordination role. Remote, or Pamplona.
I don't want a handoff, a ticket factory, or a role that exists to save headcount. I want a domain where I am close enough to the users to know what "the right thing" means here, and have enough decision rights to do something about it.
If you have a product problem that needs someone who owns the outcome, let's talk. If you're looking for a pair of hands, I'm not your person.
The code is still there. It's just not the job.