Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

Embracing Mindset Diversity in Disciplined Agile

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

Disciplined Agile (DA)'s Value Streams Layer

Money river - Source Getty

The value streams layer encompasses the capabilities required to provide value streams to your customers.  A value stream begins, ends, and hopefully continues with a customer. A value stream is the set of actions that take place to add value for customers from the initial request through realization of value by the customers.  The value streams layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the value streams layer.

Figure 1. The layers of the DA tool kit.

Disciplined Agile Layer Overview

Figure 2 depicts the DA FLEX lifecycle, overviewing the high-level workflow for a value stream.  As you can see, a value stream begins with the initial concept, moves through various stages for one or more development teams, and on through final delivery into business operations.

Figure 2. The DA FLEX lifecycle for value streams.

DA FLEX lifecycle

Let's explore the components of Disciplined Agile's value stream layer.  The hexes in Figure 2 and Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner.  Process blades also describe functional roles specific to that domain as well as extensions to the DA mindset specific to that domain. 

Figure 3. The process blades of Disciplined Agile's value stream layer.

Disciplined Agile Value Streams Layer

You can see in Figure 3 that some process blades, such as Product Management and Program Management, are specific to this layer.  Other process blades, such as Strategy and Marketing, are shared between the value streams layer and the disciplined agile enterprise (DAE) layer. This is an indication that you may choose to implement those process blades at both the enterprise level as well as the level of a single value stream - do what is right for your situation.

Expanding upon the Disciplined DevOps layer, the value stream layer adds the following blades:

Business operations

Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.

Continuous improvement

The continuous improvement process blade describes how people within your organization can share their improvement learnings with one another in a systematic way.  There are many strategies for doing so, including centers of excellence (CoEs), communities of practice (CoPs) which are also known as guilds, techniques for exploring existing ways of working (WoW), identifying new WoW, and sharing techniques.

Governance

Governance is the leadership, organizational structures, and strategies to enable you to sustain and extend your organization’s ability to produce meaningful value for your customers. Lean governance promotes strategies such as motivating people to do the right thing, enabling them to do so (often via automation), communicating organizational objectives, and preferring visibility over reporting.

Marketing

The goal of marketing is to ensure successful interactions between your organization and the outside world. Disciplined Agile marketing applies data and analytics to continuously source promising opportunities or solutions to problems in real time, deploying tests quickly, evaluating the results, and rapidly iterating. It also means taking a validated learning approach, being customer focused, working in a collaborative and flexible manner, and working in an evolutionary (iterative and incremental) manner. Your marketing efforts will represent your organization and your offerings, both products and services, to the outside world and conversely will represent external stakeholders, and potential stakeholders, to the rest of the organization. In conjunction with product management, Marketing will be actively involved with long-term visioning for your organization’s offerings. Marketing is sometimes called brand management

Portfolio management

Portfolio management addresses how an your organization goes about identifying, prioritizing, organizing, and governing their various endeavors. Disciplined Agile portfolio management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. Potential endeavors include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing solutions.

Product management

Product management is the art of taking strategic objectives and turning them into tactical activities.  Disciplined agile product management is performed in a collaborative and evolutionary manner that reflects the context of your organization. Disciplined agile product management includes the acts of:

  • Identifying and prioritizing potential products/solutions to support your organization's vision;
  • Identifying, prioritizing, and allocating features to products under development;
  • Managing functional dependencies between products;
  • Marketing those products to their potential customers;
  • Exploring the needs of existing and potential customers;
  • Identifying minimum business increments (MBIs) for delivery teams to work on.

Program management

A program is a large team composed of two or more sub-teams (also called squads). The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goals of the overall endeavor. Program management encompasses financial activities, vendor management, coordination of people/staffiing concerns, coordination of the evolution of the solution, and coordination of requirements management issues across the sub-teams within the program.

Research & development

