Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

Who is the Product Owner for the System Team? - Part 2

31-Mar-2020 07:24:00 SAFe SAFe 5.0
Find me on:


In part 1 of the blog, we discussed what the System Team is, what a PO for the System Team does and the essential skills for this role in relation to the System Team. Now we turn our attention, where you might find the Product Owner for the System Team, and no matter where you find them, that there will be some personal development needed to maximise their potential. 


Where might a systems team PO come from?

Being they are a PO like any other, when identifying candidates this role, you may find your existing product management function doesn’t have the technical product domain skills to effectively work within the team. This can naturally lead people to look within the technical domain, but this means they won’t likely have the PO skills needed.


There are four patterns that we have seen, each has its own pros and cons, and you will need to make your own trade off decision in your context. For each you will find an outline of the considerations you need to make.

  1. From existing Product Management function
  2. Team Leader or Senior Team Member
  3. Business Analyst or Architect
  4. Source within the team


From existing Product Management function

Taking them from the product management function means they will know the role, but potentially struggle with the ‘product’. Here you can have a captain who knows where to go, but doesn’t know how to get there. They will have to rely heavily on the team to create stories and find solutions. This will have an impact on their capacity to deliver while supporting the new PO. You may also find that your existing PO community does not have a personal interest in this domain and don’t see it as a product they want to work with.


On the flip side, the existing relationships they have with other POs can support the adoption of new capabilities and provide a fast feedback loop of what the other teams are doing. Exploiting these relationships can give positive results and improved alignment.


This choice can be one of the hardest to implement, as the learning curve can be high if the PO doesn’t have the technical skills necessary.


Development opportunities include:


Team Leader or Senior Team Member

Some teams have sourced the PO from their team leader or senior team member roles, which means they have the technical skills, but they will be lacking in the PO skills. Also being the ex lead or senior dev (or worst wearing two hats), means the job of the Scrum Master in the team can be challenged. Team members might find confusion over if they should take their lead from the ex leader owing to their previous role and stature in the team, or the Scrum Master who is coaching them to improve.


Development opportunities include:


Business Analyst or Architect

You might find a Business Analyst (BA) or Architect (potentially System or Solution) who already have some of the technical skills, and is often the case for BAs, has some PO type skills too and therefore has to work at being a PO and improve their technical skills. 


This pattern of using the System Architect is one Em Campbell-Pretty and Adrienne L Wilson echo in their book, The Art of Avoiding a Train Wreck. They outline that, “this should help keep the System Architect grounded in the reality of the health of the system that Agile teams are working in.” 


Potentially, you could stretch this pattern and look wider in the enterprise to someone from within release or service management. They could help bridge the needs of the delivery teams with those processes and organisational structures needed to release to production.


Development opportunities include:

Source within the team

One possibility is to look within the team, is there a natural person to take on this role? Someone might want to pick up this role; the same applies to the Scrum Master role.  If there isn’t a taker for this, look wider than the team and see if there is a stakeholder that we can look to to do this role. 


Development opportunities include:


Across the board, for anyone who takes on this role they may with to consider:


Read the next instalment here.


Thank you to my reviewers, Andrew Sales, Darren Wilmshurst, Virpi Rowe, Sukie Kang, Kay Overend, Mark Richards and Neru Obhrai.


Glenn Smith

Glenn Smith

Glenn is a techy at heart, but these days doesn’t get a chance to get his hands dirty in the code anymore. As a coach and trainer, he helps organisations get better at product delivery and enterprise agility. He loves seeing people ‘get it’ and then going on to build great products, be that IT or non-IT alike. With near 20 years of experience, from the coal face of writing embedded software, to running a multi-disciplined team over two continents and having now supported many organisations, he has a wide range of skills and experiences. And in a past life he was a local politician, so can tell you lots of things about street lights and waste collection too! Read more