5 benefits and challenges of transitioning from Developer to Product Owner (PO)

by Daniele Baldon

When I first heard about the Product Owner (PO) role, I thought it was not for me. I was a developer on a mission to code and create a product that solved any technical problem, while the PO was the person trying to fit as many tasks as possible into the plan!

However, I took on the role of PO just a few months ago after being a Java developer for seven years. If you are a developer, you are probably asking, “Why did you do that?” The answer is simple: for natural tendency. I was always heading towards this change, even if I didn’t realise it at the beginning. For example, my focus was already more on the product than the mere code itself. Therefore, I saw the PO role as one where I could capitalise on my soft skills more than my development skills. Moreover, I was growing fond of the new product that our team was developing at the time, so I wanted to be more involved in the decision-making process in both the short and long-term lifespan of the product.

The first months of the transition were neither easy nor hard. It was, and still is, rather complex. My daily life changed completely. For example, as a developer, a feature lifespan involves thinking about HOW to implement it, develop it, and solve merge conflicts. As a PO, however, the lifespan of a feature starts much before its birth. The client needs are translated into requirements that help to define WHAT will be the new product feature. It has to be analysed, estimated, and prioritised. It is also necessary to explain extremely well to the development team WHY the feature is needed. Once it is implemented, it needs to be validated against user expectations, and it will likely need a second iteration.

During the transition, I realised that having a developer background was an advantage for me. Let me share the five main ways that having a development background helped me, and the five main changes I had to embrace. If you are a developer wondering if the PO role is for you, I hope it helps you weigh your decision.

Benefits of having a development background

1. You know the inside of the product. You understand how it works internally, as well as all of the strengths and the weaknesses. This is especially helpful with a backend project with no outside visibility of what is being implemented. For example, if the product is an API, with visibility on the json requests and responses only, then the product decisions are tight with the technical solutions. Having a technical background can help you drive possible feature discussions with clients towards a more favorable terrain.
2. You’re able to provide a fairer approach to technical tasks. For example, code refactors, which are often marked as a low priority since they offer nothing visible to the user. How often do we hear about how the technical debt of the project hinders implementations, causes trouble, or non reproducible bugs? And then in the plan, there is barely space for those tasks?
3. Developer gibberish or “tech speak” actually makes sense, and you’re able to understand its implications for the tasks, projects, and planning!
4. You can help make sure development discussions are thorough and that all details are discussed. You can help guide conversations with development teams with the finest grain of detail. Suppose a developer complains that a task is technically impossible to implement or it has drawbacks that you did not consider. In that case, you can understand the reasons behind them and help to find possible alternatives which still meet the same business requirements.
5. Your project plan tends to have a bigger buffer, especially for the most technical functionalities, and, therefore, is more realistic. Integration tests, refactors, spikes, and unforeseen technical problems are left out of the plan too often. For example, while implementing a frontend button could take a known standard amount of time, what is the standard for a new CI/CD system? Or for setting up a Kubernetes cluster? There are systems that are very hard to VROM and plan; however, being aware of the complexity of the work can be an advantage in order to not underestimate them.

The changes to embrace

1. Your responsibility now involves what needs to be implemented, not how. Even if you don’t want to close IntelliJ or Eclipse, which has opened up on your screen by default for so many years, you’re going to realise you don’t have time for both POing and coding. Therefore, you must detach from the code. You cannot control everything. Perhaps you can do some Code Reviews at the beginning if you wish, but soon, the code probably will have changed so much that your code review will not be exhaustive anymore.
2. Think about your new responsibilities. Are they clear? It may seem like a simple question, but if you have a simple answer, then it is probably not the whole truth. It is important to define clear responsibility between you and the development team. In the beginning, you’ll probably want to participate in technical decisions. “I know the code!” you might think. Sure, for the first month or so, you might; however, code is changing every day, and you cannot control it! Moreover, you have a fantastic development team, so leave the technical decisions for them. It is not up to you anymore to discuss if a strategy pattern is the most appropriate implementation. Remember when you were complaining about POs trying to define database columns names?… Right?!
3. The decisions are more complex. One of the main changes of mindset I’m still embracing is with the decision drivers. When coding, if the acceptance criteria are well specified, then the final result can only be right or wrong. The unit tests are either green or red. The QA either passes or not. As a PO, answers are never 100% right or 100% wrong, black or white. It’s always a nuance. Experience can help, but experience is precisely what you will lack the most of in the first months! So what should help to drive your decisions are data and user feedback. User feedback is not always easy or fast to get, and sometimes decisions must be taken quickly. Data, instead, might be easier to get. But where is the data coming from? You and your company are likely to have access to tons of data already that no one paid attention to until now. Jira generates lots of data, for example, and there are plugins that help you to interpret them. The product itself can generate the data you might need. And I’m sure the development team would be more than happy to add a microbenchmark or a monitoring or logging system.
4. Start speaking in business terms, not technical terms. It is not as easy as it might sound, especially if you are used to talking about the same topic with the same team members and just from a different perspective. However, it is very important. When you explain a task from the technical point of view, you focus on the how-to and the details, taking for granted that you already understand what needs to be done. Meanwhile, when you explain a task from a business perspective, you are helping the developers understand what the task is about and why, regardless of the details. There are always several ways to implement the same business feature, while there is usually only one technical solution that solves one specific problem. Focus on the acceptance criteria, on extraordinary cases, how the user will use a feature and why, and try to pass down information the best you can to the development team.
5. Different achievements. One of the feelings I initially missed the most in my new role was the sense of completion. As a developer, once a task is done, you forget about it and go take on the next one. Once the QA has passed, you could be proud of your implementation. But what is the definition of DONE for a PO? Once the product is in production? Once a new feature receives positive feedback? In my opinion, such a question does not apply to a Product Owner. Instead, you must enjoy every day, every discussion, and every decision. There are no definitions of DONE, and no concept of finish. Once a feature is done, it might need to be modified. And once the product is in production, it is already time to improve it, since in the IT business everything changes fast.

Change is the only thing that is permanent, so enjoy the changes!