How I Transitioned from Engineer to Product Manager (and Back Again)

My career has made two significant pivots. The first was from software engineering into product management. The second was from product management back toward engineering — this time as a Product Engineer rather than a pure developer.

Both transitions felt uncertain from the inside. Both turned out to be the right call. Here's what the journey actually looked like, what transferred and what didn't, and what I'd tell someone considering a similar move.

From Engineering to Product: What I Was Looking For

I joined Andela in 2018 as a Software Engineer. I spent three years building React applications for companies like Coursera and UMed. It was good work — technically interesting, with clients who had real scale and real problems.

But I kept noticing that the conversations I found most engaging weren't about implementation. They were about what we were building and why. Why this feature and not that one? Why are users abandoning the flow at this point? What's the actual problem the client is trying to solve, and is this the right solution for it?

These weren't questions I was supposed to be asking as an engineer. My job was to build what was specced. But I kept asking them anyway — in PRs, in planning meetings, in conversations with designers and client PMs — because they seemed more interesting than the implementation choices I was hired to make.

That's usually the first sign that a PM transition might be worth exploring.

The move happened when I joined Bantu Blockchain as Technical Product Owner. It was a jump rather than a step — going from engineer to owning the product roadmap for a blockchain wallet. I didn't have a formal PM background. What I had was an engineering foundation that meant I could talk to the team in their language, a genuine interest in the user problems, and the willingness to learn everything I didn't know about product process fast.

What Engineering Gave Me That PM School Can't

The most useful thing I brought from engineering into product wasn't technical knowledge. It was a particular kind of thinking — systematic, specific, suspicious of vagueness.

Engineers are trained to think precisely. A requirement that says "it should be fast" is not a requirement. A requirement that says "the transaction confirmation should appear within 2 seconds on a 4G connection" is. That precision habit, applied to product requirements, makes everything downstream better — better estimates, better testing, fewer misunderstandings between product and engineering.

I also had credibility in engineering conversations that non-technical PMs often spend years trying to build. When I said something would take longer than the stakeholder expected, I could explain why in terms that engineers recognised as accurate. When I pushed back on a technical estimate, engineers knew I wasn't doing it from ignorance — I was asking because something didn't add up. That two-way credibility changes the quality of the conversation.

The second thing that transferred was a direct relationship with the product as a built thing. Technical PMs who've never written code sometimes have a slightly magical view of software — they understand it conceptually but not practically. They don't viscerally know why refactoring is hard, or why adding a field to a form might require database migrations that touch three other systems. I knew these things, which made me a better partner to the engineers I worked with.

What I had to learn: almost everything else. User research methodology. Prioritisation frameworks. Stakeholder communication. Roadmap planning. How to run a sprint without becoming the scrum master. How to say no to a feature request in a way that doesn't make an executive angry. How to use data to make an argument when the data is ambiguous. These things are learnable, but engineering doesn't prepare you for them — you have to go through the uncomfortable period of being bad at them before you get good.

The Middle Years: What Good Product Work Looks Like From the Inside

At BantuPay, I had ownership. Full ownership. Product vision, roadmap, user research, prioritisation, go-to-market, metrics, the works. It was one of the most formative experiences of my career, partly because the scale was real — 87,000 users, 147 countries, $23M+ in transactions — and partly because blockchain wallet UX in 2021–2023 was genuinely hard.

The best PM work I did in that period was the username system. Discovered a problem (15% transaction failure rate due to address input errors), diagnosed it correctly, designed a solution that was simple enough to work, spec'd it in a way engineers could build, and tracked it through to an outcome (2% failure rate). That's the PM job in miniature: understand the problem, design the solution, enable the build, measure the result.

At Winnov8, the SwissPay role added vendor management and cross-functional coordination to the mix — navigating the relationships between compliance, engineering, design, and marketing simultaneously, while keeping a complex SoftPOS integration on track. This was the stakeholder complexity side of product that I hadn't fully experienced before. Alignment across functions where each function has legitimate but different priorities is its own skill set.

What I noticed through all of this: the PM work I found most satisfying was always the work that kept me close to the actual product. The user research, the problem diagnosis, the spec writing, the UAT. The work that took me furthest from those things — executive presentations, long roadmap planning cycles, stakeholder management that felt more like politics than problem-solving — was where I started to feel the pull back toward building.

The Second Transition: Back Toward Engineering

The move back toward engineering wasn't a rejection of product. It was a recognition that the thing I want to do is sit at the intersection — close enough to the build to have real influence on how things are made, not just what gets made.

"Product Engineer" as a category is relatively new and still inconsistently defined. But the underlying idea is real: someone who can write code and think in product simultaneously, who can contribute directly to the build while holding the bigger picture, who doesn't need to be separated from the technical work by a spec and a handoff.

I'd argue that this is actually where I'd always been operating in my best moments — writing the UAT system myself at Winnov8, getting deep into the data architecture at Truss, using Claude Code and Kiro to ship the NeuroCare AI MVP with a managed engineer rather than handing off a spec and waiting.

The label finally matches the work.

What I'd Tell Someone Considering Either Direction

Engineer to PM: Don't wait until you feel ready. You'll learn the product craft by doing it, not by preparing for it. Your engineering background is a genuine advantage — use it, don't apologise for it, but also be honest about the things it doesn't give you and learn them actively. Find a role where technical depth is valued, not just tolerated.

PM to Product Engineer (or back to engineering): The credibility question is real. You'll encounter scepticism — people will wonder if you're still technical enough after years in product. Answer it directly. Build things. Build things in public. Blog about the technical decisions you're making. Having a portfolio of things you've actually built is worth more than any amount of explanation.

Both transitions: The skills that transfer are the ones that are about thinking clearly — about problems, about users, about systems. The skills that don't transfer are the process and craft skills specific to each role. Be honest about which category each of your skills falls into.

And remember that a career that has moved in more than one direction is not a career that lacks focus. It might be a career that has accumulated a kind of range that's genuinely rare and genuinely useful.

That's the story I'm still writing.