As well as prioritising the backlog, setting acceptance criteria, attending Power-Of-3 sessions and signing-off work they are expected to visit customers, give sales reports and produce 5-year plans.
How do we reduce their work?
Introduce the Strategic Product Manager / Tactical Product Manager model.
The Strategic Product Owner / Tactical Product Owner model, or if you prefer: the Strategic Product Manager / Tactical Product Manager model, gets implemented again and again by companies not realising it.
They usually disguise it by calling the Strategic role a “Product Manager” and the Tactical role “Product Owner” or “BA” or something else.
Few of these companies realise that this is a reoccurring solution and is quite legitimate. Used correctly it can be very helpful.
However, it also opens the door to misunderstandings and conflict. The key is for the Strategic and Tactical to speak with one voice.
There are, at least, three reasons using this model:
- There is too much work for one person, and perhaps it is in different physical locations
- The roles require slightly different skills and experience
- The model allows companies to scale up and support multiple teams or multiple products
I thumbnail description would be:
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 Manager/Owner lacks time simply because – 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 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!
In my company Product Manager is responsible for features and product/customer fit (“outcomes”) -versus- Product owner is responsible for the backlog, i.e., the tactical execution of featues the Product Manager puts in the backlog.
Are we doing it wrong? ! .. and does that mean the Product Manager should wield OKR definition? (There is some linguistic slipperyness to PO/PM that I’m having trouble with !? )
Peter, I don’t think you are “doing it wrong”
Product Manager should be covering Customer Fit. While I don’t want you to build a feature factory it is natural that they will have a say in features - although I hope it is a discussion with the engineering team.
Where I woiuld make a change is that I’d put the Product Owner in that conversation too. Idon’t want them being merely a “Backlog administrator” for the things a Product Manager puts in the backlog. The Product Owner (in effect your Tactical Product Manager) should be working with the team in the details, but that doesn’t mean they don’t have a voice in deciding the features. That needs to be a broader conversation: Strategic (your Product Manager), Tactical (your Product Owner), engineering team and probably UXD and (if you have them) User Researchers.