At the Agile Open Conference in Northern California, I was inspired by the Open Space forum to share and learn from those gathered about product ownership. As a software project manager, I’m tasked with helping define, facilitate and participate in product ownership roles. One of the biggest challenges I face is also part of the thrill in working with a consultancy: there are many active projects and each one is unique. So in this session, I asked "How could we define, assess and begin executing the product ownership role in three meetings?"
What is a Product Owner?
We started by looking at what it takes to be an effective Product Owner? There’s a lot to be said here; we kept coming back to a few key qualities and skills.
Qualities
- They have vision. Of the product, its context, and where it’s going.
- They know the users: what they do and how they do it. Also, what they need, want and should have.
- They have authority to make decisions about the product, and where to spend budget.
- They’re available for day to day work, and for larger planning.
A lot of discussion focused on the problem space vs. solution space. Whereas developers and project managers are primarily working in the solution space, product owners need to come from the problem space.
- They love and know the problem space.
- They’re open and willing to evaluate many possible solutions.
Skills
We differentiated skills from qualities because skills can be more easily taught and learned.
- Writing user stories
- Working in vertical slices
- Breaking work into measurable, small chunks
- Prioritization
- Negotiation
- Knowing when to say “No”
Getting Started with Product Ownership
So, we revealed a group of qualities and skills crucial to good product ownership. All of these are used to do the work. What surprised me about our discussion was how helpful it was to think about assessing, teaching, learning, and executing with these tools in mind.
Everyone brings different skills and qualities to a project. My job as a manager is to make sure a team has the right tools and processes in place so the team can focus on the work at hand. If the team is missing qualities and skills from above, I want to identify that early-on and bring in support. For example, we could clarify and adjust the approval process so a customer has appropriate authority. Or, we could do some education around user story creation to build a common language.
At every stage in a project, we can foster these qualities, improve skills and use tools to increase productivity and efficiency. I came away from this session seeing my own strengths and weaknesses in a new light, thinking about how I could improve my skills and nurture qualities in my daily work.
The Three Meetings
I’ll admit that three meetings were a bit arbitrary, likely inspired by the universal ‘rule of three’. But, many early conversations in my projects follow this pattern:
- Introduction (Why)
- Discover (What)
- Kickoff (How)
This is great because it starts in the problem space and ends in the solution space. Obviously, there could be a lot of work in the ‘middle part’. And not for a second do I think that all discovery can fit in one meeting. But this framework could establish an iterative process defining the problem, and launch an effort to solve it. It’s easy to imagine these as as phases rather than meetings, to support larger scopes of work.
So we mapped the qualities and skills gathered to the three meetings. What resulted is an interesting breakdown of assessment tools, discussion points, dependencies, and teaching opportunities around these skills and qualities.
With such an open-ended discussion, it was impossible to talk clearly about specific strategies. But we bounced a lot of ideas around together. And I realized that the idea of mapping product ownership skills and qualities to a series of meetings could be extremely helpful in the work that I do. It also made me think about my own learning and teaching opportunities.
A few other items we identified were key deliverables that would support product ownership and the project:
- Problem Statement (Framing Document)
- Acceptance Criteria (I consider this included in a complete user story)
- Roadmap
These would presumably be developed, and evolve over time. They’re just a few key deliverables found in a development project.
From 0 to 60?
Did we get up to speed? I’d say we got rolling and came away with a lot to think about. Product owners have a hard job. It takes skill, knowledge, diplomacy and grit to perform well as a product owner. It’s a discipline of its own, worthy of thousands of hours of practice. While this article could only scratch the surface, I hope a novel approach may inspire some new or helpful ways of thinking about product ownership.
Thanks to the organizers of AgileOpen and especially to all the participants who shared their time and knowledge including my colleague Jay Gonzales (who also took the board photo).
About the Author
Jules Bowie is passionate about collaboration, creativity and technology. He brings experience in computer science, design and production to support his work as a Project Manager at Beezwax. He’s a Certified ScrumMaster professional.