DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Stop Using the ATM-Didn’t-Kill-Jobs Story to Reassure Developers About AI
  • The 7 Pillars of Meeting Design: Transforming Expensive Conversations into Decision Assets
  • How AI Is Transforming Software Engineering and How Developers Can Take Advantage
  • When AI Crashes: Classifying Failure Modes in Safety-Critical Software

Trending

  • Dear Micromanager: Your Distrust Has a Job; It’s Just Not the One You’re Doing
  • Ujorm3: A New Lightweight ORM for JavaBeans and Records
  • Catching Data Perimeter Drift Before It Reaches Production
  • Key Takeaways From Integrating a RAG Application With LangSmith

Do We Really Need a Product Owner?

If you want to maximize value for your customers, yes.

By 
Allan Kelly user avatar
Allan Kelly
·
Jul. 02, 19 · Opinion
Likes (4)
Comment
Save
Tweet
Share
12.3K Views

Join the DZone community and get the full member experience.

Join For Free

This guy could totally be a product owner.

This product owner is quite confident that your team can't, in fact, live without him.

As regular readers might know, I'm working on a book called The Art of Product Ownership to be published by Apress later this year. One of the chapters is entitled "Why have a Product Owner," and a few days ago a bunch of ideas crystallised into what follows...

The aim of the Product Owner is to increase, even maximize, the business value delivered by the team as a whole. The Product Owner does not so much create value themselves as increase the value created by others.

Think of it like this: If the team randomly selected work to do and delivered it to customers, then some value would be created. (For the moment, I'll ignore the scenario where that work detracts from the existing value.) The aim of the PO, though, is to ensure the work done creates more value than a simple random selection. The greater the difference, or delta to use a mathematical term, between random selection and an informed selection the better.

The general hypothesis is that intelligent selection of work by a skilled Product Owner will result in both more value being delivered and an increasing delta between intelligent PO selected work and randomly selected work.

This difference is the value added by a Product Owner, which I like to call the Product Owner Delta.

Now, in real life, work is seldom randomly chosen, so Product Owners are not really competing against random selection. And in some cases, the alternative to a designated Product Owner is someone else: a senior developer, an architect, a manager, or someone else. In such cases, this person is taking on the Product Owner role. They may not have the title, the aptitude, the skills, or official position, but when work is selected by one person they are de facto the Product Owner.

In other cases, the alternative to the PO might be selection by consensus on the team, or a sub-set of the team. Now, it is entirely possible that such a group could outperform a single Product Owner in selecting work, especially is they have market and customer knowledge, some analysis skills, time to do the background research, and so on. And in some cases this works; for example, think of a small start-up staffed by software developers creating software development tools.

However, in some cases, selection by committee might actually be inferior to a random selection. Imagine a team that has never met a customer, argues about what to do, ducks key decisions, and never says No to any request. Its easy to image a dysfunctional selection committee.

There is more to increasing the Product Owner Delta than simply selecting the highest value items. Timely selection can help too. If decisions are not being made, or committees are spending a long time making decisions, then having one person simply make those decisions in an efficient, timely manner can increase the delta.

Time also has another role. Because of cost-of-delay, simply selecting the highest value items at any one point in time does not maximize the value delivered. Time Value Profiles (see Little Book of User Stories or my presentations on value "How much? When?") expose this and need to be another tool in the Product Owner's repertoire.

And of course, the Product Owner Delta is not the only reason to have a Product Owner in the team, but it is probably the main reason.

Further reading

How to Be a Great Product Owner

Software development

Published at DZone with permission of Allan Kelly. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Stop Using the ATM-Didn’t-Kill-Jobs Story to Reassure Developers About AI
  • The 7 Pillars of Meeting Design: Transforming Expensive Conversations into Decision Assets
  • How AI Is Transforming Software Engineering and How Developers Can Take Advantage
  • When AI Crashes: Classifying Failure Modes in Safety-Critical Software

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook