One Expert, One Topic — Lance Dacy Talks Product Ownership

One Expert, One Topic — Lance Dacy Talks Product Ownership

  • Post author:
  • Post category:
    guru

Not only did Dallas native Lance Dacy train me to become a Certified Scrum Product Owner (CSPO), he helped me train some of the smartest research cryptographers in the world to become CSPOs. Together, we trained over 60 scientists in Santa Monica, Seoul, and Bogota on the essence of agile product development. Thanks to his training, we could create a decentralized organization that had focus, structure, velocity, and freedom.  

Lance has been in the tech world since 2004, embracing agile methodologies since 2008. He’s not just teaching agile as a Certified Scrum Trainer; he’s living it as the Product Owner of a software that’s been making waves since 2009. Ever the learner, he’s broadened his expertise with a Master’s in Data Science from SMU, diving into analytics and AI to bring real-world solutions to clients.

As a Certified Scrum Professional – Product Owner, he’s helped numerous clients scale their product management processes. As Senior Director of Global Product Operations at a major company he has managed  a diverse portfolio of 52 products. There, he spearheaded the creation of an agile roadmap planning process, integrating it seamlessly with Scrum and other agile methodologies within the Product Development organization.

On a personal note, Lance has been married for over 25 years and is a father to four boys. He also enjoys playing the piano and writing music, showcasing his creative side. He lives by the motto, “if you aren’t servicing our customers directly, you better be servicing someone who is,” reflecting his commitment to agile principles.

About The Series

This is the fourth installment in the “One Expert, One Topic ” series, where field experts select a topic and share essential insights using Matt Abrahams’ What/So-What/Now-What format. Presented in written form, it allows you more time to absorb the topic and guides you on where to go for further learning. Writing is both challenging and time-consuming; we are grateful to our contributors for sharing their wisdom in this format. 

What

What should we call your position? Product Manager, Product Owner, perhaps both? 

We often think of the Product Manager (PdM) and Product Owner (PO) as interchangeable positions; especially in the world of agile product development. Both roles share a common goal of delivering high-quality products that meet customer needs, making them seem similar. 

A Product Owner is a term born solely in the agile framework of Scrum created in the late 1980’s and made formal in the mid 1990’s. 

The Product Manager term has its roots in the 1930’s from Procter & Gamble (P&G) through a memo written by Neil H. McElroy who later became P&G’s president. McElroy’s memo proposed the creation of a new role to manage individual products, which was a novel idea at the time. This role was designed to be responsible for overseeing all aspects of a product’s lifecycle, from development to sales and marketing. 

So What

It is important to those of us who actively practice agile product development to make sure that people understand the delineation of responsibilities and authorities. Most agile frameworks have some form of rules about roles. Usually, there is a natural tension built-in between the roles (specifically in Scrum between the Product Owner, Scrum Master, and Developers). 

If we don’t pay attention to the roles and constraints, we likely end up stuck and blaming the process itself for not working (much like coming to the conclusion that a Ferrari is a terrible car because you only drove it on a gravel road). We must learn to seek the constraints of a process so we can properly apply the rules. On a healthy eating plan, avoiding sugar is a constraint. What happens if I don’t follow that constraint?  

