The Price of Poor Product Ownership: 3 Ways to Doom Your Agile Project

Being an Agile product owner is a difficult endeavor. In fact, I would venture to say it may very well be the hardest and most critical product owner role on an Agile project. You have to keep the team happy and engaged, stakeholders are constantly looking for “status” updates, and you need to appease the customer by understanding their needs and delivering high value as quickly as possible.

I’ve witnessed many unpleasant Agile projects, even to the point of a project’s complete failure, because of poor Product Ownership, despite using a proper agile framework. There are a variety of reasons for that, but I’m seeing a trend of Product Owners spending their time in the wrong places.

Here are 3 ways product owners are dooming their own projects, and key advice to turning the tables on these bad habits:

1. Interrupting Daily Scrums

Disrupting the Daily Scrum to task check or to get a status update causes a negative reaction on self-organization, a key component of team problem solving. So does pushing and pulling user stories on or off the Sprint Backlog at will. Remember that the development team owns the Sprint Backlog. Allow the ScrumMaster to be the team’s Sprint Backlog shepherd and leave it alone!

A happy team trusts their product owner, and the best way to gain trust is by listening to the team and being authentic. Remember to be available when they need you, check in (don’t check up), give credit where credit is due, and encourage working at a sustainable pace. Lastly, celebrate successes and have fun from time to time!

2. Focusing on the Wrong Metrics

Metrics, when used appropriately, can be great tools to appease stakeholders. Agile metrics, however, are often misunderstood.

The misuse of velocity has been at the heart of miserable teams and stakeholders on more projects than I want to admit. Velocity isn’t an evaluation metric, it’s a predictive measurement and should be used to forecast your future, not scorn or reward a team. There’s also no way to normalize velocity, so it’s misleading to present velocity to stakeholders in a way that suggests otherwise.

Instead, keep stakeholders happy and engaged by simply being cognizant of them and providing them with what they need while not hurting the development team. In general, transparency cures all ailments and showing progress in the form of working demos is the best visual progression of your software.

3. Forgetting to Involve Customers (Early & Often)

With so many day-to-day commitments to the team and stakeholders, a product owner can forget who they’re building the product for. Product owners who make long-term assumptions about what their customers want tread in dangerous territory. So if you aren’t measuring the outcome of your ideas, a project can make it to completion without any indication of real market value.

You can avoid that mess simply by getting working software in a customer’s hands quickly and gathering feedback, or studying the use of a new feature.

Your users are your customers, and in some cases your product is a revenue generator. You want user feedback and need to validate any assumptions that you’ve made early and often. Act-Learn-Build is a philosophy often adopted in the Lean community that will prevent you from crossing the finish line without any real understanding of your users, thereby leading to a better final product. The end goal is to produce a product that customers love, of course, so keep validation top of mind as you develop it and validate assumptions by releasing early and often.

Poor product ownership, if not addressed early on, will diminish product value. That translates to disappointed users, unhappy teams, and dissatisfied stakeholders. Nip bad habits in the bud and experience more successful product development on your next project by remembering what your job really requires.