In a branch like ours, change is a constant. New technologies, shifting customer needs and constantly evolving work methods are the fuel of this industry. And for some developers, there also comes a time when they start thinking about where their career should go next. One path that is chosen again and again by developers is the transformation into a product owner.

This career change is not trivial. After all, product owners embody a key role in agile development teams, with responsibility for product design and implementation. While developers are the ones who write the code and solve technical problems, product owners are responsible for defining product specifications, prioritising features and communicating with stakeholders.

In this blog article, our Xperts take a closer look at the journey from developer to product owner. We will explore the reasons, motivations and challenges that accompany this career change. The article is primarily aimed at developers, but also offers exciting insights for anyone interested in the different roles within agile software development.

Phase 1: Before the decision

Developers are confronted with situations in everyday project work that fall in to the area of responsibility of a product owner. It happens time and again that developers drive topics forward, moderate meetings or provide conceptual input for technical decisions. In addition, there are unclearly formulated requirements and technical stalemates that require a consensual solution.

Despite its closed nature, the Scrum process also offers open flanks that confront development teams with the time-quality-cost-target conflict. To meet these challenges, skills are often needed that go beyond software development. Communication plays a key role here.

Developers slip into these situations because they bring a certain skillset with them. In addition to their technical skills, they are interested in the big picture and usually have a better overview of the project than the team scope dictates. They also think outside the box, inform themselves about the current situation in other teams and, above all, have the motivation to get involved and push things forward.

Phase 2: The decision

The path from developer to product owner is varied. If developers already have the above-mentioned qualities, they may already be thinking about a career change themselves. Often, however, the initiative comes from the employer, as the developers in question have handled conflict situations extremely well in the past.

However, the decision to become a product owner means a major break in your career path. The job that one has being doing up until now, namely developing, is not a part of the product owner role. In principle, however, it should be possible to switch back to software development. Anyone who feels like becoming a product owner should definitely give it a try; only then can there be clarity about the decision.

It is not only important to clarify the terms of the contract and the duration of the probationary period, but also the chance to get used to the new role. Here, for example, an assistant to the current product owner as well as various work-sharing models are possible.

Phase 3: The Start

Especially in the beginning, it can be difficult to find your way in the new role. The new tasks are different from the previous ones and it can also take some time for others - whether developers or stakeholders - to get used to the new product owner.

Instead of developing, the day is now determined by, for example, clarifying topics, writing user stories, refining these with the team and sprint planning. Nevertheless, it can happen, especially at the beginning, that product owners who come from development tend to take on smaller implementation tasks or bug analyses themselves. After all, the IDE (integrated development environment) is still within reach.

Above all, the development team expects technical solutions instead of goals formulated in what & why rather than how. Here it is important that new product owners behave in a role-compliant manner and do not slip into the situation of doing a little bit of everything.

Even if there is of course understanding from many sides in the initial phase, you are caught up relatively quickly in the day-to-day running of the project. It feels like everyone wants something and preferably immediately. Now that you are officially responsible, there will also be one or two attempts to delegate pressure further. The good thing is that many of these situations can be solved with and through communication.

If you are new to the role of product owner, you can make things easier for yourself by making your own feasibility options transparent. Pointing out conflicts through escalation meetings and questioning the desired implementation dates is also extremely helpful. It is also advisable to precisely identify the goal of implementation requirements. This often leads to alternative solutions that are more suitable than those requested. It is important to always abstract one's own technical knowledge, since discussion parties often have no background as developers. If you don't want to experience any surprises, you should take notes in all meetings, especially the results that were agreed upon.

Phase 4: The maturity phase

Once the period of getting used to the new role is over, the maturity phase begins. This phase is crucial for the development of a product owner and ultimately shapes them into what this role is all about.

Every project is structured differently and has its own characteristics in terms of the size/number of teams and the degree of agility. The organisational type of the teams (horizontal vs. vertical) also affects decisions and requires flexible approaches from the product owner. Smaller and larger adjustments to one's own way of working are inevitable in this phase. This is the only way to make progress in the role and to exercise it successfully.

Even though Scrum is an agile process, as a product owner you will be confronted again and again with processes that are more reminiscent of waterfall models. These often manifest themselves in additional quarterly planning to the sprint planning or in release planning (especially in the area of embedded development). One also encounters these in the form of calculations (e.g. effort + timeline) of larger implementation topics as well as the effort measured in person days instead of story points or the delivery of net capacities.

Overall, as a product owner, a lot of coordination work is required, and not only within your own team. Some topics require cross-team cooperation, such as adjustments to the way of working and the sequences or dependencies of the individual topics.

Working according to Scrum means working according to a certain principle. A valuable tool here is the determination of velocity. However, in order to maintain the Scrum process in an everyday project life, that is characterised by waterfall processes, a high degree of creativity is often required. The determination of conversion factors for the calculation of story points in person days, the splitting of velocity according to types of work for quarterly planning as well as the addition of implementation time for cross-team topics require unorthodox approaches now and then in order to integrate them successfully into Scrum.

Although there is little difference in development between product owners with and without a technical background in this phase, there are nevertheless small differences. It is more common for product owners with technical experience to focus more on those aspects of software development that go beyond pure feature development. Examples of this are: Test automation, logging, build/deployment processes, monitoring/alerting, technical refactorings and technical concepts.

Even if the empirical values here are only visible after some invested time, it can be rewarding to remain steadfast on these points. It valuable to be able to plan ahead more, something that also affects the accuracy of the estimates. Errors are not avoidable, but it saves time not to produce a bug in the first place or to be able to analyse its cause more quickly. Another aspect that should not be underestimated is the stability of the plan. Since the preventive measures are always part of the effort of each user story, the stories can be better estimated in terms of references. At the same time, there is less unexpected rework, which represents unplanned effort and disrupts ongoing sprints.

In principle, however, it can be assumed that product owners with development experience are just as well suited to supervising a non-technical product as product owners without a development background for a technical product.

Conclusion

In this exciting journey we have seen how developers become visionaries, better themselves and expand their own skills and perspectives. The path from pure coding to product vision and the associated tasks may be demanding, but it can be very rewarding for some. Product owners maximise the value of the product and thus support the achievement of the company's strategic goals.

The path from developer to product owner illustrates how versatile and changeable careers in agile software development can be. It shows that it is never too late to take new paths and develop further. Something that also applies to us as a company. In a world characterised by speed and agility, it is important to remain adaptable in order to develop future-proof software solutions for the world of tomorrow.