It's 2019, almost two decades since the agile manifesto. We have thousands of agile teams working in organizations across the world. Yet, many organizations have only managed to create "feature factories." These organizations may have improved their execution agility. Still, they've missed the mark on creating any sense of true organizational agility. They continue to build things few customers want, just much faster! I don't know about you, but that sounds like a big step backward to me.
Culture and resistance to change in large organizations certainly play a part. There's a lot of "agile in name only" out there, and it's certainly a symptom of the lack of real results we see from many large organizations. Today, however, I'd like to suggest that another significant cause stems from a standard piece of advice that we in the agile community have been giving them. Pull Product Owners from the business.
While I understand the benefit of having someone who understands your business domain guiding the prioritization of your backlogs, I've come to realize that this advice is incomplete and inadequate. There are a few things that happen in practice when organizations follow this particular guidance. One problem is that the people we ask to become product owners aren't experienced in the customer-facing parts of the business and are out of touch with customers. Because those front line employees with the best understanding of customer needs are seen as too valuable to business operations, they can't spend time guiding an "IT project." As a result, someone more junior or a manager that no longer directly interacts with customers becomes the product owner.
To make matters worse, organizations tend to assume that putting someone "from the business" on a team or in charge of a product backlog is enough. Maybe they'll send these new product owners to a two-day training class, perhaps not. Even then, those people rarely receive the follow-up support and coaching they need to be successful.
Product Management is a broad, complex discipline to which people working in business operations most of their careers generally don't have much exposure. I’ve seen plenty of people make this transition well, so I’m not saying it’s impossible. What I’ve seen in practice though is that people working in business operations usually don't understand how to perform customer discovery, design experiments to test hypotheses around customer needs, and create a vision for satisfying a customer need. What we're often left with are products looking for a problem to solve rather than products that were designed to solve a problem. It's not good for the organization, and it's not fair to the person we're setting up to fail.
The product owners and managers I've seen be most successful have been individuals with a mixture of experience in the business domain and the discipline of product management. Given a choice between the two, I'd take someone who knows nothing about the business but understands customer discovery and product development any day. Why? Because those are the skills needed to quickly understand what customers are actually asking for. Through a disciplined discovery process, we can find out the real needs of the customer and lean on others in the organization for domain context where needed.
On the other hand, people with a vast knowledge of how the business works and little product management experience tend to drive the development of products that satisfy a narrow set of customer needs. They base their vision for the product entirely on their knowledge and understanding and see very little need for continual customer discovery. When those products come face to face with real customers, they fail.
One group I worked with was developing a new platform for insurance underwriters to create and manage insurance policies. The product manager was a director from the group that had previously spent years as an underwriter. She didn't feel the need to perform customer discovery due to her experience. Instead, she opted to guide the teams building the product based on her expert knowledge of how the system should work.
They spent over nine months developing an MVP based on the experience and preferences of one director. After releasing it to the underwriting group, they realized they'd completely missed the mark, and the MVP they'd developed didn't fit the needs of the group at all. They attempted to salvage the product with a few fast follow on releases, but ultimately scrapped almost 12 months of work for five software development teams and started over.
You're doing a disservice to the people you're asking to serve as product owners and managers if you don't set them up to be successful in these new roles. Setting them up for success starts by providing them with the right training to get them started in an unfamiliar discipline, but it doesn't end there. We also must provide the support needed to learn a new set of skills.
You can’t simply ask your business partners to assign product owners to your teams. You must also provide the support they need to adapt to that role. So how do we help them? Training followed by expert coaching and ongoing mentoring from peers.
This means:
Train new product owners, not just in traditional PO classes offered by agile consultants, but in skills specific to product management as well.
Create a mentoring group. If you have a few good product managers in your organization, create a mentoring group where newer product managers can learn from them.
Get coaching. If you don't have a decent supply of people in your organization who understand product development, bring in an outside expert to help get them started on the right path.