Research & development (R&D) encompasses the innovative activities undertaken by your organization to identify potential new offerings (services or products), or to identify potential improvements to existing offerings. R&D constitutes the first stage of development of a potential new offering.  R&D activities are an important part of both product management and solution development to help explore potential ideas and strategies.

Sales

The aim of your sales efforts is to, you guessed it, sell your organization’s offerings (both products and services) to customers. Your sales people, if any, will work very closely with your marketing team to ensure they are focused on selling offerings that reflect your organizations’ overall strategy. They will also work closely with product management to ensure that what they’re selling is available or can be built in a timely manner. Organizationally Sales is often combined with marketing or may even be matrixed into business operations.

Strategy

Strategy is what you do now, and what you intend to do in the future.  The focus of the strategy process blade is to identify, evolve, and then drive the execution of your organization’s vision. Your vision is driven by the perceived needs of your customers and influenced by the environment in which you operate.

 

Posted by Scott Ambler on: October 02, 2020 12:00 AM | Permalink | Comments (6)

Product Owners vs. Product Managers

People

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:

    • Product Owners are more tactical in practice.  POs work closely with delivery teams to ensure they build the right functionality in a timely manner. POs will transform the high-level vision of the Product Manager into detailed requirements. To do this they work closely with a range of stakeholders for the product, including non-customer stakeholders such as finance, security, operations, support, audit, and others.  Tactical activities such as attending team coordination meetings, organizing demos, doing sufficient analysis to ensure that requirements are ready to be worked on, and being involved with ongoing testing efforts easily add up to a full-time job.
    • Product Managers are more strategic in practice. They should be focused on the long-term vision for the product, on observing trends in the marketplace, on identifying new potential outcomes or themes to be supported by the product, on supporting the sales/adoption of the product, and on ensuring the product meets the needs of the value stream(s) the product is involved with. Effective Product Managers tend to be very customer focused, although recognize that this needs to be tempered by the constraints and capabilities of your organization. The activities that Product Managers are responsible for – product marketing, supporting product sales/adoption, budgeting, long-term envisioning, customer care, and of course supporting the solution delivery team(s) – can easily add up to a full time job.

 

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.

Figure 1. Example of rolling wave planning for product functionality (click on image for larger version).Product Owners and Product Managers

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:

  1. Everyone should consider strategic issues.  Some people, particularly those focused on Scrum, will tell you that Product Owners should also be focused on strategic issues.  It’s certainly good for POs to understand the long-term strategy for the product that they are focused on. In short, POs, like everyone else, should be Enterprise Aware.
  2. Each role requires a different, and comprehensive, skillset.  Each of these roles are challenging enough by itself. You’ll have a much better chance of finding someone with the skills to work tactically, and someone with the skills to work strategically, than finding a single person with both skillsets (or the time and inclination to pick up both).
  3. There is often too much work for one person.  As we argued earlier, the day-to-day tactical work tends to be a full-time job (and often more) as does the strategic Product Management work.  As a result, you are often motivated to tease these two roles out into separate positions.
  4. These are roles, not positions. In straightforward, non-scaled situations, it is common to see a single person taking on both of these roles.  This is common in start-up organizations where the company simply can’t afford to have two people to do this work.  It’s also common with new products in general because it isn’t yet obvious whether the product will be sufficiently successful in the marketplace to warrant much investment in long-term strategic thinking around it.

So, as usual, the answer is “it depends.”  As we like to say in DA, context counts which is why choice is good.

 

Related Reading

Posted by Scott Ambler on: February 10, 2018 09:44 AM | Permalink | Comments (0)

The Disciplined Agile Product Management Mindset

