Product Ownership

Ealden Escañan
Ealden Escañan
Published in
3 min readMay 22, 2017

--

Listening to feedback (I think) at the 2017 Odd-e Gathering in Singapore

Lately, I’ve come to really appreciate good product ownership. I’ve been involved with product development teams with really good Product Owners, and I thought it would be useful to share my observations on what made them good at what they do.

They Owned the Product

Scrum makes ownership of a product explicit through the Product Owner role. Thus, the person who ultimately decides and who has access to the funding, is involved closely with product development. This allows them to direct product development better, while owning the outcomes from it.

Our Product Owner made decisions when we needed him to. A big part of this was understanding what was important, especially what was important now. He was very knowledgable in the industry we operated in, articulating the challenges our customers faced. That gave us direction as a team.

They Trusted the (Development) Team

Product Owners usually come from the business side of the organization, not from technology. I see this as it is much easier to teach business people Scrum, than to teach technology people about the intricacies of the business. It also lets the Development Team do ALL the work, as the Development Team is equipped with all the skills necessary to do product development.

Since we, the Development Team, knew more about the technical aspect of product development, our Product Owner spent his time on framing the challenge and letting us solve them. It was always a conversation, and through these conversations we were able to find the best solutions for our customers.

This also freed up our Product Owner to spend more time with our customers and on the direction of the product, rather than on work that could be done by the Development Team such as documenting features, testing functionality, and the like.

Finally, we spent a fair amount of time talking directly to the customers, rather than having the Product Owner act as an in-between. Not only did we free up more of our Product Owner’s time, we were able to see how the work we did made a positive impact to our customers — very rewarding for the Development Team.

They Invested to Learn

Product development is really about learning what we need to do, and learning how we can build them better. Sometimes we get things right, and sometimes we learn what we could do better. This is the nature of innovation, as we are doing things that may have never been done before.

Our Product Owner understood this well. We treated our features as assumptions rather than definitive truths, and thus tried to validate them as soon as possible. We celebrated when we got things right, and took ownership when we could do better.

It helped that we could deliver at will, so we could easily validate our assumptions and adjust accordingly as soon as possible.

The Product Owner and the Development Team form two sides of the same coin: the former focuses on building the right thing, and the latter focuses on building things right. Both roles must interact, to find the best next step forward, and to validate this by working directly and iteratively with the customer.

And the Scrum Master? He ensures that the interaction exists, and not get in the way ;)

--

--