In reality, I don’t think the term Product Manager is quite as controversial as Product Owner. I believe the “Product Owner” has garnered criticism and discomfort within the product management and development communities alike for several reasons:

  • Implies Sole Decision-Maker: The term suggests that a single individual has complete authority and ownership over the product, which can be misleading (or threatening to leaders) in environments that thrive on collaboration and collective decision-making. This perception can create tension within teams, especially in settings where input from various stakeholders is crucial for a product’s success.
  • Conflicts with Team Collaboration: Scrum, from which the Product Owner role originates, emphasizes teamwork, shared responsibilities, and collaborative decision-making. The title “Product Owner” might imply a hierarchy or silo that conflicts with the spirit of collaboration and cross-functional teamwork that agile promotes; really this is just an education problem.
  • Limited Scope Perception: Some believe that the title “Product Owner” suggests a focus only on the delivery or operational side of product development, potentially neglecting the strategic, market-facing responsibilities that are often associated with product management. This can lead to confusion about the role’s scope and the expectation that product strategy and vision are outside the Product Owner’s purview.
  • Vagueness and Misinterpretation: The term can be vague and subject to interpretation, leading to differing expectations among team members and stakeholders. For instance, some might expect the Product Owner to be deeply involved in technical decisions, while others might see them primarily as a liaison between the development team and the business or customers.
  • Global Applicability Issues: In some cultures and languages, the direct translation or implication of “ownership” might not carry the intended meaning or might be difficult to convey accurately. This can lead to misunderstandings about the role’s responsibilities and authority level, especially in global teams.