Mindset
Building on the ideas captured by the Disciplined Agile Principles and the Disciplined Agile Manifesto, there are several agile/lean philosophies that are critical to success in Product Management.  These philosophies are:

  1. Be customer driven.  The needs of customers, and more importantly the potential desires of customers that they are not even be aware of, should drive your Product Management decisions.  The implication is that Product Managers must work closely with existing customers, and furthermore must invest time to identify and understand potential customers so as to grow the market for their product.
  2. Address the full value stream.  An important part of being customer driven is to understand that it is the full customer experience with your organization, not just the “products”, that must be addressed.  You need to understand the full value stream(s) that your product(s) are part from beginning to end from the customer’s point of view – Product Management is about solutions and not just software.
  3. Take an experimental approach. People often don’t know what they want, will struggle to describe what they want, often won’t tell you want they want, and will change their minds anyway.  The point is that you need to go beyond asking people for their requirements if you want to identify what to offer your customers.  Modern thinking is to take an experimental approach via creation of minimal viable products (MVPs) to get something in front of potential customers to determine what they actually want – you do this through observing the features of your MVP that they use, how they use them, and the features that they don’t use.  This strategy was popularized by Eric Ries via his Lean Startup work and is captured in DAD’s Exploratory lifecycle.
  4. Release incrementally and often.  Releasing smaller increments more often enables you to reduce the feedback cycle with your customers, which in turn enables you to learn quickly and thus react to customer needs faster.
  5. Embrace change.  Customer needs and desires change, often rapidly.  New competitors enter the market with different or improved offerings.  New technologies and platforms are introduced and then evolved.  To be trite, the only constant is change.  Successful product managers not only accept this but they embrace it.  The implication is to adopt flexible, light-weight strategies.
  6. Plan strategically and react tactically.  Products should be planned strategically in the long term yet implemented tactically in the short term.  The common agile strategy is to take a what is known as a rolling wave planning approach where detailed planning occurs for what should be delivered in near team incremental releases but for future releases the planning is high-level and less detailed the further in the future something is.

Being a Product Manager is an interesting and exciting role.  We hope that this blog has been valuable for you.

Posted by Scott Ambler on: January 04, 2018 05:40 AM | Permalink | Comments (0)

Defining MVP, MBI, MMF, and MMR

 

Dictionary

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.  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 a minimum business increment (MBI), a minimum marketable feature (MMF), a minimum marketable release (MMR). There are several reasons why there is significant confusion in the marketplace:

  • These are closely related concepts with very similar names.
  • Various authors over the years have used these terms in different ways, thereby muddying the waters.
  • Few people go back to the original source of a concept and instead choose to read derivatory work (such as this article).  In effect suffer from the whisper game – you heard the term MVP from one person, who heard it from someone else, who heard it from someone else, and so on.

To clear things up, we address the following topics:

  1. Defining the terminology
  2. Answering common questions
  3. An example
  4. Summary

 

1. Defining the Terminology

Figure 1 below overviews how the following terms relate to one another:

  • Minimum Viable Product (MVP). An MVP is a version of a new product that is created with the least effort possible to be used for validated learning about customers.  MVPs are used to run experiments to explore a hypothesis about what your customers really want.  They are much closer to prototypes than they are to the “real” running version of your end product.  A development team typically deploys an MVP to a subset of your (potential) customers to test a new idea, to collect data about it, and thereby learn from it.  MVPs are created to help you to find the features that customers are actually interested in.  Note that the term MVP was originally coined by Frank Robinson although was popularized by Eric Ries.
  • Minimum business increment (MBI). An MBI is the smallest piece of functionality that can be realized by a customer (internal or external) that is consistent with the strategy of the business and makes sense to deliver when transaction costs are considered.  An MBI adds value for your customers and provides valuable feedback to the product team that the right functionality is being built and is being built in the right way.  An MBI provides functionality that can be delivered and which can also be validated as being useful and it enhances the ability of the organization to deliver value in the future. An MBI is a solution that contains all of the pieces that are required for value realization. An MBI, when it is done right, is both an MMF and an MMR.
  • Minimum Marketable Feature (MMF). An MMF is the smallest piece of functionality that can be delivered that has value to both the organization delivering it and the people using it.  An MMF is a part of an MMR.  The term MMF was first proposed by Denne and Cleland-Huang.
  • Minimum Marketable Release (MMR).  Successful products are deployed incrementally into the marketplace over time, each “major” deployment being referred to as a release.  An MMR is the release of a product that has the smallest possible feature set that addresses the current needs of your customers.  MMRs are used to reduce the time-to-market  between releases by reducing the coherent feature set of each release to the smallest increment that offers new value to customers/end users. An MMR is one or more MBIs.

