The Product Owner Is Your Best Customer, a PM Learns

Project Management Lesson Learned: The Product Owner Is Your Best Customer

In Scrum, the product owner is responsible for writing customer-centric user stories, and other items, prioritizing them, and making sure they get added to the backlog. It’s important for every company to listen to the voice of the customer, but some may also forget that it’s equally important to listen to the product owner. Hala Saleh, an Agile Coach and Project Management Consultant learned this the hard way. Below, she tells the story of an important lesson she learned about the role of the product owner.

Two Wrongs Don’t Make a Right

By Hala Saleh, CSM, PMP

As Project Managers, we can sometimes lose sight of who our customers really are.

We often work on projects for which there is a customer for whom we are building a product or service; in many cases referred to as an end-user. We spend hours, perhaps even days trying to gain insight into our end-users and their needs, creating personas to represent them, and telling ourselves stories about their lives. We do our best to figure out what end-users want, and even sometimes (for better or worse) do our best to figure out what they “want but don’t yet know that they want.”

As we march our project teams toward the finish line, we naturally start to feel the pressure of delivery, and can fall into counter-productive behaviors.
Let me tell you the story about how I learned – the hard way – to never lose sight of one of my most important customers: the Product Owner.

Once upon a time, there was a project team that was brought in to prove out a technology, and build functionality for an end-user that was thirsty for a solution to their problem. The team was challenged to prove that they could deliver functionality early and often, which was probably where things started to go wrong. This challenge to deliver created a disproportionate focus on throughput and velocity, therefore setting us up for a disconnect with some of our stakeholders.

In addition to the slightly maniacal focus on Deliver! Deliver! Deliver!, we had a product owner who had a pretty overwhelming load, and was not always as available to us. Simply put, our product owner sometimes didn’t “show up” for weeks at a time. This caused much frustration on our part, but even worse, it caused us to think that we could make decisions on behalf of our product owner.

“Oh no you didn’t!”, you say?

Oh yes, we did.

At one point, we were in a situation where we had been going back and forth on the right way to release some functionality to a pilot group of users, and we ended up in open-ended land, where there was no real decision on many of the questions we had.

On top of all this vagueness, please add a dash of no response from our product owner on whether we go ahead and release, or not.

I was left with a development team that was ready to release functionality and start a pilot, and a product owner who wasn’t making decisions “on time”. So I did what any democratic leader would do; I consulted my developers and the project manager on the client’s side, and we all agreed that the functionality was ready and tested, and that we had given enough prior notice to our product owner. So, naturally, we decided to go ahead and schedule the pilot functionality to be released, and I would take on the job of sending an email to inform our product owner of the plan, and ask if he had “any concerns”.

What do you think his response was?

Since I have no interest in rubbing additional salt into that wound, I will keep it succinct and tell you this much: he had concerns.

We had totally gone over his head and made a decision that wasn’t ours to make.

We had forgotten one of our most important customers, and had made a grave mistake by assuming we had taken everything into consideration before deciding to move forward with releasing the pilot.

I had failed as a project manager, and had done a disservice both to my team as well as my stakeholder. The good news was that we were able to quickly go back and stop the presses. We avoided making complete fools of ourselves by not releasing the code, but we were still wrong.

Was it wrong for our product owner to be disengaged and unavailable? Of course it was. However, this did not justify our attempts at hijacking the process in the spirit of making progress and delivering. Our issues with our product owner should have been resolved much earlier on in the project, in order to ensure our success as a team.

Personally, my approach with this type of situation is to own up to it. I quickly went back and apologized, but that was not enough. I also explained in detail what we had done wrong and demonstrated my understanding of why it was wrong.

Lesson Learned: Never lose sight of who your customers are. Your product owner is the formal customer representative, and has a role in the project that must be respected.

Hala Saleh describes herself as a Project Excellence Passionista and Agile Enthusiast. A certified Scrum Master, Agile Coach and Project/Program Manager, she is passionate about helping project teams and individuals achieve their true potential, and realize success. She is also the co-host of #PMChat, a weekly Twitter chat which takes place every Friday from Noon to 1 p.m. EST.

Hala Saleh, CSM, PMP
Twitter: @HalaSaleh1

We would love to hear about lessons you have learned from working in project management. If you have a story you would like to share, please send them to kim[at]onedesk[dot]com.

Scroll to Top