What role does a Technical Product Owner play in agile teams,
and when do you need the TPO?

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.

Role Definition

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. 

TPO Functions

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.

Technical assistant and advisor

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:

• Assisting and advising the PO on critical technical decisions.
• Helping the POs to add and prioritize stories concerning technical debt or technical enablers for business features.
• Assisting with the product roadmap planning, ensuring complete visibility for both business and technical items.

Also, the TPO acts as a technical advisor to stakeholders such as business owners, product managers, scrum masters, and members of other teams:

• Supports teams on important technical decisions.
• Highlights and helps resolve cross-team dependencies.
• Helps with backlog prioritization and sprint planning.

Client Advisor

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:

• Thoroughly understand the client’s needs, mainly from a technical perspective.
• Explain technical stuff to the client’s stakeholders.
• Highlight dependencies and engineering complexity.
• Present/provide solutions to technical problems.
• Give realistic high-level estimates.

General (Advanced) Technical Ownership

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:

• collaborate with Solution Architects;
• develop a single technical backlog for all teams;
• create and manage architecture roadmap;
• guide architecture changes across multiple groups in a consistent way;
• schedule technical spikes or architectural changes ahead of dependent functional commitments in the product roadmap.

Difference between TPO and other roles

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.

Technical Product Owner vs. Product Owner (PO)

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.

Technical Product Owner vs. Solution Architect (SA)

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.

Technical Product Owner vs. Delivery Manager (DM)

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.

TPO’s day-to-day routine

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:

• Participation in discoveries/meetings with business stakeholders, POs. The TPO is a required attendee in these sessions to help to achieve the following main goals:
  • Make all stakeholders understand what’s doable and what isn’t.
  • Think about possible dependencies and technical features as enablers for business features.
• Backlog management. The TPO develops and prioritizes the technical backlog for all teams. It’s convenient to split the backlog into several categories:
  • The non-functional (technical) backlog contains technological enablers for business features.
  • The architecture backlog includes complex, long-term technical user stories and research stories related to architecture improvements and changes.
  • Refactoring backlog is used for activities connected to technical debt.
  • DevOps (Infrastructure) backlog holds stories linked to a product or team infrastructure (new or modified infrastructure, defining or improving deployment process, introducing new tools, helping the team to deliver software).
• Roadmap management. The TPO and the PO work together to develop an integrated functional product backlog with the technical backlog. They do it at the roadmap level and also at an individual team backlog level. 
• Collaboration with teams and stakeholders. The TPO is a proxy between many team members — POs, technical leads, architects, DevOps, and DM. The TPO is a person who can communicate technical vision strategy, taking into account the interests of all collaborators and whose recommendations are trusted by all sides.
• Support of release planning and management. As a person who holds and communicates a full technical vision of a project, The TPO participates in release planning meetings to highlight potential dependencies and help with prioritization. 

To sum up 

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:

• Delivering messages across different channels.
• Presenting ideas.
• Receiving feedback.
• Doing research or data analysis.
• Inspiring creativity in technical solutions.
• Effectively behaving in critical situations.

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.