Figure 1. The relationship between MVP, MBI, MMR, and MMF.

Defining MVP

It is important that the term “marketable” doesn’t mean marketing in the sense of a product, but rather, making people aware of the value of what is being released. This can be as it related to a product or service and applies whether it is external or internal. In other words “something that is useful to the customer (internal or external) that can be demonstrated to be of value.

 

2. Answering Common Questions

We often get asked several common questions around this topic:

  • Is it minimum or minimal?
  • Why differentiate between MBI and MMR?
  • Don't we just need the concepts of MVP and MBI?

 

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:

  • Minimum. The refers to the least quantity or lowest possible amount.
  • Minimal.  This refers to barely adequate or sufficient (similar to the agile concept of just barely good enough (JBGE)).  Minimal is an adjective derived from the word minimum.

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 will find that 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.

 

3. An Example

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 build a series of MVPs to explore this product idea.

Figure 2. The Exploratory Lifecycle.

Exploratory Lifecycle - Lean Startup

Over a several week period I work through a series of minimum viable products (MVPs):

  1. MVP #1: A power bar on a table.  I start with a very simple approach: I talk the mall manager into allowing me to put a table against a wall for a one week period to run an experiment. I plug a power bar into a nearby outlet and put it on the table.  On the wall I have a sign that indicates this is a phone charging station.  Throughout the week I stand by the table telling people about the service and tell them I’ll keep an eye on their phone if they want to go shopping while it charges (I quickly discovered that nobody is willing to actually do that, or at least they’re not willing to trust me, hmmm….). For anyone willing, I have them take a short survey asking them what they think about the service.
  2. MVP #2: I add several common power cords. On the first day several people indicated that they would use the service but unfortunately didn’t have their charging cable with them.  So at the end of the first day I bought several power adapters from an electronics store in the mall. Sure enough, over the next few days I had more people willing to charge their phones at my table.  By the end of the week I had gathered a fair bit of data that showed there was general interest in the idea but that a major problem was the inability to safely leave a device to charge while they go off to shop.
  3. MVP #3: I move to a cafe. The following week I run a similar experiment in a cafe a few blocks away from where I live.  Interestingly, I have several people ask to borrow a power cable from me so that they could power their phone while sitting at their own table.  The cafe already has power sockets for people to charge devices and it’s fairly common for people to camp out in the cafe for several hours with a laptop or table plugged into the wall.  After several days it becomes clear to me that a cafe isn’t a good option for a charging station.
  4. MVP #4: I add lockable cubby holes.  Over the next week I decide to build out a more sophisticated solution, a wood cabinet that has 16 cubby holes for charging devices.  Each cubbyhole has a specific type of charge cable, so if you want to change a phone you need to use a cubby with the right type of cable.  Each cubby has a door with a physical key lock.  I go back to the mall, in the same location as I’d been in previously, and instead of a survey I interview people to discover what they they think, how they would make it better, and what they’d be willing to pay for such a service.

This series of experiments led me to identify a collection of minimal marketable features (MMFs) that this product should offer:

  1. Lockable cubby holes.  People will only leave their phones and other devices if they’re safe.  Each cubby hole needs to be locked in such a way that only the person who left their phone in the cubby can get access to it.  This could be an electronic locks where people can type in a private code or a physical key-based system.
  2. Common phone power cords.  We need to be able to support charging a range of devices.  Each cubby should have several common power cord/cables as well as a normal power plug.
  3. Easily accessible location that doesn’t offer charging alternatives.  Malls and restaurants are good options, but public areas that already support device charging (like cafes) are not.
  4. Payment processing.  We want to support credit card and possibly blue-tooth payment strategies such as Apple Pay.  Payment options need to be investigated still.

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 actually a large smart phone) 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 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.

 

