From Developer to Product Owner

I have been a software developer for around ten years, but recently I was fortunate enough to be offered a different role as product owner (PO) for an Identity Platform. Keen to try something new, I accepted. However, after seven months in the role, I worked out that it wasn’t for me. This post will detail what went well, what went badly and what other developers can possibly expect if they choose to make the switch from engineering to product.

My background

I have been a developer ever since my Uni days and have worked at a number of different companies in London for around ten years. I’ve worked for Media companies, Finance and also a startup.

The Job

When I was contacted by a friend (and former colleague) about a “Technical Product Owner” role I was really intrigued. I have always felt that “pure development” roles don’t fit me perfectly as I enjoy more than just coding features. I enjoy coming up with plans, talking to a wide range of people in an organisation and taking on extra responsibility. I thought that perhaps this role could suit me perfectly but was also quite intimidated by how much of a challenge it would be. What made me accept the role was the realisation that it was such a unique opportunity that I could hugely regret declining in the future.


I took it on and was hopeful that a lot of my experience would prove relevant and that I’d pick up the other skills needed along the way.


Some of the challenges that I faced were unique to the initiatives that were in progress or planned. What I want to focus on here are the challenges that could apply to other developers making a switch to product and offer my advice.

Stakeholder management is different to working with a single PO as a developer

I was confident I’d be ok at stakeholder management. I have a lot of experience from my development days talking to non-techy POs, working out what they want and coming up with a plan of action. I assumed that as PO of a platform (with a more technical focus) engaging with the stakeholders that were non-techy and more business focused would be very similar. In some ways it is, but there are some differences that are very significant.

You need to have the confidence to dictate

As a developer, talking to your PO is all about coming to a compromise. As a PO, when it comes to dealing with stakeholders, compromise is still to be strived for but sometimes you have to dictate in the name of progress. Looking back, I wasn’t confident enough to dictate when it was necessary for a clear plan of action. I was very much aware of how important it was to be decisive, but still didn’t feel able to state “This is the plan, we’re going ahead” when I knew that they had expressed preferences that were only slightly different to my proposal.



I think this came from a subconscious feeling that I wasn’t in someway on their level. They seemed like the “real” POs to me as they could talk confidently about business terms such as revenue growth, user engagement and subscription funnels. I was more comfortable talking to the devs about techy details such as scalability, zero downtime deployments and firewall rules. Dealing with multiple stakeholders as PO in the same way that I had dealt with single POs as a developer led to too much compromise which resulted in a lot of back and forth. It took way too long for us to come up with a concrete plan of scope for our first release of a new feature.


Looking back, a key moment was when I was trying to get many stakeholders to agree on a plan of action. One day I told a more senior product owner something along the lines of “Hey, great news I just managed to get one of the stakeholders to agree with plan A”. To my disappointment he wasn’t very enthused with my update. His response was “It doesn’t matter, because we’re doing it anyway”. I thought that this was a strange thing to say at the time, but looking back I now realise its importance. In some scenarios it is impractical and inefficient to negotiate with every stakeholder because it prevents you from getting clarity on what you’re doing.


People more senior than me started to recognise the problem that I was facing. With their help a plan was put in place, communicated at a steering group and everything started to fall into place. It’s very widely known that when a team is working towards a clearly defined goal they are much more likely to get something of tangible value delivered. I have seen this first hand and realise just how important it is to have clarity from the top so that everyone understands exactly what’s needed.

Developers are used to looking at the detail - When the PO joins in, things don’t move

As a developer, I have always found estimation hard. Estimating at a high level, such as epics that have not been fully broken into stories, I find even harder. I can recall retrospectives in the past when former teams I belonged to have discussed why we think we vastly under-estimated a piece of work.


This past experience has (rightly or wrongly) made the developer in me very cautious to not overlook details that could contribute to underestimating. Other developers no doubt feel the same way.


When estimating high level epics as a team for future items on the roadmap, being super accurate is not important. Given the tendency of developers to need more detail, If the product owner supports the demands for “more analysis” or “spikes” you are left with analysis paralysis. It’s issues like this that can cause uncertainty to rumble along for too long and prevent a delivery roadmap from being formed.

A development background can lead you to present at too fine-grained detail

This sounds so obvious, but it is worth pointing out. I prepared a presentation to some non-techy stakeholders that showed user journeys and thought I was mindful enough of the business focused audience. To my astonishment, I received feedback that my message was far too detailed. Keep this in mind and get a second opinion (ideally before slaving away over your slides) to ensure you communicate at just the right level.

Stress makes you less effective

When things got stressful, being effective was a lot harder. Work felt exhausting and became miserable at times. Seeing that our “sprint planning” session was fast approaching in the calendar filled me with dread on the occasions I knew there weren’t enough stories prepared. At times it seemed impossible to create a backlog of work and switch to a more proactive, long term focus.


Seeing this issue, our delivery manager made the suggestion to put the work temporarily on hold and let the team work on whatever tech-debt they’d like for a sprint. This was a great idea as it bought us some much needed time and allowed us to finally get things in order. With stories prepared for a number of sprints, gradually our focus switched to more long term planning and things became much calmer.

A good support network is crucial

As a developer, you benefit from working closely with your peers. Pair programming, code reviews and informal chats typically occur multiple times per day and all help with knowledge sharing. This is made easier when you’re all at the same bank of desks working on the same thing.


As PO, it’s likely that you will sit with your team and far away from your other fellow PO peers. This means that the opportunities that do occur to knowledge share are highly valuable.

If a role doesn’t work out, it will still benefit you

As I mentioned at the start, the role wasn’t perfect for me. However I did gain a huge amount of experience in things that I’m hoping I can apply to other future roles. At the very least, I have a newfound respect for POs because I can honestly say from experience, it’s a tough role!