How I engineered my transition into product

A product owner at one of my last engineering roles said to my face that I wouldn't be a good PM. At the same time, everyone and their mother was telling me how great it was that I was a woman in software engineering, and that I really shouldn't leave. But despite coming from a family of computer scientists and software engineers, I realised I didn't want to be one.

This isn't a grand and transformational kind of story. My transition wasn't "waterfall", there was no master plan I designed up front and executed. I took the next step that made sense, then the one after that.

It definitely was intuitive at the time. But looking back, I "agile"-engineered my way out of engineering and into a technical product role that suited me far better. Plenty of people told me it was the wrong move – more engineering roles out there, why throw it away. They weren't fully wrong about the odds and the market, but I am glad I didn't listen.

A bit of background about me

Some context for my specific story. I grew up surrounded by computer science – my dad is a software engineer, my mum teaches computer science, and my younger sister went the same way. As a teenager, I did algorithmics competitions and was good at it. But I noticed early that I didn't love it the way some of the people around me clearly did.

So I rebelled... I went to a business school instead of studying computer science. Even then, I had a vague idea of what I wanted, though I didn't have the word for it yet. I wanted to be the bridge between engineers and business. I knew I could communicate, problem-solve, and work well with people.

My internships followed that instinct, they were tech-adjacent but on the business side. Then I became a consultant at one of the "Big Four", and that's where I hit the first big wall. I found this kind of work way too vague, with way too much fluff-talking. I asked to be moved onto a software development project instead, which fortunately was approved. I wrote some code and liked it. Maybe engineering was for me after all...?

How I knew engineering wasn't for me

After graduating, I moved to London and managed to get an entry-level software engineering role. And when there was an interesting problem to solve, I solved it, wrote clean code, and got good feedback. But most of the job wasn't that. It was implementing straightforward stuff on my own, fighting with libraries, losing hours to some setup that wouldn't cooperate. I found it really boring, so I procrastinated, and my output was low – which was the second big wall and became the theme of my engineering experience.

Looking back – this was the important signal. When you are capable of quality work but consistently uninspired and unproductive, this might suggest the role is the problem and not you... I wasn't bad at software engineering, I was bored by most of what the job actually was, day to day.

I didn't realise it at the time. Without an engineering degree, I felt like an imposter and thought more education would fix it. I got accepted to a Software Engineering MSc at UCL, and actually ended up loving it. This might sound surprising after the previous paragraph, but studying software engineering wasn't actually being one. I enjoyed learning the theory and difficult concepts and doing research for my thesis. Again, in hindsight I now know this was telling me that I like the thinking but not the reality of the building. But I read it as "I like engineering after all" instead of "I like the parts of engineering that aren't the actual job."

When I graduated, I took another engineering role and truly struggled in this one... The same pattern appeared but much stronger – no interesting problem-solving and a lot of wrestling with tooling. The parts I enjoyed the most were presenting the work to clients and understanding their requirements and needs. That's how the idea of moving into product started forming.

This is where I spoke to the product owner, and he told me I wouldn't be good at product work. To be fair, he was looking at an engineer who was not very productive and clearly wasn't enjoying her work. I guess he drew a conclusion about me, but it was the wrong one.

When you are capable of quality work but consistently uninspired and unproductive, this might suggest the role is the problem and not you

The steps I took to transition into product

I am so glad I didn't take his opinion too personally. But I needed some evidence to see if the product path is right for me, and there was an internal onboarding tool which needed some love. So I volunteered to clean up the backlog, help prioritise and scope it out. I enjoyed it much better than coding, and got some positive feedback from the team. I figured I could start acting like a product manager before anyone gave me the title.

I also knew it was not going to be easy to switch roles between companies. I tried sending a few CVs for product roles and got the same response each time: "not enough experience". I briefly looked at product certifications online, but I'd just graduated and didn't want to sink money into an expensive course I wasn't sure would even help.

I decided to look for software engineering roles, but to find a company where it would be easier to transition internally. I was open about it from the beginning, even during initial interviews. It felt a bit risky – you're supposed to sell yourself as really committed to the role you're applying for, but I wanted to find the right place. 

I got somewhat lucky, and not long after I landed at an AI drug-discovery company through a friend's recommendation. Early on, I was upfront with my manager: I was committed to being a good engineer on the team, but I saw myself in product long-term and wanted to grow in that direction.

I figured I could start acting like a product manager before anyone gave me the title.

The engineering work was a bit more interesting there, which helped – but I was also making my interest in product work deliberately visible, even more in my actions than in just words. Within the first months, I'd spoken to every PM internally, shadowed their work, and volunteered for the PM tasks nobody owned. This way, I was making the internal case for myself continuously. Oddly, that also motivated me to show up for my engineering tasks better – I really cared to make a good impression.

