THE PRODUCT OWNER AND THE "CEO" OF PRODUCT DEVELOPMENT



In my previous article I worked on the question if the Product Owner can be considered the CEO of the product. I received a lot of interesting feedback, often emphasizing the disciplinary power that a CEO has in contrast to the Product Owner, the direct responsibility for a company in legal terms, the position at the top with no lines of defense behind, etc.


While I was did not want ask for a more fancy title assigned to the Product Owner my primary intent was, and still is, to shed some light on the common grounds both positions share and how a similar, entrepreneurial mindset serves both them in achieving their missions.

And since the CEO "claim" resonated quite well with my audience in terms of article views I will stick with it for some more paragraphs and we'll talk about CEO not in terms of a hierarchical position or a title but in terms of key success factors that are mission critical to both, the Product Owner as well the CEO.


Customer Centricity


Ahhrg...not again. Buzz-words party? While this term truly can be (and honestly must be) found in almost any corporate value statement I have still seen this often be neglected in day to day behaviour of the people acting. Not rarely neglected because of personal egos being deeply addicted to the solutions they have designed, widely ignoring the deviating feedback from the customers. And lack of adoption of new services is feedback, too.


These egos are not only found in the Scrum teams, e.g. in the role of authoritarian Product Owners consistently pushing their own ideas on and, for too long, without truly sensing the customers reactions. Often, if not most of the times these egos can be found in senior product managers or executives pointing at their vast market experience and knowledge and claiming to "know what the customer wants", finally doing the prioritization work for the Scrum team from outside.


In case you might feel that I want to bash on senior silverbacks who have not managed the transition to the consumer-driven markets, then I need to adjust direction.

These non-responsive egos are human trap we all are prone to from time to time. Ryan Holiday´s "Ego is the enemy" was a revealing read on this for me.


I think that this is something that we need to remind ourselves sometimes: In German we say "Schönheit liegt im Auge des Betrachters", i.e. the single source of truth for beauty, usefulness or quality lies with those who look at it. 'It' being our product, here. In other words, quality is defined by the customer. And only by the customer. Thus, from my deepest conviction, the only path to a successful product, a sustainably successful product in particular, is the one which is consistently guided by customer feedback.


Empiricism


To make that customer feedback actionable, I think it is important to focus your senses. Imagine dozens, maybe hundreds or thousands of voices shouting at you. Unless they more or less all shout the same, like in a sports arena, you will hardly understand anything. When you focus, though, at a certain direction, that of the home team for example, chances are good that you will understand what those are crying for.


This similarly applies to product development. Unless you are phrasing clear questions, aka hypotheses, the customer behaviour you experience as a reaction to your increments will hardly give you any actionable answers. Hence, you won't get any direction where to persevere, where to pivot and where to trash specific features. Empiricism is key to avoid this trap.


The Scrum Guide is very explicit about that when stating that "Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials." For me, empiricism is a precondition for lean concepts to work as it lays the foundation to identify what is waste in the first place so that it can subsequently be avoided or at least minimized.


And in areas of high complexity, i.e. where the outcomes are not predictable,"with no right answers, only best attempts. There’s no straight line to a solution, and you can only know that you’ve found an effective strategy in retrospect." Thanks to David Bejamin and David Kolmos for this concisive quote in "How to tell if a problem is complex or merely complicated".


Agile, particularly Scrum, enfolds its competitive edge in the domain of complex problems. And the consistently empirical approach underlying the three Scrum pillars of transparency, inspection and adaptation helps the Product Owner fullfil his accountability for maximizing the value of the product resulting from the work of the Scrum team.

Or as W.E. Deming famously put it, “In God we trust, all others must bring data.”


Outcome Orientation


As we now know where to look (customer centricity) and how to look (following empiricism) the third step is the what to look for. And this is about outcome orientation.

While the immediate output generated by a development team are features what we are looking for is rather the effective change in the behaviours of our customers that these features are causing.


It's those actual behaviour changes that make the difference and have an impact on our businesses. A feature, unless it's really adopted (conversion), repeatedly used (retention) and recommended to others (referrals), is just like a buffet appetizer. Regardless how nicely looking, if it's not taken, tasted and enjoyed then sooner or later it will rather start to stink and deteriorate the remaining offer than attract any new client. In software products this can take form of technical debt, bad UX, complication of maintenance, etc.


When focusing on the desired outcomes from the beginning, searching them with the customers, sensing and responding to them in an empirical way will almost inevitably bring the product on track for success resulting in business impacts that each CEO is striving for.


49 views0 comments