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 minimum 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. The issue is that it’s common for people to say MVP when they are actually talking about is a minimum business increment (MBI), a minimum marketable feature (MMF), or a minimum marketable release (MMR). Having said that, I prefer the terms MVP and MBI, two different concepts, and rarely use terms like MMF or MMR other than to point people to the first two terms. Having said that, I'll still cover all four concepts in detail here.
There are several reasons why there is significant confusion in the marketplace:
To clear things up, we address the following topics:
Figure 1 below overviews how the following terms relate to one another:
Figure 1. The relationship between MVP, MBI, MMR, and MMF.
We often get asked several common questions around this topic:
What are the Key Take-Away Points?
The key take-away points of this article are:
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 MBI, MMR, and MMF). Once again, the words are very close:
As you can see, very nuanced. For better or worse, the industry has settled on the term minimum so that's what we're sticking with.
Why Differentiate Between MBI and MMR?
We wish we didn't have to. Ideally an MMR is a single MBI - your team wants to do just enough work to develop the minimum functionality that provides your customers with value and release it as quickly as you can. That's an MBI. Practically though you're sometimes forced to release more than a single MBI in a release. Perhaps you've decided to have a regular quarterly release cadence. Perhaps your customers prefer large releases (this still occurs in practice, although is becoming less common as your customers become more savvy with regards to incremental releases). These challenges can all be addressed in time, and they should be, but you may not be there yet.
Don't We Just Need The Concepts of MVP and MBI?
That's correct. When you've streamlined your way of working (WoW) you should be at the point where an MBI is an MMF that you release to your customers, so it is also an MMR. The concepts of MMF and MMR are stepping stones towards what you are really aiming for, MBIs. But you might not be there yet, and you may be working with people who are more familiar with older terminology such as MMF and MMR - as a result we recognize in DA that these older terms exist but we avoid them where we can.
Now let’s work through an example of the development of a fictional product using the concept of MVPs and MBIs. 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 run a series of experiments to explore this product idea.
Figure 2. The Exploratory Lifecycle.
Over a several week period I work through a series of minimum viable products (MVPs):
This series of experiments led me to identify a collection of features that this product should offer:
Over the next two months we built a minimum business increment (MBI). The MBI was a large box which had 16 cubby holes for small devices such as phones. We the 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 a tablet) as an input device attached to a card swipe for capturing both credit and debit card payments. Over several weeks we built five of them, placing 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.
Then we continued to evolve the product via a series of MVPs. 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. So we developed a new MBI, 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 chain told us that they loved the concept but wouldn’t allow our boxes into their more upscale locations until they were more attractive.
I'll say it again (a paraphrasing of Al Shalloway's advice):
Here's the key difference between the two: With an MVP you are in entrepreneurial mode and need to discover what your customers actually want. MBIs are for when you have an existing product and have a good idea for how to extend it.
My hope is that this article has helped to clear up some of this confusion.
5. Related Resources
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.
For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) toolkit, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few. This article explores how to apply rolling wave planning in a pragmatic manner to product roadmaps.
An important aspect of product management is to develop and evolve an overall business vision, an important part of which is your organization’s product roadmap. This is sometimes called a “multiple product roadmap” or “product offerings roadmap” although more commonly just a “product roadmap.” This roadmap indicates upcoming product releases (or application releases for non-product companies), potential product ideas, and the retirement of any products. The goal is to manage customer expectations regarding your product portfolio.
An example of a product roadmap for a fictitious company is depicted in Figure 1 below. For product planning this company’s very near term (green) is a three month, rolling period. In this case we’re seeing the roadmap as of September 2016. For the very near-term the expected release dates of each product are indicated. This company has chosen to also do this for some, but not all, of the products being release din the near term (yellow) – In some cases it isn’t yet clear exactly when a release will occur so the company doesn’t want to set unrealistic expectations by giving an exact date yet. In the case of Katana 12.1 they are committing to a date whereas with Webshooter 1 they are committing to sometime during quarter 2 (April through June). The other product releases do not have published dates yet.
Figure 1. A product roadmap (text approach) from September 2016.
It’s interesting to note that for upcoming (red) they are choosing to just indicate new products they hope to release during that period but not releases of existing products. This is because this period is nine months or more into the future so promising exact dates to people becomes a questionable proposition, far better to indicate ranges for now. For the distant future (gray) the product roadmap shows potential ideas for new products but these are only vague “wish list” items at best right now, not all of which will be invested in.
Figure 2 depicts a timeline version of a product roadmap. It focuses on currently planned product releases and so it does not depict the future product ideas that we saw in Figure 5. These product ideas would be captured elsewhere, perhaps as a list on a whiteboard some where.
Figure 2. A timeline version of a product roadmap.
What Should the Planning Horizon Be?
Product roadmaps tend to have a multi-year planning horizon. Figure 1 showed about two years of planning whereas Figure 2 a bit more than a year. There are several key considerations to take into account when determining your planning horizon. First is how often can your teams release? You typically want to be able to indicate several releases of your major products/solutions on your roadmap, which you can see in both examples. Second, how often do your customers want releases? Third, how far in advance do your customers need to plan? This is a reflection of the sales cycle for your products, the longer the sales cycle the longer between releases of your product (usually) and the longer the timeframe covered by your roadmap.
How to Capture Product Roadmaps
There are two basic strategies for depicting product roadmaps:
Your product roadmap is an important part of your organization’s overall business vision. Another part of that vision is your business roadmap, the topic of a future blog.