Improving Agile Product Owner Effectiveness in Business Services Organizations

By: John David Woods, CMO, Dotcom Distribution

John David Woods, CMO, Dotcom Distribution

Experienced agile project managers and product owners often have trouble adapting to their new environment when entering the fast paced and often chaotic world of business services. In past positions, I have managed technology for data services, marketing services, and call centers. Though these teams were all ultimately successful deploying agile, one of the biggest challenge we faced was figuring how improve the retention rate of experienced agile team members as they transitioned into our space.

"You are part of a service organization, and we know how to get things done quickly and efficiently"

Because agile methodologies were initially developed to help improve the delivery of software, it makes sense that the various roles and artifacts would deploy well in that area. In order to gain the maximum benefit from agile outside of software, you’ll need to be firm enough to maintain the basic elements of the process, but flexible enough to adapt them to your new environment. Think about it from the perspective of an agile product owner for a software company. Your work supports a platform that people interact with or will interact with, and as the result of those interactions, users make suggestions for improvements to discreet features and interfaces. A formal design team typically introduces new features and feature enhancements. As the product owner, it’s your job to balance the mix of internally requested feature additions, fixes, and long term optimization projects, and you work with a project manager and development team who specialize on that product. You’re also probably very good at keeping everyone focused on business value.

This is not the way of most service organizations. The typical offering is more of a matrix comprised of human and system processes, adapted to provide output specific to each client. This not-so-subtle difference usually first manifests itself when an agile implementation team suggests appointing a product owner. Because of this, service failures and fallout are sometimes assessed in terms of personality rather than process. Additionally, service organizations tend to define the client experience in terms of satisfaction with their account management team. These drivers, among others, make it hard to establish the baseline for an ideal user experience. That said, I firmly believe that agile project management implementations significantly improve outcomes for service organizations, and that the success of an agile deployment depends on the integration of the product owner role into the business.

The question is – how can you be an effective product owner if you have no products?

Focus on the user experience

If you or someone you support are part of an organization that has not historically examined its services as individual products, then be prepared to step out of your comfort zone. To succeed, you’ll need to take on additional responsibility and work one step upstream from the traditional agile product owner role. You’ll need to sponsor an effort to define the service groups that will ultimately become your products.

The first step in identifying service products is to create a high level process map for a relevant sample of existing clients. Perhaps you can organize by industry served, perhaps by revenue tier, maybe by number of users – the idea is that the business probably already has some organic grouping for its clients and that’s a great place to start. As you map, identify the inputs and outputs for every process, not only the system processes, but the human processes that facilitate the initiation, integration, and termination of system processes.

Where you identify similar (or mostly similar) process chains, you have something that could be a product. The next step is to create a more detailed map of those products as the customer experiences them. Deploy what you know, user stories:

“As the head of marketing for ABC Company, I call my account manager to kick off the process for a monthly target list.”

This is a good starting point in defining the individual user experiences or “features” of your products as they are today. Each interaction point represents another user experience. For example, a user is aware of the time it takes to upload a file, the utility of any confirmation messaging, how helpful the exception reports may be in identifying a problem on their end, error handling, call connection rates, service ticket initiation and follow up, etc.

Borrow from Six Sigma

You cannot go wrong by asking your customers to help define expectations and basic needs. Because services are usually as much process-based as they are system-based, I recommend drawing from Six Sigma which is the best process improvement toolset we currently have. Six Sigma offers proven tools for gathering both the voice of the customer and of the employee, though this initial exercise does not need to be too rigorous. In a structured way, ask your users to describe how they interact with each feature, to describe its usability. To use an older but simple example, you might find:

“As the client accountant on this job, when I download a report from your system I currently have to change the file type and the formatting on several columns before I upload it into our accounting system. I would like the ability to map the output one time.”

Once you have collected a few of those, you have the foundation for a to-do list for your product, or a backlog. Make sure to set up separate opportunities to include the voice of the employee. The output will be a list of CTQs, or critical to quality features, which are the must-have elements that support the customer experience.

Create your backlog and get grooming

This list of external and internal CTQs will serve as your initial product backlog. Based on my recommended approach, it is not likely to be filled with exciting new features and experiences, but it will get you started with a list of elements that your clients and employees deem important to their experience. Control metrics confirm that the enhancements or additions provide the intended outcome or experience. For example, if your team anticipates fewer inbound client calls as the result of a new algorithm, make sure that you measure and track the number of inbound calls and that the metric is in place before accepting the new feature. Completing the work is not enough, proving that it provided the anticipated value from the perspective of the user is the true goal. This is where the majority of enhancement initiatives fail – when success is measured as an item ticked off of a project list instead of as value provided to the business.

Do what you do

From this point and on, product owner duties are well defined – estimate and prioritize your list of experiences, making sure that the list is prioritized in terms of overall value to the business. Help internal and external users define their needs, and encourage the organization to add some unexpected and exciting items to the list. The best part, is that you are part of a service organization, and we know how to get things done quickly and efficiently – just doing what we do.