Arya Stark – Stick bad ideas with the pointy end

This is a PO take on Arya’s statement “Stick em’ with the pointy end” referring to her high prowess and knowledge on how to wield her sword ‘needle’.

The Product Owner rule here is to stop starting work if it doesn’t hit the mark from a analytics and validated learnings perspective. We’ve all seen the HIPPO (HIghest Paid Person’s Opinion) effect in action – work that we know shouldn’t go ahead that seems to be fast-tracked. The best Product Owners are ones that are unafraid to terminate work when it is a bad idea, knowing the risks that it may have to their job but holding steadfast regardless.

Ygritte – You  know nothing without validating your hypotheses

Whilst Jon Snow arguably knew nothing according to Ygritte, so too do teams and Product Owners if they blindly go building capabilities without validating problem-market and problem-solution fit assumptions.

Lean Startup gave us a huge shift in the mindset of software development when it began to re-wire our thinking to stop considering everything a requirement and to start to test and learn on our riskiest assumptions.

Great Product Owners not only test and learn on their riskiest assumptions around problem-market and problem-solution fit, but they are critically aware of the different types of cognitive bias and actively struggle against their better-self in order to ensure that the best possible solution goes to market.

Jon Snow – Benefits are coming

It might as well be winter with how much money is spent building work that doesn’t result in the expected benefits. Although most people have heard the of the 2002 Standish Chaos report that cites 64% of features are rarely or never used, this has yet to be considered statistically valid. Again the biggest challenge to how products deliver benefits has come from the Lean Startup community by focusing on a lifecycle that deeply embeds into its core a process of Build-Measure-Learn with critical decision points at the “Learn” stage to pivot (changing problem goals), persevere (continuing on same path, changing solution options) or perish (stop the work altogether).

There is still too much “throw it over the wall and it’s done” mentality in the industry. Leading organisations are deeply embedding this learning cycle into their development approaches and moving away from heavy batch to more flow based lifecycles. Whilst the Scaled Agile Framework (SAFe) is continuing to grow momentum, it is lost on many that implement it, that applied poorly, it creates massive three month batching.

Think about what this means from a test and learn perspective – you release something to market and begin to gather analytics and data. At the same time you start your next Program Increment meeting and create a firm commitment for the next three months of work. Let’s say that after three weeks you get enough data to validate what you just released and with great concern it just isn’t resulting in the outcome expected. You have an assumption about what you need to pivot, but it will require two weeks of work. What do you do?

You can wait to the next Program Increment, which is another two and a half months away, and then deliver a change in another three months (just over a five month pivot – yikes!). You could pull something out of the Program Increment, thus breaking the expectation that was set, further delaying the scoped benefits. If you were smart you would have built in some slack into the Program Increment to allow for pivots on released work.

In the field, I have rarely seen either of these decisions occur. Leaders don’t generally allow any slack in a Program Increment and instead tend to drive for the whole increment to be filled up, and then sadly what happens next is they push to have the teams deliver both, breaking their sustainability with a promise of “we won’t let this happen again”, which it inevitably always does.

Whilst you could argue that these leaders haven’t been coached effectively and are misunderstanding the core Agile manifesto value around adaptation for Agile (responding to change over following a plan), it doesn’t deminish the fact that SAFe as it tends to be implemented results in massive batching which in turn reduces the time to benefits and pivoting for benefits optimisation.

Great Product Owners know this and will be empowered to push back against the organisation’s leaders to ensure benefits optimisation. To do this, again the Product Owner will likely need great courage to fend their decision against leaders within the organisation.

Littlefinger – Backlogs aren’t a pit, backlogs are a ladder

For a while I considered using the Petyr Baelish quote “Fight every battle everywhere, always, in your mind. Everyone is your enemy, everyone is your friend. Every possible series of events is happening all at once” twisting it into a quote about stakeholders, customers and predictability of needs, but in the end I used the more known quote, “Chaos isn’t a pit. Chaos is a ladder. Many who try to climb it fail and never get to try again. The fall breaks them. And some, are given a chance to climb. They refuse, they cling to the realm, or the gods, or love. Illusions. Only the ladder is real. The climb is all there is.”

Backlogs are real. The climbing through them to deliver is (almost) all there is. Importantly a backlog shouldn’t be a pit. Product Owners tend to acknowledge all requests from stakeholders and politely put them into the backlog. These get prioritised down at the bottom of the backlog and languish for all of eternity. Great Product Owners will look at not just the important and prioritised work in the backlog as part of backlog refinement, but will also actively remove aged items within it, work that will never get done because it is deemed as too low in priority or value.

Product Owners will also appreciate where they are in the Explore-Expand-Extract stage of their product development and their backlog’s content will be reflective of the stage.

Tyrion – A Lannister always prioritises by value

Need I say more? The answer should be yes. A good Product Owner will prioritise by value, a great product owner will prioritise by value with an understanding of cost, alignment to strategy, market and competitive trends. Value can take many forms – customer value, business value, risk reduction or meeting industry obligations. Balancing value with cost of delay and job size will mean Product Owners can realise benefits sooner. A weighted shortest job first algorithm with relative estimation can be utilised to compare work in the backlog in order to ensure that the highest valuable work is prioritised higher.

Daenerys – I’m not just going to tell the story, I’m going to live the story

Daenerys Targaryen may be the breaker of chains with a goal to break the wheel, but as a Product Owner she epitomises the role of a story teller. Product Owners are passionate about the problem they are trying to solve. They want to get to the heart of it and do this best by engaging directly with customers and deeply knowing the data, insights and pain points about both customers and the business. Ideally the team would be attending the customer testing, but if they don’t then the Product Owner really has to be the voice for the customer, to put help the team to put themselves into the customer’s shoes and deeply understand their needs.

This is where Lean UX and Design Thinking intersect with Agile in order to build the right thing.

More Product Owners in Game of Thrones?

Do you have a good quote conversion from a Game of Thrones character to a Product Owner? If so post in the comments below.