I owe a special thanks to my colleague Jason Novack for pairing with me recently on a presentation to the Boston International Institute of Business Analysts (IIBA) about making the leap from business analyst to a product owner. It was a great experience that really got me thinking about some of the journeys I’ve seen analysts go through as they moved into Agile teams and began playing the role of Product Owner. This blog encapsulates some of the concepts we came up with in that discussion and the archetypes I’ve seen for behaviors that these people go through, specifically analysts from large organizations that find themselves dropped into the role of product owner.
Archetypes of Product Owners
I don’t mean to imply that every product owner I’ve worked with could fall into one of a series of buckets, nor that alignment with a single archetype would imply someone can not behave according to another. In fact, as I look at the people I have had the privilege to coach and work with, I see the archetypes representing a couple progressions individuals move through towards becoming truly effective agile product owners. These categories capture the essence of different roles I have seen people play. Some are good, some are bad, and some are somewhere in between. The most hopeful thing is that I have seen people successfully progress from one to another and to another as they learned and grew in their role. Thus, these don’t imply a fixed classification, but rather a step in a journey.
This is a place where many people find themselves – including yours truly – at some point early in their career as analysts. Whether they are an analyst or a product owner, they are simply expected to ask the customer what they want, and to write it down. Unfortunately, my experience was that my customers were notorious for asking for a solution they thought would solve their problems without actually articulating what they were really trying to do. Indeed, my own journey beyond this archetype really began when I was able to eliminate a six month development project by talking through with our business partner in response to a request they submitted for some new functionality. Low and behold, we were able to offer that capability to them with the current system by using a few tricks!
As a product owner, the stenographer finds themselves – by choice or organizational imposition – in a role where they are unable to influence and not expected to add much expertise or knowledge to the problem domain. Product owners in this role may feel more like order takers from higher up executives who are looking to use them as interlocutors to relay requirements to the development team. Unfortunately, this is a self-defeating position for a product owner. They are unable to articulate a clear direction for the team to execute against, because they must continually go back to get questions answered.
Ultimately, product owners must outgrow this limited model and become masters of their own destiny if they are to help guide their teams in a coherent direction. In fact, many organizations embarking on an Agile transformation are open enough to change that this provide an opportunity for an un-empowered analyst to grab the opportunity and find a voice nobody knew they had. They begin to show leadership and vision, at least enough for the team they work with to execute effectively.
Offering confident message and vision forward, we see product owners in the decider archetype offering a clarion call to their team about what must be done, what order and to what end. The key benefit they offer the team is decisiveness and a vision to execute against. No longer must the team troll through enormous document to glean a possible answer to a question. No more must they wait weeks to float questions in order to get simple answers. The decider short circuits these anti-patterns and provides consistent and timely information to the team so that it can continue to do what it does best: deliver software.
This is not to say that the decider has no product expertise, as some are quite experienced in their domains, but rather that their primary locus of control is in the stated role of product owner being the “single wring-able neck” who owns the product backlog for a team. They cut through the ambiguity and uncertainty so that the team doesn’t have to. At their best, they are able to set both “big hairy goals” for the project and tactical goals for the team. One precocious product owner I worked with really took to this concept. I recall working through a story map with her when we were identifying their first release. Working with some key people on her team, they decided that the priority for the first release was to confront product and technical risk. Once she clarified that goal, she quickly move through the backlog and de-prioritized anything not meeting that criteria. I recall her looking at each piece of work and simply stating things like, “well that doesn’t move us any closer to our goal, so let’s put it off until later”.
She provided a consistency that allowed the team to focus on a goal and not get bogged down in changing scope or a morass of requirements for the project that were not terribly important but threatened to distract the team.
Unfortunately, this archetype is not without it’s downside, and I would describe this as a transitionary place for product owners. While they cut through ambiguity and provide clarity of purpose, this is not always informed by deep product knowledge. Product owners working in this model run the risk of sending their teams off a cliff. Fortunately, the nature of Agile projects is designed to accommodate this, by allowing for false starts and early failure. The impact of a lost two week iteration is usually not profound for a large project that is being properly managed. This is also the opportunity facing these product owners, namely to learn more about the domain. The iterative nature of Agile projects provides ample opportunity for individuals to test a hypothesis, experiment, and learn. This opportunity is not lost on good product owners, and we frequently see them become veritable authorities within their product domains moving them into the next archetype, the genius.
Product owners in this archetype are generally coming from one of two paths. Either they have been playing the role of product owner for some time and have used that opportunity to accumulate experience, or they are credible subject matter experts within their domain already and have now been put into the role of product owner to lead an Agile team. These individuals frequently retain the confidence and decisiveness of the decider archetype, but they can back up that clarity of purpose with a significant amount of expertise. A general difference I see between geniuses and deciders is that deciders are generally more focused on the tactical decisions. They lay out the next release or prioritize the next set of features. Geniuses will focus more energy and time articulating the big picture and crafting a bold and ambitious vision for the product overall.
This depth of personal knowledge about a product domain can be incredibly valuable to a team. It allows the product owner to better educate the team about the nature of the domain, answer difficult questions, and in general set context very well. This in turn allows the team to be more responsive and creative in their own solutions. Unfortunately, this expertise comes with a couple of risks. While a product owner with this level of expertise can be quite effective, if they do not share their understanding and help to explain their vision clearly to those around them, their expertise can effectively be wasted. Indeed, it may be quite a difficult situation for a product owner in this position, as the “curse of expertise” can even undermine their ability to communicate effectively. A critical success factor for product owners in this model is to be able to clearly articulate complex ideas. Even if they do share their expertise, they are still prone to the risks that face any expert in that their own past experiences may actually become liabilities. As the economist Kenneth Boulding once famously said, “Nothing Fails Like Success.”
Namely, patterns and approaches that have served us well in the past will invariably be used again in the future, until they fail. If an expert has used a limited set of techniques or perspectives to great success, they may be unable to let them go and move on to new ideas and concepts. Similarly, the genius archetype must avoid leaning on their own expertise too much and not exploiting the empirical feedback loop available to them inherent in any iterative and incremental project.
The other major trap that I have seen product owners in this role fall into is what Fred Brooks dubbed the “second system effect“, where they have the opportunity to build a newer version of a system they are already familiar with and become seduced by progressively more and more advanced capabilities until they have conceived of a system that is unnecessarily complex and expensive. This risk can even be amplified within an Agile project, as there are less constraints upon the scope that a product owner can request. The best way I have seen to guard against this type of dynamic is by laser like focus on tactical goals when prioritizing work for each iteration. Ironically, these are the skills that the decider archetype most embodies. Thus, some people may begin their journey as a budding product owner who is able to cut through the fog of complexity, but then later succumb to it as they learn more and more about the very system or product they are guiding.
Ultimately, the genius archetype faces the challenge of growing by increasing feedback channels available to them. The specifics for these sources are numerous and vary based on the context of the project. It may be reaching out to less vocal stakeholders, like support or operations, in order to broaden perspectives available to the team. It could be building stronger relationships with product development and finance in order to keep things like scope and budget within agreed upon constraints. It may also take the form of continuing to exploit iterative work in order to get empirical feedback and conduct testing and validation of concepts with the project team. Regardless of the details, experts need to ensure that they never allow their perspective become hermetically sealed within the world of their own personal experience. Having learned a significant amount about their problem domain, their journey is to continue deepening that knowledge as well as expanding the horizons into adjacent areas.
The first two archetypes discussed rest upon one major assertion: that the product owner truly has the authority to articulate and prioritize work. If you read the Scrum Guide or just about any text book on Agile Software development, you will see that this is a requirement for an effective product owner. Unfortunately, I have seen too many projects where this is simply not the reality. In some cases, organizational policy, where the development team and their customer proxy are simply not empowered to make product decisions. More than anything else, this explains how people find themselves within the role of stenographer.
We explored the concept of product owners being given the authority to make decisions, as well as in some cases them simply grabbing it. But there is another path forward where product owners exert influence over their product with limited authority. This is the archetype I call the diplomat, where savvy product owners without formal authority are able to clearly and strategically work in environments to establish clarity of purpose and get questions answered so that the team can work effectively.
While the diplomat’s ownership of the product backlog may be limited, when played effectively, they can confront problems by bringing the various stakeholders together and getting them to work through their own differences. In fact, establishing a consistent vision across numerous project stakeholders is probably one of the most effective things that a product owner can do in many organizations. I have seen numerous companies where their software development process has become so fragmented and slow that no clear vision or priority exists between the business and technology partners; in some cases a consistent vision doesn’t even exist within the technical or business silos! In these situations, a thoughtful product owner can deliver immense value to their organization by bringing the different stakeholders to a table and helping them see how their inability to resolve differing priorities undermines the success of the very projects that they all depend upon.
At their best, diplomats are able to use organizational jujitsu so that people with various conflicting priorities are able to come fact to face with each other, discuss their interests, and make a decision in the best interest of the project, program and company. This is obviously much easier said than done, and I could probably write a series of blog posts discussing different techniques available to product owners in this archetype. I have seen product owners use very simple techniques to great effect, like insisting that all stakeholders agree on what to work on next, anything the group can’t agree on, doesn’t get done. This can provide powerful motivation for people to interact and work together.
While the diplomat can be quite effective and valuable in organizations where there are numerous stakeholders who wield immense influence and aren’t always in alignment, there are some limits to what someone operating in this model can achieve. Their contribution is basically limited by the ideas brought into the common pool of discussion between stakeholders. Much like the decider, they are not so much adding expertise, rather than simply cutting through conflict and indecision. In order to grow, diplomats must grow their own expertise and offer more value than simply bringing parties to the table and helping mediate differences.
Moving beyond simple positional negotiations, experienced diplomat product owners move into another category I call the catalyst. In this archetype, they have accumulated considerable experience in their own right both in the problem domain, as well as in negotiation, communication and collaboration. Superficially, it may appear that they are operating in a similar model to the diplomat, but there are two key differences. They are strategic in who they engage and they are able to engage people in a way that allows new solutions to emerge.
As the name implies, catalysts play a critical role in helping get elements already within the system to react in ways that release energy or cause other valuable changes. In the case of Agile software development, this may be bringing to seemingly irreconcilable groups together to craft a shared vision allowing them to see how their interests can positively intersect. It may be pursuing other stakeholders in order to better balance the vision for a product. For example, one product owner I worked with brought several of the people from the business unit he represented to meet with the team periodically. They would show the team the type of work they did and how the project was going to benefit them. Incidentally, in one of these discussions, the lead architect happened to key into one pain point they mentioned about compiling reports – the point of this entire project was to streamline operations for this group – and he began to explore an entirely different solution to help solve that problem. In the end, his side investigation identified a novel way to use some of the systems they were developing to deliver automation to this business unit significantly faster, also meeting the ROI target of the project before they had completed the primary deliverable.
The catalyst is comfortable with problems with no apparent solution and invites as many perspectives as possible when confronting the problem, even if they have amassed sufficient authority that a decision rests solely within their domain. They understand that a shared vision not only fosters more solutions, but increases follow through on the actual execution. The challenge facing the catalyst is that regardless of the number of feedback loops they develop and their ability to engage different stakeholders, sometimes product require breakthrough innovation and different thinking. Apple offers a striking example of apparently counter-intuitive thinking including intentionally designing products they think are cool rather than doing market research. In the end, we see the catalyst growing by building up product expertise from unique sources of feedback and eventually converging towards the path of the genius.
Two Different Paths
These archetypes present more like a series of logical stepping stones for someone to make as they progress towards being an increasingly capable product owner. Some product owners focusing on exerting authority in the decider archetype. From there they build expertise and eventually move into a genius role. Others do not have the opportunity up front to be authoritative and must opt for a diplomat archetype. The growth opportunity for them is to build authority and decision making capabilities through their growing ability to influence without explicit power, allowing them to grow into the catalyst change. When first laying this out, I didn’t mean to show a progression, nor did mean to have the two paths diverge and then converge. Is there a sixth archetype that sits between the genius and the catalyst? Is there some ideal mastery of both influence and expertise that all product owners are striving to achieve? While I certainly agree that there are always further opportunities for growth, I’m not sure I can identify an idealized end state for this journey, so for the time being I have left this spot open. It seems identifying a terminus for some perfect product owner would undermine the concept of continual learning and growth that is one of the most important things I see in successful product owners. So let me just conclude on a note that there is no one pre-ordained journey. By enumerating these archetypes I hope others in those situations can help identify their circumstances and use that awareness to their advantage.