You are on page 1of 3

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/334427989

Being a product owner

Article · October 2018

CITATIONS READS

0 15

1 author:

Craig Cockburn
Siliconglen Ltd
8 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Lean Kanban and Lean Portfolio Management View project

Agile coaching practices for strategic transformations View project

All content following this page was uploaded by Craig Cockburn on 12 July 2019.

The user has requested enhancement of the downloaded file.


Being a product owner
medium.com/@siliconglen/being-a-product-owner-54a618e266ec

July 12,
2019

Key aspects of being a product owner include knowing what belongs on your backlog
and when to say no and knowing what should belong on your backlog and how to
prioritise it — discovering the unknown unknowns. Techniques such as Weighted
Shortest Job first can help with prioritisation.

To form and evolve a backlog a product owner might spend around 2/3 of their time
outward facing to stakeholders to understand requirements and gather information to
help prioritise requirements.

In order to prioritise we need some prioritisation based framework including knowing


the Cost of Delay. If you put something top of the backlog, it’s helpful to know the cost of
pushing everything else down and having to wait.

To support decision making we prefer empirical data. Scrum is an empirical framework.


Empirical data is valuable evidence which supports decision making. However within the
Complex space which agile works best in (especially Complex Adaptive), then there is
often a lack of empirical data therefore experimentation is essential to turn hypothetical
data into empirical data and support decision making. In doing so, we mitigate the risks
associated with working in the complex space where outcomes are uncertain. To
facilitate decision making the product owner should know which data is empirical and
which is not, in order that hypotheses around empirical data can be validated and the
risks of uncertainty can be reduced. An experimental culture using a short effective
feedback loop is essential to drive out these risks. Fast feedback is more valuable than
fail fast as feedback is valuable whether it is good or chance to stop and reflect.

In order to fully take advantage of the wisdom of teams, we need to have a culture of
servant leadership. We do not influence culture directly. We influence the levers around
which culture grows and evolves. We do not tell a tree how to grow, we give it a nurturing
environment in which it is able to succeed. This is how culture works. In order to
evaluate what type of culture is present just now and if the teams are empowered then
Decision Making cards are useful. You can use these to decide what looks like servant
leadership and what looks like command and control then you can compare it to how
you work to evaluate where you are and then have a conversation around where you
want to be. Useful information here is “Pivotal Conversations”. The cards are a useful tool
to help you assess where your culture is just now. This can help to clarify whether you
have empowered teams and are you approaching agility which should be helping you to
meet the organisational goals that agility is seeking to achieve. We are not seeking to do
agile or be agile, we are using agile to help meet relevant organisational goals.

This is why an agile culture is essential to embedding the agile mindset. However, it is not
1/2
a mindset we need it is the mindset and associated behaviours together in support of
View publication stats

the relevant organisational goals.

I’m thinking of writing a book because so many people struggle with the above.
Comments welcome. See also Strategy Maps.

Further topics to research/ “Weighted shortest job first”, “Cost of Delay” , “Cynefin”, WSJF,

2/2

You might also like