Product Owners Hold the Keys to Project Success

In this presentation, projekt202 Vice President of Technology Paul Tidwell explains why the product owner holds the keys to success and how companies can best support them to ensure outstanding project ROI.

WATCH THE VIDEO NOW. A TRANSCRIPT ALSO FOLLOWS BELOW:

Hi, my name is Paul Tidwell, and I am the National Practice Lead for Technology at projekt202.

Today I’d like to talk a little bit about the product owner, the critical path to success.

As companies begin their agile transformations, they eventually have to find a responsible product owner. Often, the product owner becomes the linchpin for success on a project, for better or worse.

Often the PO is named but not trained. Often the PO is not relieved of their old duties. Often the PO lacks seniority or lacks authority.

These can all be critical flaws to the downfall of a project. We’ll talk a little bit about how these challenges can be overcome to yield better outcomes for the product owner.

So what do they do? They set priorities in the backlog. Their job is to basically decide what’s the number one thing to do, the number two thing to do, and you need a single person to do this because you can’t have more than one number one and more than one number two.

So, if everything’s high priority, then nothing’s high priority.

They also are responsible for author and user stories and acceptance criteria. These are the intersection of the business development and quality assurance teams.

So, acceptance criteria become incredibly important. Their precision yields the outcome of what actually gets built. And if they’re not right, the right thing isn’t built, the right thing isn’t tested and nobody’s happy.

So this part becomes very, very difficult, very, very time consuming, requires some technical expertise, but also a deep understanding of how to deliver business value.

They also represent various stakeholders, often many senior influential people who all want their thing built first.

So, the product owner is the arbiter of what happens next. How do they field all of this input? How do we determine what feedback is valuable when we’re demoing new software?

This often means that they are accountable to people who have more authority than they do and they have to say no to people with seniority within the organization, but they must be empowered to do so.

They also are responsible for translating business value to the backlog. So, understanding how a feature is not just a feature, it imparts value to the business and hopefully connects back to the bottom line, to the objectives of the CFO itself.

Translating this value becomes very important and very difficult. You don’t want to work on something that’s low value but easy just because it’s easy. You need to really confront the things that are going to bring value to the business and prioritize them as such.

They also fuel the builders. The development team gets all of their work, all of their tasking from this backlog, and if there’s not enough fuel there to power the engine, then the developers can become starved, become idled and you have a very expensive resource that’s not being effectively utilized.

So how can they fail? Often, this lack of authority can become very problematic. If a business stakeholder is asking for something that doesn’t really make sense, do they really have the authority to push back and say no?

We recently had a customer looking at a login screen as part of an MVP initiative. They decided the logon screen didn’t look balanced and needed some graphic treatment. When the team pushed back and suggested perhaps this wasn’t MVP functionality, that this page would work perfectly well without that image, the product owner had no authority to push back and not commit the team to work on work that was not part of an MVP flow. And the cost of this is something else later down the road will not get worked on because of the time spent on something that was low value.

Inexperience is also a critical downfall. Most product owners are new at the job. Even though 20 years into agile, there’s just not a lot of seasoned product owners out there since they have an intersection of the ability to do this administrative work in the backlog in whatever application lifecycle management tool you’re using, like Jira, combined with the business understanding and the context for all of these things. So that level of experience takes time to develop.

They struggle, often, with incremental thinking.

So, are you slicing horizontally or vertically?

We once had a client who we were building a credit application and as we were building out the fields, some of the fields didn’t have validation because it was not authored into the acceptance criteria, which is perfectly OK. It’s fine to just go and add that stuff later. Well, during product demos, the stakeholders struggled to understand that you can enter alphanumeric characters into a phone field when everybody knows that a phone field is strictly numeric.

Well, if the acceptance criteria doesn’t say do it, then the developers don’t do it because it might be an intentional decision to do it later. With a phone number, it’s easy to say a developer should just know that those are numeric fields. Well, had it been an international tax ID, you couldn’t say the same thing. So, we must be explicit in these things.

And so, thinking incrementally about whether you’re deferring on validation or basically horizontally or vertically slicing your work to call it done is very, very useful, but all of the stakeholders need to be on the same page.

Prioritization. Everybody wants their stuff done first and often we lack the data to justify what needs to be done in what order.

We have people who have MBOs or experiencing different market pressures or worked for different parts of the organization who would all prioritize things differently, and the product owner is the person who has to coalesce all of that into a single prioritization.

This is where things like field research and contextual inquiries and some sort of market analysis for your competitors can help you drive some empirical information to allow you to understand a true prioritization, and this is something that projekt202 recommends to all of our customers.

Finally, if they fall behind development velocity. If you have a product owner that can’t build enough of a backlog to keep the team busy sprint after sprint after sprint, the team is going to become starved for work, and that’s not an effective outcome. It taints your velocity.

One way to combat this is to allow the product owner time to build out a fairly large backlog of work before even bringing a dev team to bear.

So, it’s important to think about, how can we help them be a success?

Team them up with an architect. They need a technical representative to help them understand dependencies and constraints within the system, so they can’t be solely responsible for all of those complex acceptance criteria without a technical partner. So, just like they’re representing the business, they effectively have a very strong interface with the development team. Especially in that early kind of pre-build of the backlog, technical representation will help them not go down a path with an outcome that can’t be achieved given the technology at hand.

Anoint them with authority. Make sure that they are OK with telling their superiors no, that they are anointed with enough power within the product team to really drive the product to completion and they can’t be second-guessed in this regard. And this also kind of points to the importance of picking the right person for the job who can understand all of these things.

Embrace failure. This becomes a cultural component of the entire organization.

These failures teach us very important things about the solutions that we’re building. And over time it should become more infrequent. But thinking about failure as something that should be penalized begins to demotivate the team and stifle innovation and support the wrong type of metrics for the platform.

Retrospectives and Kaizen. So, continuous improvement is such a critical part of any iterative development cycle or product development life cycle that it has to be kind of built in. Have retrospectives, allow the team to be honest. Don’t invite certain people if people can’t be honest around them. It takes a bit of a soul searching and being able to kind of reveal your weaknesses as a team to successfully improve on those things. And then Kaizen, embrace continuous change.

Finally, give them training and a really substantial head start. If you can implement some of these capabilities, your product owners will be happier and the business will get more of what it needs out of its product development teams.