The timing worked out well for me. The product manager for my team left, and there was an obvious person to fill the space. About seven months in, they offered me the switch to a technical product manager role.

Now, I need to be honest about one important factor that worked in my favour. As a small AI drug discovery company, there were no external users or clients to sell to. The product work was internal, for the internal AI scientists and drug discoverers. That took away the commercial aspect of a product role and made the jump much smaller. I was moving from building internal tools to shaping them, not learning to sell to enterprise clients or to optimise B2C e-commerce metrics. I got to make the transition on the easiest possible terrain, and I wish I could say it was intentional.

But many things I did were very intentional. The key takeaway from this part of the story is that luck matters, but you can make yourself the obvious person for it to land on. And what made me that person? I did the free online courses and read the product books, which gave me the lingo, but I don't think this mattered that much. What mattered was the visible, repeated, perhaps slightly annoying act of showing up as a product person, and then waiting for the right opportunity. 

Succeeding after the role change – what skill gaps I had to fill

The drug-discovery company eventually went through major restructuring, so I was looking for a new role again. Technical PM is a niche, and having a software engineering background turned out to be a huge advantage. 

I landed a really good B2B role: PM for an internal data platform, built from scratch, bringing the data of five merged companies together into a single web product. Conceptually hard, technically hard, and communication-hard – but it was comfortable terrain for me. It was the kind of technical, internal-facing problem I already knew how to think about. More importantly, it was the kind of work I really enjoyed doing (and was so grateful to be able to do all the brainstorming, planning, and thinking, but not having to actually implement it!)

Then the third big wall appeared. They wanted me to be the PM for a user-facing data API, designed and built from scratch. Which meant the big commercial part I'd managed to avoid as a PM so far. This was the biggest gap in my product skills. 

But this time, despite some worries and hesitations, I didn't turn around to look for a different path. I decided I wanted to get over that wall. That difference is the whole point – the earlier walls were signals I was in the wrong place, and this one was a signal I had somewhere to grow.

So I got involved. And since then, I've worked closely with account managers, customer success, and revops. I've planned releases and go-to-market. I've built commercial enablement tools to help the team sell our data to clients who aren't always technical. I've been involved in pricing strategy. Now, I meet clients, demo and pitch the API every week, I run user research and analyse usage data.

The product manager role is a unique one. It can span all or some of user research, product design, product ownership (Jira tickets and backlog), data analysis, some marketing and sales, and most recently, working with AI tools and product prototyping – and the mix is different everywhere. No one arrives at a PM role having it all. What matters is being willing to walk straight into the part you're worst at and get involved, as much as possible, until it's not the part you're worst at anymore.

The earlier walls were signals I was in the wrong place, but this one was a signal I had somewhere to grow.

The method that comes out of my story

My personal reflection from my story is that I don't regret the engineering years, but I don't see them as "everything happens for a reason" either. I really struggled back then, but it's what made me a technical PM rather than a generic one. And I'm grateful to my past self for the agile approach – for taking the next sensible step instead of waiting for a grand plan, even though I only understood it as a method long after the fact.

And to extract a general method from my personal story, this is what I would share with someone trying to engineer their own role change:

• Read your own signals. Liking computer science isn't the same as liking software engineering. Liking to design isn't the same as liking to build. And if you're producing good work but you're consistently slow and unmotivated, treat that as a data point, not a failure – the role might be the problem, not you.
• Act like the new role before anyone gives you the title. In your current role, find the work related to your target-role that nobody owns and volunteer for it. You don't need permission to build evidence. Most importantly, the evidence for yourself. But also for the future – that evidence is what matters when interviewing, not just stated ambition.
• Don't force transitioning between jobs, find a job to transition within. Switching function mid-job is hard. Consider finding an employer who's open to the move, and say so out loud, even in the interview. It feels risky, but if you have the time it will get you to the right place.
• Make yourself the obvious choice, repeatedly. You can't manufacture an internal job opening. But you can make sure that when it appears, you're the first person people think of. Visibility beats credentials – the courses gave me the vocabulary, but showing up got me the job.
• Walk straight into the gap you're worst at. Nobody arrives at a new role complete. When that gap appears, get involved fast and deliberately, until it's not what you're worst at anymore.

And something much less concrete is learning to tell the two kinds of "walls" apart. Some walls you hit mean you're in the wrong role and place. Some mean you've found somewhere worth growing and stepping outside of your comfort zone.

----

Marta is a Senior Product Manager with over 10 years of experience in tech & AI, who moved from software engineering into product. She now mentors people in product and beyond on technical depth, career transitions, and career growth.

She is also an ICF-accredited, neuroscience-informed coach with over 200h coaching & mentoring experience. She holds a PGDip in Applied Neuroscience, and writes Mind Body Dialogues, on the evidence behind neuroscience and self-help.