Students of politics will recognise the phrase “It’s the economy, stupid” as the pivotal tag line from the Clinton 1992 presidential campaign.  Although the origins of the phrase have been lost in the myths of political history  it was seen as a game changing event that re-energised Clinton’s communications strategy for the rest of the campaign. They could have talked about healthcare, defence, the deficit or any number of subjects but the economy was identified as the primary concern for voters. Since then the meta structure of the phrase “It’s the XXX, stupid” has evolved into a by-line for how focus can be derived from a multi-faceted problem assessment.

When it comes to building an agile team for a new project,  it’s important to get the right people into all of the roles associated with the agile process. Yet when you consider where the greatest business process risk falls if the right person is not appointed then, “It’s the product owner, stupid”.  Why?

With waterfall and other staged process models the business problem is decomposed into a logical process and it passes through various layers of examination by multiple experts to evolve a solution.  In contrast most of that layered process model – what I like to refer to as ‘problem contemplation’  – is ditched and the ball is handed to a ‘product owner’ who sets the path forward. That puts a huge burden on the ‘product owner’ to get it right, as they are being asked to perform everything from strategising the solution, identifying requirements and affirming the business value of outputs.  As one commentator described, get this aspect of the agile process wrong and the agile team is reduced to being a headless story munching machine that simply addresses whatever is top of the pile. Yep – “It’s the product owner, stupid”.   

The criticisms of waterfall/staged problem examination methodologies are well known, and I like to summarise those limitations as “too slow, too elaborate, too rigid”.   Yet there are plenty of situations where waterfall is a better choice than agile.   From my own experience there are two practical problems with using the waterfall approach , but funnily enough echoes of the same  problems do appear in the agile world.

  • Authoring skills –  the waterfall approach normally involves a lot of document writing, and the simple truth is that most people just aren’t very good at this.   Similar problems exist in the agile world – capturing the right stories in the right mix is something of an art form.
  • Interpretation/relevance – having multiple layers of examination introduces multiple personalities and this creates huge problems of interpretation.   Typically each waterfall process document will have its ‘moment-in-the-sun‘ but after that they are rarely curated as a living project asset.  It’s like the old habit of spending a huge amount effort building a project Gantt chart,  only for it to be confined to a metaphorical top drawer and never looked at again.   In the agile world the equivalent problem is with curating the backlog, as this activity rarely gets the level of attention it demands.

Whilst waterfall methods have their place, I believe that there are two primary economic factors that make agile the right choice for most software projects:

  • Firstly, with modern software tooling you can build the outputs faster than you can write about them.  Whether its mobile app design or building an API platform there are plenty of interactive tooling options available that offer collaborative routes for shaping outcomes.  Who in 2016 is going to write a requirements doc for a UI?  That doesn’t mean that no docs are required, but the focus is now on context setting and constraints.   This puts a huge burden on the product owner to set that context and to have the skills to use these modern software tools.
  • Secondly, stakeholder supervision/governance.  Software teams are expensive and the ‘opportunity window’ for a business initiative is getting shorter with each passing year.  Businesses can no longer afford the long gestation periods associated with waterfall methods, but agile has a much looser set of boundaries and so the ‘build-show-validate’  agile approach is key to keeping all parties on track, and delivering affirmation of progress.  This puts the product owner ‘front and centre’ with the business stakeholders to explain what that value represents, what compromises might have been made to get to this point, and the route forward.  Given that a single user story is rarely the catalyst for pivotal change, this means that the true business value is normally only manifested at an ‘epic’ or ‘feature’ level. Those larger work items take multiple sprints to deliver, and the challenge for the product owner is controlling stakeholder expectations against time. That takes a lot of energy.


With all of this in mind I believe there are five key characteristics required for a person to be a successful product owner:

  1. Hybrid skill set.  In the first instance the product owner is acting as the customer proxy, but to have a chance of fulfilling that role the product owner needs expertise in multiple areas.  Firstly, they need the domain knowledge to understand the problem, and an ability to empathise with what the proposed business value represents. Secondly, they need an innovative mindset that can translate the change agenda/ambition underlying the project into a practical concrete set of actions. Thirdly, they do need some awareness of the implementation tech and the possibilities that this opens up.   Without this the risk is as Henry Ford stated, “if I asked my customers, all they wanted was a faster horse”.
  2. Strategic awareness. The product owner has to own the strategy for the initiative and  manage how external threats/changes impact the mission.  After all inferring a strategy from a user story backlog – a gloried ‘to-do’ list – is practically impossible.  The product owner has to fill that gap and act as the ‘north star’ for all parties involved. This means being able to explain ‘why’ and what factors make for success.
  3. Capable of making decisions – the right ones!   By their very nature agile projects work off an imperfect information model.  Late breaking insights or requirements changes are a fact of life,  and so the product owner needs to be an individual who is capable of making important decisions.  For this to work the parent organisation needs to provide the product owner with the authority to make decisions,  because on occasion this is going to involve saying ‘no’ to a stakeholder who wants their pet feature to get more attention.
  4. Strong collaboration skills.  If you’re not a people person, don’t become a product owner.  Agile methods and agile timelines require a high degree of collaboration,  where the product owner often acts in a facilitation role to synthesise technical, business and quality factors into a practical outcome.
  5.  Entrepreneurial spirit. A great product owner is basically an entrepreneur for the product. They will have a keen eye for opportunities, a focus on business value/ROI, and act proactively on possible threats/risks.  However, all this energy has to be focused on the task of getting business value into client hands at the earliest opportunity. In this sense a product owner has to work with that old entrepreneurial maxim of “making dinner from what’s in the fridge“.

From another perspective a product owner can only be successful if the parent organisation provides them with the time and space to fulfil what is a demanding role. Various studies show that on average a product owner will consume around 40% of their time on basic product owner duties for a single project. From a project portfolio management viewpoint the availability of a pool of good product owners is going to be a constraining factor on planning options.

In summary. as organisations mature with their adoption of agile methods the presence of a strong cadre of product owners is going to be seen as a pre-requisite for agile business value delivery.  It is already a key factor in separating the winners from the losers.