In an industry like ours, change is a constant. New technologies, shifting customer needs, and constantly evolving work methods are the driving force behind this industry. And for some developers, there comes a time when they start thinking about where their career journey should take them next. One path that developers frequently choose is to transition into the role of Product Owner.
This career change is no small matter. After all, product owners play a key role in agile development teams, bearing 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, prioritizing features, and communicating with stakeholders.
In this blog post, our Xperts take a closer look at the journey from developer to product owner. We’ll explore the reasons, motivations, and challenges that come with this career change. This post is primarily aimed at developers, but it also offers fascinating insights for anyone interested in the various roles within agile software development.
Phase 1: Before the Decision
Developers, too, may encounter situations in their day-to-day project work that fall within a product owner’s scope of responsibilities. For example, it often happens that developers drive initiatives forward, facilitate meetings, or provide conceptual input to support business decisions. Added to this are ambiguously worded requirements and technical deadlocks that require a consensus-based solution. Despite its self-contained nature, the Scrum process also has vulnerabilities that confront development teams with the time-quality-cost trade-off. To address these challenges, skills that go beyond software development are often required. Communication plays a key role here.
Developers find themselves in these situations because they bring a specific skill set to the table. In addition to their technical skills, they’re interested in the big picture and usually have a better overview of the project than the team’s size would suggest. They also look beyond their immediate scope, stay informed about the current situation in other teams, and, above all, are motivated to get involved and drive things forward.
Phase 2: The Decision
The path from developer to product owner can take different forms. If developers already possess the qualities mentioned above, they may already be considering a career change on their own. Often, however, the initiative comes from the employer, since the developer has demonstrated an exceptional ability to handle conflict situations in the past.
However, the decision to become a product owner represents a major shift from your previous career path. The actual job you’ve been doing up to this point—namely, development—is completely eliminated in the product owner role. In principle, though, it should be possible to return to software development. Anyone interested in becoming a Product Owner should definitely give it a try—that’s the only way to gain clarity about the decision.
It is important not only to clarify the terms of the contract and the length of the probationary period, but also to explore ways to ease into the new role. Options here include, for example, serving as an assistant to the current Product Owner or utilizing various models for dividing up the work.
Phase 3: The Launch
Especially in the early stages, it can be difficult to find your footing in your new role. The new responsibilities differ from your previous ones, and it may take some time for others—whether developers or stakeholders—to get used to your new role.
Instead of focusing on development, the day is now spent, for example, on defining the scope, writing user stories, refining them with the team, and planning the sprint. Nevertheless, especially in the beginning, Product Owners who come from a development background may 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 rather than goals that are defined in terms of “what” and “why” rather than “how.” It’s important here that new product owners act in a way that’s consistent with their role and don’t slip into the trap of doing a little bit of everything. Even though there’s naturally a lot of understanding from all sides in the early stages, you’ll find yourself caught up in the day-to-day of the project relatively quickly. It feels like everyone wants something—and they want it right away. Since you’re now officially in charge, there will also be the occasional attempt to pass the pressure on to someone else. The good news is that many of these situations can be resolved through communication.
Those who are new to the role of Product Owner can make their job much easier by clearly communicating their own capacity limits. Identifying conflicts through escalation meetings and questioning the requested implementation deadlines are also extremely helpful. It’s also advisable to precisely determine the goal behind implementation requirements. This often leads to alternative solutions that are better suited than the ones originally requested. It’s important to always present your technical knowledge in abstract terms, since the people you’re talking to often don’t have a background in development. To avoid surprises, you should document all meetings in writing, especially the agreed-upon outcomes.
Phase 4: The Maturity Phase
Once the period of adjusting to the new role is over, the maturation phase begins. This phase is crucial to a Product Owner’s development and ultimately shapes them into what defines this role.
Every project is structured differently and has its own unique characteristics in terms of the size and number of teams, as well as its level of agility. The way teams are organized (horizontally vs. vertically) also influences decision-making and requires the Product Owner to adopt flexible approaches. Minor and major adjustments to one’s own work methods are unavoidable during this phase. This is the only way to progress in the role and perform it successfully.
Even though Scrum is an agile process, as a Product Owner you will repeatedly be confronted with processes that are more reminiscent of waterfall models. These often take the form of additional quarterly planning sessions in addition to sprint planning, or even release planning (especially in the embedded sector). You’ll also encounter them in the form of estimates (e.g., effort + timeline) for larger implementation projects, as well as effort measured in person-days rather than story points, or the allocation of net capacity. Overall, being a Product Owner requires a great deal of coordination—and not just within your own team. Some issues require cross-team collaboration, such as adjustments to working methods, as well as the sequence or dependencies of individual tasks. Working according to Scrum means working according to a specific principle. A valuable tool in this regard is determining velocity. However, maintaining the Scrum process in a day-to-day project environment dominated by waterfall processes often requires a high degree of creativity. Determining conversion factors for calculating story points in person-days, breaking down velocity by type of work for quarterly planning, and adding implementation time for cross-team topics occasionally require unorthodox approaches to successfully integrate them into Scrum.
Although the development process for product owners with and without a technical background differs very little at this stage, there are still some minor differences. For example, product owners with technical experience tend to focus more on those aspects of software development that go beyond mere feature development. Examples of this include: test automation, logging, build and deployment processes, monitoring and alerting, technical refactoring, and technical concepts.
Even though the benefits of this approach only become apparent after some time has been invested, it can be worthwhile to remain steadfast in these areas. Being able to plan further ahead is very valuable—something that also affects the accuracy of estimates. Errors are inevitable, but it saves time to prevent a bug from occurring in the first place or to be able to analyze its cause more quickly. Another aspect that should not be underestimated here is plan stability. Since preventive measures are always part of the effort involved in every user story, the stories can be estimated more accurately. At the same time, there is less unexpected rework, which represents unplanned effort and disrupts ongoing sprints.
In general, however, it can be assumed that product owners with development experience are just as well-suited to managing a non-technical product as product owners without a development background are to managing a technical one.
Conclusion
On this exciting journey, we’ve seen how developers become visionaries, rise to new heights, and expand their own skills and perspectives. The path from writing code to developing a product vision and the associated responsibilities may be challenging, but it can certainly be rewarding for some. Product owners maximize product value and thereby support the achievement of the company’s strategic goals.
The journey from developer to product owner illustrates just how versatile and adaptable careers in agile software development can be. It shows that it’s never too late to explore new paths and continue growing. This applies to us as a company as well. In a world characterized by speed and agility, it’s important to remain adaptable in order to develop sustainable software solutions for the world of tomorrow.
