From PM to Product Engineer: Why I Made the Switch
For a while, my job title said Product Manager and my career was moving in what everyone agreed was the right direction. More seniority. More strategy. Further from the code.
Then I started paying attention to what I actually enjoyed, and the two things didn't quite line up.
What I Missed
I came into product from engineering. I'd spent three years at Andela writing React applications for clients like Coursera, building clinical research tools at UMed, working closely with the people who were actually making things. When I moved into PM roles, I brought that engineering background with me — and it was genuinely useful. I could read a codebase, spot an unrealistic estimate, write a spec that engineers didn't have to mentally translate before they could act on it.
But over time, as I moved further into product leadership, something started to feel off. I was spending more time in Confluence writing documents that described features than I was spending anywhere near the actual product. I was in prioritisation meetings and stakeholder updates and roadmap reviews. All necessary things. But I missed the part where you make something.
The thing I kept noticing was that the most satisfying moments in my product career were never the roadmap presentations. They were when I discovered that 15% of transactions on BantuPay were failing because users couldn't reliably type 42-character wallet addresses, and I designed a username-based system that dropped errors to 2%. They were when I built the UAT system for SwissPay from scratch — Google Forms, Apps Script, automated reporting — because we needed something that worked and had no budget for a tool. They were when I was close enough to the problem to see it clearly, and close enough to the solution to actually build it.
I wasn't just a PM who happened to understand engineers. I was someone who wanted to build things, who had learned product thinking along the way, and who had been gradually moving away from the part of the work I found most alive.
The Label Problem
"Product Manager" is a job that means radically different things in different organisations. In some companies, a PM is deeply technical — writing detailed specs, reviewing PRs, making architecture-adjacent decisions. In others, a PM is primarily a roadmap prioritiser and stakeholder communicator, with engineers handling every technical decision. Both are legitimate. But they're not the same job.
I kept finding myself in roles that wanted the second version while I was instinctively doing the first.
The label "Product Engineer" is newer, less standardised, and sometimes misunderstood — but it describes something real. It's the person who can write a feature spec AND build a prototype of it. Who can sit with a data scientist and understand what they're explaining AND translate it into product requirements. Who can do a code review AND give feedback on user flows. Who can ship a working MVP and also think clearly about what it should become.
It's not about doing two jobs. It's about having a different kind of depth — one that makes you more useful at the intersection of product and engineering, and more credible on both sides of the table.
What the Transition Actually Looked Like
I didn't make a sharp turn. It was more like a gradual course correction.
At Truss, working on the AI/ML data platform, I found myself spending more time than my job description required thinking about the technical architecture of the annotation workflows — not just what the product should do, but how it should be built. I was working directly with data scientists and ML engineers, and the conversations that felt most useful were the ones where I could engage with the technical reality, not just translate from it.
At NeuroCare AI, the co-founder role meant I had to be the person who did things. When you're building something early-stage and there's no engineering team yet, you write the specs and you build the thing. I've been using Claude Code, Kiro, Lovable, and V0 — not as curiosities but as actual tools in a real build process. That's reoriented how I think about my own skills and where I want to sit.
And then I built Tracklo — my own AI job search tool — in a day. It's live, it works, it's built on a real stack, and I built it myself. That felt like something I needed to do not just because the tool was useful, but because I needed to prove to myself that the skills were real.
What I Gave Up and What I Gained
The honest answer on what I gave up: clarity. "Senior Product Manager" is a well-understood title with a clear career ladder, known compensation bands, and a predictable interview process. "Product Engineer" is still being defined as a category, which means every conversation about it starts with an explanation.
There's also a version of this transition that reads as indecision — like someone who couldn't commit to being a PM and couldn't commit to being an engineer and ended up somewhere in the middle. That's a real perception risk, and it's worth naming.
What I gained is harder to articulate but clearer to feel. I'm in conversations where I can be more useful. When I'm talking to an engineering team, I'm not translating from a product perspective — I'm speaking the same language. When I'm talking to a founder or a business stakeholder, I can give them a realistic picture of what's actually possible and what it will take, not a PM's polite estimate that the engineers will quietly revise.
I'm also just more interested in the work. That sounds like a small thing. It isn't.
Who This Move Makes Sense For
Not everyone should do this. If you're a PM who genuinely loves the strategic, stakeholder, and communication-heavy parts of the role — and finds the technical depth a necessary evil rather than an interesting problem — this is probably not your move.
But if you came from engineering and find yourself frustrated by how far removed PM work has taken you from the actual product, it might be worth asking whether the label is serving you or constraining you.
And if you're early in your career and trying to decide between engineering and product — consider whether you have to choose. The most interesting work I've done in the last few years has been in the space between the two.
The industry is starting to catch up. More companies are creating Product Engineer roles explicitly. More engineering teams want PMs who can speak technically. More product leaders are realising that the people who can do both are often more valuable than two specialists operating in parallel.
The category is real. The work is real. I'm glad I stopped pretending to be one thing when I was clearly more interested in being something else.