Scrum’s “Blank Page” & The Purpose of this Blog

What’s the problem?

In a Wall Street Journal article in 2011, Marc Andreessen famously wrote “software is eating the world”. Given its dominance these days, we might also say “agile is eating the software process world”. And while it is true there are many flavours of agile, as we peel layers from the onion it is becoming clear that “Scrum is eating the agile world”. Most organisations use agile approaches for projects and most of those use Scrum (or a variant of Scrum).

In 2013 the Scrum Alliance alerted us to an alarming statistic about adoption of the Product Owner role:

24% of our participants have a Product Owner role that is in alignment with Scrum best practices, with that individual having the authority to set business priorities for the project and directly interfacing with the customer. 38% have a Product Owner who juggles priorities for multiple stakeholders and is acting in more of a liaison role. 20% of their teams were co-located, while 24% were distributed across sites or geography (Click here to read the full report)

In other words, only a quarter of those using Scrum have a Product Owner aligned with Scrum methods. Surely only a subset of this quarter are also effective at the role. So we can infer that maybe 1 in 5 (or even as low as 1 in 10) Product Owners are both aligned and effective.

This is a colossal failure!

At least some of the cause is that Scrum itself only vaguely describes the Product Owner role.

Blank Page

The Scrum Guide essentially leaves the Product Owner role as a blank page.

The Scrum Guide 2017 describes a Product Owner as “…responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.” It goes on to say that “…the Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: … optimizing the value of the work the Development Team performs”.

Strategically and tactically, practically how does a Product Owner optimize the value of the work? The Scrum guide gives us no clue, so Product Owners are expected to figure it out for themselves.

Clearly many Product Owners are not figuring it out.

What can be done?

Traditionally the function that decides what to build has been someone with a job title like Product Manager, Product Marketer or Marketing Manager. The Scrum Product Owner role only really specifies (and vaguely, at that) the mechanics for communicating what to build to Development Teams.

It does not specify how to go about deciding what to build in the first place. In other words, the narrow Scrum Product Owner role is just one aspect of the function that decides what to build.

Practical advice and guidance on how to go about all the other aspects of the role is sorely needed.

The purpose of this blog is to elaborate on the business function of deciding what to build (as opposed to how to build it) by understanding the theory and more importantly, turning theory into practical advice.

Is this blog for me?

This blog talks to 2 audiences.

Techies are those who build software – developers, QA, architects, Scrum Masters, Product Owners, DevOps, Head of Engineering, COO.

The Business are those who decide what software to build – Marketing, Product Managers, Head of Product, CMO.

For the business:

  1. Does Product Management clearly articulate how development is connected to delivering value?
  2. Is there a clear understanding of each product’s roadmap and how it relates to commercial strategy?
  3. Are the voices of your customers heard loud and clear by development?
  4. Do your product releases always energise your customers and make them say “Wow!”?
  5. Do your organisation’s software projects always deliver what is perceived as optimal value?

For the techies:

  1. Does the business have a clearly defined and transparent process for adding new items to the Product Backlog? Is this process traceable back to the principles in The Agile Manifesto?
  2. Is development engaged and involved in Product Backlog refinement?
  3. Are requirements framed as a way to facilitate a dialogue between the business and development?
  4. Does your organisation clearly separate the what (the business’ role) from the how (development’s role)?
  5. Does the business continually explain how the development efforts – and changes in priorities over time – directly result in increased value?

If the answer is no to any of the above, you’ve come to the right place.


A couple more points.

This blog is not only about Scrum. As we work through the theory and practice of the role that decides what to build (whatever it happens to be called in your organisation), it will become clear that this role can (and must) be flexible enough to work with any development methodology.

Feedback is always welcome. We learn best by having conversations, so this blog is best viewed as a conversation starter. Whilst every effort will be made to research facts and apply rational argument, claims and assertions are my own opinions and are subject to change as better information comes to light. In summary, please feel free to correct me or hit me up with better information you might have.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.