This guest article is brought to you by Daniel Merriman, Product Owner at Raspberry Pi Foundation and former Project Manager at Isotoma. Tweet Dan @MisterDanielM or connect with him on LinkedIn.
In my day job, I do not call myself a Product Owner.
My title is Project Manager, and I think this is an accurate representation of what I do. I ‘manage projects’, in the sense that I do my best to ensure that projects are organised, run smoothly, and achieve outcomes that leave my clients feeling satisfied.
In a previous life, I have worked as a Product Owner. I worked for a large organisation that used their own version of Agile methodology across the board to deliver both new products and ongoing Business-As-Usual work. I was not a Project Manager there: I was a Product Owner. At least, that was my title. Whether I was actually a Product Owner, in the strict Scrum sense, I’m not so sure.
As the name suggests, a Product Owner is someone who owns a product, which is to say the “Vision”, as well as the Strategic goals and Tactical development of a product. This is part of the definition given to me by Roman Pichler, one of the foremost experts on Product Ownership and host of a two day workshop that left me with both an enormous sense of enthusiasm for the potential of the role and the nagging feeling that, despite what my memory and CV tell me, I haven’t actually been a Product Owner at all.
But first, let me discuss some elements of the course itself. I have to admit to a certain degree of scepticism towards such things, if only for the sheer number of offerings out there. With no rankings of the courses available, or accountability for many of the large organisations that deliver them, how do we ensure that the course we take is actually useful? Experience of such workshops, not just in business but in my previous life as an academic, suggest that there are two main factors that determine its usefulness.
First, does the instructor know what they are talking about? Do they have experience of the role in the ‘real world’, under fire, where life, politics, and Murphy’s Law conspire to ruin perfectly curated Agile processes? Do they rely on a textbook for delivering the course content, or do they have the expertise to share their knowledge in a way that adapts itself to their audience’s needs? Can they respond to their battle-hardened, sometimes cynical participants in a manner that acknowledges their own competencies while getting them to buy into the content as both realistic and valuable?
Second, who are the participants? Are they willing to get involved, to share their own experiences openly and honestly? How broad is their range of experiences? Are they all new to the role, in which case their inexperience may limit useful conversation, or are they all experienced to the point of weariness, in which case it may be difficult to persuade them of the value of active participation? Are there even enough attendees to have a meaningful discussion?
All these thoughts ran through my head while, bleary-eyed and half asleep, I sat on the early train to London. In the end, however, I need not have worried. Roman has worked in management and product roles for over 17 years, and has more than enough anecdotes and examples of real world application of the principles he espouses (both successes and failures) to demonstrate his bona fides. He cuts an imposing figure, part Steve Jobs, part “Gangs of New York” Daniel Day-Lewis, and delivers his material with confidence and mastery. I was particularly impressed with his method of starting with blank slides, then building them up with drawings and annotations as the exercises and discussions progressed. It seemed an excellent way to react to the queries of the attendees while maintaining a strong sense of narrative and interaction throughout the sessions, something that a set of pre-made slides or a handouts struggles to achieve. The approach reminded me greatly of similar techniques used in some YouTube videos (such as these), and I found it an excellent way of keeping an audience engaged*.
As for my fellow participants, an initial exercise revealed that we had a good mix of current, former, and new Product People in our midst. There were about 30 attendees in total, and remarkably some had even travelled from as far away as Germany and Slovakia to take part (and there was me thinking Yorkshire was far enough). Some, like me, came from small agencies, but many were based in start ups or large enterprises in industries ranging from fintech to engineering to travel and beyond. Most importantly, they were all happy and willing to share their experiences and ask insightful questions of our instructor and of each other.
Naturally, this being a course about Scrum roles, we began the course by building a backlog of questions we had about product ownership and goals we had for the two days. For myself, I really had two questions that I hoped the course would address. Firstly, and most applicable for my current situation, how do you leverage the value of product ownership in an agency that doesn’t have distinct Product Owner and Scrum Master roles? My second question was more personal, and takes me back to my thoughts at the beginning of this blog: that is, once a business reaches a certain size, or the scope of a product reaches a certain complexity, is it possible for a Product Owner to operate effectively in the Scrum sense of the role, rather than transitioning into “something else”?
Regarding Product Owners in agencies such as ours, Roman proposed two models, where either the client takes that role or the Project Manager (or someone similar in the agency) acts as a kind of ‘proxy’ Product Owner, switching hats as necessary for the duration of a project. While examining these possibilities, I thought about how we do things at Isotoma. With some clients, having someone on the customer side act as a Product Owner makes a tremendous amount of practical sense. They are a subject expert with a strong vision for the product that we’re developing, they are able to obtain buy-in from their business to support that kind of close working relationship, and they have a visibility of their internal business roadmap that allows them to prioritise work that returns the most immediate value. With other clients, however, that kind of relationship is a lot more challenging. Their schedule doesn’t allow them to devote the time necessary to a single product, their organisation doesn’t allow for them to ‘own’ the product themselves, or sometimes a lack of domain expertise means they rely a lot more on our input when considering what direction a product could take.
In practical terms, then, I realised that we actually practice both of these approaches. It’s not that one is intrinsically ‘better’ than the other, but rather each approach is more or less suitable depending on who our client is and what it is we’re building. Ideally this is something we can identify early on – much like my previous blog about asking questions (link), we use the Discovery phase of a project to determine the kind of role that our client is going to play in the delivery of the product. Are they able (and willing) to play this role effectively, or do we need to be more involved on a strategic level? This can change as the project develops, too, with some clients being heavily involved in the early stages and less involved once the product has started to take shape. Sometimes, when we’re acting more as direct partners, they will leave the early decision making to us and take more ownership of the product once its direction becomes more certain.
The importance for me, then, lies not in where the Product Owner role ‘sits’ during a project, but that everyone knows how decisions are made and buys into that process.
This brings me to my second question.
One of the main challenges that face Product Owners, in my view, lies in ensuring that they are understood to be Product Owners, rather than simply Project Managers working in an Agile environment. This is to say, their job is to own the vision of the product as well as its strategic and tactical direction. What their job should not be, in a true Scrum environment, is managing the development team on a day-to-day basis, or existing purely to triage requirements from other parts of the business without the authority to push back. Based on discussions with my fellow Product People over the two days, however, I think it’s fair to say that these experiences are fairly typical. Not one of the people I spoke to said “Oh, I wish I had less say in the direction that my product is taking”, or “I wish I had to spend more time dealing with issues arising during sprints”. Rather there was a real sense that Product Owners in large organisations are encumbered with an administrative burden that is anathema to the value that the role can bring. They become mini Project Managers, or funnels for business requirements from other stakeholders.
There is a standard model of how Scrum roles scale in large organisations. During one of the sessions Roman drew a distinction between ‘big’ Product Owners, who own the larger Vision and Strategy of the product, and ‘small’ Product Owners, who, typically through organisational design, have little influence beyond the Tactical level. This can work well, if everyone involved understands this role and works together as a kind of ‘Product Ownership Team’, but the broader challenge as the product and organisation grows is the dilution of a single point of ownership and subsequent weakening of both vision and consistency. If the product is simply too big by this stage, the question then becomes “Do we break down the ownership of this product into discreet ‘features’ or ‘components’, and if so what is a sane and sensible way of doing that while maintaining a coherent overall vision?”
It’s a hard problem to solve and I think, for my own part, it’s a problem that is addressed less by finding the ‘perfect’ configuration of roles and responsibilities in your organisational structure and more by individuals deciding for themselves whether they are truly satisfied with role that they are being asked to play. As Roman discussed in the course, when faced with a difficulty like this, you can either change what you’re doing or change how you feel about what you’re doing. I like this idea a lot, and would go further and rephrase it:
If you cannot take ownership of the product, take ownership of your relationship with the product.
And so I returned to York after two days, an officially certified Product Owner to go alongside the Scrum Master certification I achieved in 2016, and pondered the emphasis we put on methodology and roles and process management. Certainly we need all those things to maintain some semblance of order, to strive for value in the work that we do, to make sure that the things that need to get done are done by the right person in the right place at the right time. But still I wonder how many square pegs are out there, forcing themselves into round holes not because that is where they’re happiest, but because they’ve resigned themselves to never finding the square hole that would show them at their best.
* Note to self: steal this approach
This article was first posted on the Isotoma Blog. It is republished with the permission of the author.