So what does Scrum say about the Product Owner role (https://scrumguides.org/scrum-guide.html)?

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

  • Developing and explicitly communicating the Product Goal;
  • Creating and clearly communicating Product Backlog items;
  • Ordering Product Backlog items; and,
  • Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”

Now the real problem. Most of the reasons I listed why people take issue with the Product Owner role are actually true! The Product Owner:

  • Is the Sole Decision-Maker: The Product Owner is one person with a single voice to the developers that represents the stakeholders in the process. They must collaborate with developers and stakeholders alike, but act as a single voice to avoid confusion and misdirection of the work.
  • Is a Team Collaborator: While some may think of the “Owner” word to be definitive, it is necessary to imply authority. The Product Owner must collaborate with all facets of the organization to succeed, but they have the sole authority to make decisions on the priorities of the work and are subject to the criticism of their mistakes as they go.
  • Is Not Limited the Operational Side of Development: They are responsible for the entire “Go To Market” strategy of the product and must collaborate with Sales, Marketing, and Support to reach their ultimate goal of creating, developing, delivering, and supporting great products as assigned by the organization.

Once we dive into these nuances, I think we start to see the lines blurring between the two titles of Product Manager and Product Owner. In the trainings I offer with Scrum, I often represent a venn diagram showcasing a balance of successful characteristics of a Product Owner: 

  • Authority to make the decision and empowered to follow through
  • Availability to collaborate with stakeholders and developers 
  • Knowledge to understand the business problems that need solved in the market

Why is it important to ensure these roles are enacted as intended? Ignoring or misunderstanding the role of the Product Owner can lead to several negative consequences for product development teams and the organization as a whole, especially in agile environments where the Product Owner role is more prevalent.

  • Lack of Clear Vision and Direction: Without a clear understanding of the Product Owner’s role in conveying the product vision and priorities, teams can suffer from a lack of direction. This can result in features that don’t align with user needs or business goals, potentially leading to a product that fails to meet market expectations. Teams that think of a Product Owner only as an operational capacity are at greater risk of this issue.
  • Poor Product Backlog Management: The Product Owner is responsible for prioritizing the product backlog to ensure that the team works on the most valuable features first. Misunderstanding this role can lead to a disorganized or poorly prioritized backlog, causing the development team to focus on less important tasks and thus delaying the delivery of key features. We are at risk too when this is spread across multiple people or authorities.
  • Reduced Team Efficiency: A well-defined Product Owner role helps streamline decision-making processes by acting as the single point of contact for the development team’s questions about the product. Without this clarity, teams may face delays due to unresolved queries or conflicting directives, reducing overall efficiency and productivity.
  • Weakened Stakeholder Alignment: The Product Owner acts as a liaison between the development team and stakeholders, including customers, business executives, and others. Ignoring or misunderstanding this bridging function can lead to misalignment between stakeholder expectations and the product development efforts, risking stakeholder dissatisfaction and reduced support for the project.
  • Decreased Product Quality and User Satisfaction: A key aspect of the Product Owner’s role is to ensure that the product meets user needs and delivers value. Misunderstanding or undervaluing this role can compromise the focus on user experience and quality, potentially resulting in a product that fails to satisfy users or solve their problems effectively.
  • Increased Risk of Product Failure: Collectively, the consequences of not properly understanding or fulfilling the Product Owner role can increase the risk of project failure. This can manifest as products that are over budget, behind schedule, misaligned with market needs, or inferior in quality, any of which can have significant negative implications for the organization’s reputation and financial health.

Education is really the key to helping your teams and organizations understand the title of the roles. I think we can demonstrate that the role of a Product Manager and Product Owner are essentially the same. In fact, Jeff Sutherland, the creator of Scrum has said that a Product Owner is a Product Manager; they just didn’t want any Scrum role to have the word “manager” in their description given the consequences of the term manager as it relates to organizations. 

Now What

Knowing that these roles are essentially the same, I think the real problem occurs at scale. 

Product Owner’s in Scrum are one of the first roles to start cracking under the pressure of a large product development organization. The demands for their time become unmanageable. As such, we need to learn how to scale the role for the work to continue. The good news is that we have an out as described in the Scrum Guide: 

– “The Product Owner may do the above work or may delegate the responsibility to others.”

An option at scale is to have a Product Manager, Product Owner, and perhaps Developer role like an Analyst who all serve the needs of the product management collective. This is where the Product Manager role could start tackling more of the forward thinking responsibilities of the product (3-5 years out, working with trade shows, marketing, sales, and customers). While the Product Owner focuses on the near-term execution of the roadmap 1-3 quarters out with designers and user researchers as we build out the product, and Analysts assist in creating the requirements and backlog; trying to understand the domain of the users and interviewing them to become better equipped at describing the needs (the “what”) to the developers. 

Another scaling option is to create a Chief Product Owner, Product Line Owners, and Product Owner. This eliminates the title Product Managers all together, but once again takes the collective of responsibilities and scatters them to each of these roles. Think of Microsoft Office, you might have the Chief Product Owner of Office Suite, Product Line Owners for Word, Powerpoint, Excel, One Note, etc…and then Product Owners for the features of those products as needed at scale. We could have 2,000 development teams working on this one product. It becomes more important to think of how to manage the roles and work at scale. 

Every organization is unique in how they work, but usually their problems are not unique. Work to apply what works best for your organization utilizing education to explore and experiment with ideas. 

For those looking to deepen their understanding of Product Management and the Product Owner role, a variety of resources are available, ranging from books and online courses to podcasts and professional organizations. 

Here’s a selection of resources that can provide valuable insights and guidance:

Books

Online Courses

  • Big Agile – We offer Certified Scrum Product Owner and Advanced Certified Scrum Product Owner courses to tackle many of the issues facing this topic.
  • Coursera and edX – Offer courses from universities and institutions on product management and Agile methodologies, including the role of the Product Owner.
  • Udemy and Pluralsight – Provide practical, skill-based courses taught by industry professionals on both Product Management and Agile practices.
  • Pragmatic Marketing – A deep dive into the tactical ways to work within all confines of the organization to achieve business agility and great products.

Podcasts

  • This is Product Management” – Features interviews with product management professionals and covers a wide range of topics.
  • Masters of Scale” by Reid Hoffman – While not exclusively about product management, it offers valuable insights into scaling products and companies.
  • The Product Podcast” by Product School – Shares stories and advice from real-life product managers in leading tech companies.

Websites and Blogs

  • Mind the Product – An online community and blog that provides articles, resources, and events for product managers.
  • Product Coalition – A medium publication that hosts a wide range of articles on product management and design.
  • SVPG Blog – The Silicon Valley Product Group, led by Marty Cagan, offers deep insights into product management best practices.

Professional Organizations and Meetups

  • ProductCamp – An unconference where product professionals network and learn from each other.
  • Meetup.com – Offers local and virtual meetups for product managers and Agile enthusiasts.
  • Product Management Festival – An international event that brings together product professionals for workshops and networking.`