The Product Owner Refactored: the SPO/TPO Model

Surprisingly, I've never blogged about the Strategic Product Owner/Tactical Product Owner model. This is surprising because it is a model I both find again and again, and advocate again and again.

I find lots of companies who have a version of this model in place, and they have created the model to deal with their own situation. But few of these companies realize that this is a reoccurring solution and is quite legitimate. (I should write it up as a Pattern but I haven't written any patterns for a while.)

More importantly, I find that many companies and individuals faced with problems around Product Owners benefit from adopting this model. Specifically, as I've already mentioned there is a lot of work for a Product Owner to do and one way of doing this is to share the load.

If I were to write this up as a pattern the thumbnail version would say something like:

The Product Owner lacks the time - and sometimes skill - to fill the role fully therefore split the role in two. One person, the SPO (Strategic Product Owner), looks long term, they focus on customers and strategy. The other, the TPO (Tactical Product Owner), focuses on the near term (this sprint, the next sprint, the next quarter). The TPO spends most of their time with the delivery team while the SPO spends most of their time with customers and senior stakeholders.

Sometimes the Product Owner lacks time. As I've said before, there is so much work the Product Owner should be doing they simply don't have time.

Sometimes they lack time because the team is large, or the team lack domain knowledge (and therefore need to ask the PO lots of questions). Sometimes POs need to travel a lot to meet customers and even the most talented PO can't be in two places at once.

They may also lack time because they have another job to do. While I think the Product Owner role is a full-time job, sometimes the person who is the right person to hold the role—usually because they command authority—needs to combine the work with another role.

For example, on a trading desk the Product Owner should probably be a senior trader who both knows the domain and has the authority to say Yes and No to features. But by definition, such a person lacks time. Normally I'd want a dedicated Product Owner in place but sometimes the only way to have the necessary authority is to have another job.

And sometimes the person who is should be Product Owner—think our trader again—lacks the skills and experience to do the role. So again they need help.

The key thing about the SPO/TPO model is that the two people who hold the role need to speak with one voice. If they do not then the model will fail. Ideally, the SPO will stand in when the TPO is unavailable and vice verse.

There is another occasion when the SPO/TPO model can be useful: big teams.

Ideally, there is one product owner, one team and one stream of work. But sometimes there are several products, teams, and streams. Here you might have an SPO who looks at the long-term and several TPOs each of whom works with one team on one stream.

Now, like all good patterns, this one is not without its downsides.

I've heard Scrum-advocates argue against this model: One True Product Owner they say. And they have a point: putting more people between the delivery team and the customer does detract from communication.

One of the problems software development faces is when multiple people think they have the right to say what is built next. Another problem occurs when the customer is remote from the development team and multiple people mediate what is asked for.

Ideally, developers can talk to customers directly, but that is often not possible or desirable—I won't go into the reasons right now. So a good solution is One True Product Owner.

But then the One True Product Owner becomes a bottleneck so we split the role SPO/TPO. Yet every time we introduce another link—another person—between the coders and the customer the greater the propensity to introduce problems. So it becomes a balancing act.

Nobody in between can be ideal.

One person can make it better.

Two people can be an improvement over one.

Three...I need some convincing this is an improvement over two.

Four...I find it hard to believe that having four people mediate the voice of the customer is an improvement...unless of course you previously had five!

Want to receive these posts by e-mail? - join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development