A common question that we get is what is the difference between Product Owners (POs) and Product Managers? From a Disciplined Agile (DA) perspective, it’s a matter of strategy vs. tactics:
We Need to Collaborate
As you can see in the following diagram, the role of Product Manager is different, yet overlapping, with that of a Product Owner (PO). The PO will spend the majority of their time on tactical activities, including working with the team to communicate stakeholder needs to them and working with stakeholders to elicit and prioritize their needs. The Product Manager, on the other hand, spends most of their time on more strategic issues, collaborating closely with customers (and potential customers) to identify their potential needs.
There is clearly overlap between strategic, long-term thinking and tactical, short-term implementation. Product Owners are responsible for the Product Backlog in Scrum, what Disciplined Agile DAD (DAD) teams might refer to as a Work Item List or in the case of teams who have adopted one of the lean lifecycles a Work Item Pool, and some of the items in the backlog/list/pool might be several months away from being implemented (if ever). In Figure 1, these are items that fall into the yellow or red timing areas, or even the grey area. Product Managers, being responsible for strategic thinking, will be focused on high-level outcomes or themes for the product. They may even be focused on more concrete, yet still high level, epics or features. So we see overlap in the Product Manager’s high-level strategic focus and the Product Owner’s tactical focus, indicating the need for collaboration between the two roles so that the tactical decisions reflect the overall strategy, and the overall strategy is informed by the realities faced on the ground by the delivery team.
Please note that the timing of “short term” and “long term” will vary by product. In the case of Figure 1 the long-term planning horizon is around the three month point (where the diagram shifts from yellow to red). That’s just an example, from one team. We’ve worked with some teams where the long-term planning horizon was anything more than a month. We’ve also worked with other teams where the long-term planning horizon was closer to a year (they’ve since shortened that considerably).
Shouldn’t Product Owners Also Address Strategic Issues?
Here are a few thoughts to help answer this question:
Being a Product Manager is an interesting and exciting role. We hope that this blog has been valuable for you.
The term minimal viable product (MVP) has achieved buzzword status in recent times and I’m now hearing people throwing around the term MVP almost on a daily basis. Sometimes they’re using it correctly but many times they aren’t. Frankly it’s driving me nuts.
The issue is that it’s common for people to say MVP when they are actually talking about a minimal marketable feature (MMF), a minimal marketable product (MMP), or even a minimal marketable release (MMR). As you can see, these terms are very similar to one another so we shouldn’t be surprised that there’s a bit of confusion around them. So let’s try to clear things up.
First, Some Definitions
Figure 1 below overviews how these following terms relate to one another:
Figure 1. The relationship between MVP, MMF, MMR, and MMP.
Is it Minimum or Minimal?
Given that I’m being picky about terminology, I realized that there isn’t agreement as to whether we should use the term MINIMUM viable product or MINIMAL viable product (and similarly for MMR, MMP and MMF). Once again, the words are very close:
As you can see, very nuanced. For our purposes the term minimal is more appropriate than minimum because it brings in the idea that it must be sufficient to fulfill the needs of our product’s customers. Or more precisely, what we believe to be the current pressing needs of our stakeholders.
Example: Developing a New Product
Now let’s work through an example of the development of a fictional product. One day while shopping in the local mall my phone ran out of power. This proved to be a problem for me because I had a conference call that I had to be on, forcing me to cut my shopping trip short to go home and take the call there. This experience made me realize that there’s a potentially untapped market need as I would have been very willing to pay to charge my phone while at the mall. Note: I am fully aware that products such as Safecharge and Brightbox exist, but let’s pretend they don’t for the sake of this example.
Just because I’m willing to pay for this doesn’t mean that others will. To determine whether this could be a profitable endeavour I decide to follow Disciplined Agile’s Exploratory Lifecycle (see Figure 2), which is based on Lean Startup’s hypothesis-driven approach. My plan is to iteratively build a series of MVPs to explore this product idea.
Over a several week period I work through a series of minimal viable products (MVPs):
This series of experiments led me to identify a collection of minimal marketable features (MMFs) that this product should offer:
Over the next two months we built a minimal marketable product (MMP). The MMP was five large boxes, each of which had 16 cubby holes for small devices such as phones. We wanted five boxes so that we could place three boxes in the mall where we had run our initial experiments and two boxes in another smaller mall on the other side of the city. We made each box from folded sheet metal with clear, thick plastic doors so that people can see their devices. For security and payment processing we built a device that used a small touch screen (it was actually a large smart phone) as an input device attached to a card swipe for capturing both credit and debit card payments.
Over time we continued to evolve the product via a series of minimal marketable releases (MMRs). We ran some experiments in a public library where we discovered that library patrons wanted to charge large devices such as tablets and laptops as well as smaller devices. We developed a “Library Charging Station” that had eight small device cubbies and six large device cubbies. We also hired a designer to develop a sleeker looking box when one mall management change told us that they loved the concept but wouldn’t allow our boxes into their more upscale locations until our boxes where more attractive.
Why The Confusion?
There are several reasons why there is significant confusion in the marketplace:
My hope is that this article, and the supporting poster that is now available on the Disciplined Agile Consortium site, has helped to clear up some of this confusion.
A common challenge that we run into when working with organizations adopting Disciplined Agile strategies is helping them to identify and then coach people for the Product Owner (PO) role. This is often easier said than done due to the dearth of people with the required sill and mindset. In this blog we explore several strategies to address this challenge.
What Are You Looking for in a Product Owner?
Let’s begin with a review of the requirements for a good product owner:
Given the skill requirements it shouldn’t be surprising to anyone that there is a shortage of candidates for the PO role in most organizations. Let’s explore your options.
There are several potential sources of new product owners. The following table compares and contrasts these options. As you can see there is no ideal option available to you, and the reality is that you will likely need to obtain PO candidates from whatever source you can find.
An interesting strategy that we’ve found fruitful, albeit one that borders on ageism, is to look for potential candidates whom have been with your organization for a long time and who are getting close to retirement. These are experienced people who therefore are likely to have a good understanding of your organization and where it’s headed, they very likely have a good contacts throughout your organization, and they’re very likely looking for an interesting and stable position that will last until they’re ready to retire. Given that the investment required to create a Product Owner is rather steep so therefore you want someone willing to stay in the position for at least several years, and given that these are experienced people looking for a position that will last several years, it’s a very good alignment that you should consider taking advantage of.
Have a Clear Career Path
A critical success factor for attracting people to the role of PO is to have a clear and viable career path for them. If it isn’t obvious to people where they would go next after becoming a PO, or worse yet if becoming a PO is seen as a career dead end, then why would anyone choose to step into this role? One option for POs is to become product managers, if a product management function exists in your organization. Another career path is for POs to move into a senior business or IT leadership position. Being a PO gives people a deeper understanding of how IT fits into the larger organization and how it works in practice – key skills for anyone in senior management these days.
The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.
Rolling wave planning is implemented in several places of the DA toolkit. First, as you can see in Figure 1 below, it is an option of the Level of Detail decision point of the Develop Initial Release Plan process goal. A rolling wave approach to release planning has the advantages of more accurate and flexible planning although can be a bit disconcerting to traditional managers who are used to annual planning strategies.
Figure 1. The Develop Initial Release Plan goal diagram.
The Portfolio Management process blade supports rolling wave budgeting as an option for its Manage the Budget decision point. This is depicted in Figure 2. The advantages are greater flexibility and greater likelihood of investing your IT funding more effectively, albeit at the loss of the false predictability provided by an annual budgeting strategy.
Figure 2. The goal diagram for the Portfolio Management process blade.
The Program Management process blade supports rolling wave planning of a program itself, as you seen in Figure 3. Planning and coordination are critical on a large program, and rolling wave planning offers the advantages greater flexibility, the ability to think important cross-team issues through, and the ability to react to changing stakeholder needs. The primary disadvantage is that it can be disconcerting for traditionalists who are used to thinking every thing through from the beginning.
Figure 3. The goal diagram for the Program Management process blade.
As you can see in Figure 4, rolling wave strategies can be applied in Product Management to evolve the business vision/roadmap. A continuous, rolling wave approach is critical to your success because the market place changes so quickly – these days, few organizations can tolerate an annual approach to business planning and in the case of companies with external customers an ad-hoc approach can prove to be too unpredictable for them.
Figure 4. The goal diagram for the Product Management process blade.
Previously we saw that rolling wave strategies can be applied to evolve your technology roadmap, as indicated in the goal diagram for Enterprise Architecture in Figure 5. The advantages of this approach are that your roadmap evolved in sync with both changes in technology and with your organization’s rate of experimentation and learning. The main disadvantage is that your technology roadmap is effectively a moving target.
Figure 5. The goal diagram for the Enterprise Architecture process blade.
As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) toolkit. In fact, in most situations they prove to be the most effective and flexible strategies available to you. The advantages of rolling wave planning tend to greatly outweigh the disadvantages. More on this next time.