The product owner (PO) plays a crucial role in an agile team. They are responsible for maximizing the product value delivered through the engineering effort. As a customer advocate, the PO defines and prioritizes the team backlog and clarifies product goals and roadmaps. But some things are not in the PO’s remit. For the deeper technical requirements of a product, the PO requires technical assistance to get things right. Generally, technical leaders support them in such cases. This works well in small-size development projects, but it gets complicated when your product grows fast and the number of agile teams increases. Teams face many issues: more new and complex features, more dependencies, increasing technical debt, essential architecture changes, increasing deployment frequency, etc. Someone has to take ownership of the technical side of product development. For that reason, another vital role emerges called Technical Product Owner.
Let’s dig deeper into the details of the role and define why they are essential for product development and the teams’ success.
A Technical Product Owner (TPO) is an expert who uses their technical background to close the gap between the technical and business side of software product development. They have a comprehensive understanding of both the business and the product which allows them to guide technological and architecture changes while aligning with the overall product development roadmap and communicating it across agile teams.
You will not find a detailed role description in scrum or SAFe guides because it’s a need-based role with no predefined job description. Usually, the TPO responsibilities are modified when the role is introduced in a specific project and depends on the project’s needs. Below are some definitions of core TPO functions.
The PO should have a high-level understanding of the technical side of a project but not a deep knowledge of all the technical and architectural concepts. So, the TPO is a strong partner for the PO in the technical side of product development.
Essential tasks as a technical assistant include:
Also, the TPO acts as a technical advisor to stakeholders such as business owners, product managers, scrum masters, and members of other teams:
Most clients are not techies; they simply want to have things done. The TPO makes the client aware of what the product can and cannot do from a technical perspective and communicates technical solutions and dependencies in an understandable form. To sum up the above, the TPO serves as the bridge between the client and the agile team in cooperation with the POs. Some activities that may be in their role:
Complex technical products (a large-scale technical product or a product with a significant number of pending architectural changes) requires more engagement from the TPO. Depending on the complexity of the project, aspects of the role may include:
Generally, any team member with sufficient technical background can play the TPO role, but it may seem that the TPO role overlaps with other functions. Let’s find out what separates TPO from other roles.
TPO handles the technical elements of product development; POs are primarily responsible for defining a product’s vision and managing the business backlog. POs are not required to have extensive technical skills to do their job. But they have to know the product and dependencies very well from a business perspective & high-level technical perspective.
SA is responsible for creating technical solutions/vision. It could be a part-time role. Meanwhile, TPO mainly focuses on delivery and has good knowledge of the product and technical capabilities. The TPO is responsible for defining and communicating a shared technical and architectural vision. SA can play the TPO role.
The DM is responsible for ensuring that the teams have everything they need to deliver in all aspects: e.g., design, engineering, testing, infrastructure, and production support. The TPO’s role is entirely technical and focused only on engineering and infrastructure. DMs can play the TPO role in small teams with enough technical skills.
When the TPO role is introduced, it’s recommended to define areas of responsibility between the roles described above to avoid role overlap and resource overloading.
Now let’s get back to more natural life. What kind of activities does the working day of a TPO include? Here are the key activities:
As we see, the TPO role doesn’t have a description that is set-in-stone — it depends on a project’s needs, scale, complexity, or phase of product development. It allows you to adapt responsibilities from project to project or modify them after some time. Typically, it makes sense to make technical leads, architects, or delivery managers into Technical Product Owners when such a need arises. Also, It’s all-important that the agile teams themselves are involved in this process as much as possible. If technical leads take over TPO’s duties, it looks like a “distributed” TPO function in a scaled agile setup. All the technical leads must be aligned and behave as a team in such a setup. If there is some dispute, the final decision should be made collectively. Usually, consistency can be achieved via regular synchronization meetings and release planning meetings/activities. Afterward, leaders must regularly share high-level strategies and goals with their teams.
Also, it’s noteworthy that besides an excellent technical background, this role requires solid communication skills and extensive analytical thinking:
Introducing the TPO role — it’s a viable solution to define a balanced product backlog that aligns with the business needs, architecture, design, and then delivery towards business goals.
And this is a role that is worth engineers’ attention if they are looking for new challenges.