4. Summary

Al Shalloway says it best: An MVP is an investment in learning, and an MBI is an investment in value.

Here's the key difference between the two: With an MVP you are in entrepreneurial mode and need to explore what your customers actually need.  But this can only be done by a strongly cohesive and aligned team due to the uncertain, exploratory nature of the work.  MBIs are for when you have a product or service and have a good idea for how to extend it.  The biggest challenge is often coordinating the parts of your organization that is going to build, release, and support it.

My hope is that this article has helped to clear up some of this confusion.

 

5. Related Resources

Posted by Scott Ambler on: December 27, 2017 08:13 AM | Permalink | Comments (3)

Where Do Product Owners Come From?

People

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:

  1. Analysis skills. POs need to be able to elicit requirements, explore them with stakeholders, negotiate priorities, facilitate modeling sessions, and in some cases document requirements.
  2. Decision-making authority. POs need to be empowered to prioritize the work of the team AND need to be comfortable with doing so.
  3. Good stakeholder contacts. POs need to know who to work with in the entire range of stakeholders, including both business and technical stakeholders.
  4. Full-time availability. This is a full time job, and at scale often proves to require more than a single person in the role (more on this in future blog postings). They’re available to the team on a daily basis.
  5. You want them in the position for several years. It takes time to grow an effective PO, depending on the background of the person we’ve seen people take between six and eighteen months to truly become comfortable in the role. This is a fairly large investment for your organization, so once you’ve made that investment its reasonable to want someone to stay in the role for at least a few years.
  6. They understand both your business domain and IT infrastructure. When taking a Disciplined Agile approach to product ownership the PO is responsible for representing all stakeholders, including both technical and business stakeholders. An implication of that is that POs should have a good understanding of the business domain and direction as well as your existing IT infrastructure and the direction that it’s going in. These understandings will be very important for prioritizing the work effectively.

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.

Potential Sources

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.

Potential Source Advantages Disadvantages
Business analyst
  • Strong analysis skills
  • May have a very good understanding of the overall business
  • Likely to have good stakeholder contacts
  • Likely available full time
  • May not have decision making authority nor be comfortable with it
  • May not have an understanding of the technical infrastructure
Business architect
  • May have a very good understanding of the overall business
  • Likely to have good stakeholder contacts
  • Likely available full time
  • May not have decision making authority nor be comfortable with it
  • May not have an understanding of the technical infrastructure
Business executive
  • Has decision making authority and experience
  • Likely has a good understanding of the business
  • Unlikely to have the time to be a product owner
  • Many only be focused on a single line of business (LoB)
  • Unlikely to have a sufficient understanding of the technical infrastructure
  • Unlikely to have good analysis skills
New hire
  • You can potentially hire someone with the requisite skills
  • Available full time
  • They are unlikely to have the stakeholder contacts, or understanding of your organization, required to be effective (in the short term)
Project manager
  • Has decision making authority and experience
  • Might have decent analysis skills
  • Likely available full time

 

  • May not have a sufficient understanding of the technical infrastructure
  • May not have full range of stakeholder contacts
  • May not have good relationship with delivery team
Senior business person
  • Likely strong at a single LoB
  • May have decision making authority and experience
  • Likely to have very strong connections in the business
  • Rarely available full-time
  • May not have an understanding of the full range of business
  • Unlikely to have an understanding of the technical infrastructure nor connections with technical stakeholders
  • May not have analysis skills
System analyst
  • Strong analysis skills
  • Likely to have an understanding of the technical infrastructure and the overall business
  • Available full time
  • May not have strong connections with business stakeholders

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.

 

Posted by Scott Ambler on: November 21, 2016 05:53 AM | Permalink | Comments (0)
ADVERTISEMENTS

"There are painters who transform the sun into a yellow spot, but there are others who, with the help of their art and their intelligence, transform a yellow spot into the sun."

- Pablo Picasso