Why is Product Ownership/Management so hard?

A common problem I see time and again across development teams, organizations, and industries is difficulty with the Product Owner role or Product Management in general. How is it that team’s struggle in this area so often? Why can we find quality Scrum Masters, Software Engineers, and QA Engineers easily, yet the great product person is as rare as a Straight Flush in a hand of poker?

One can look to the books we have to teach the various roles. Amazon returns over 60,000 results on both Computer Programming and Quality Assurance, yet only around 4,000 books on Product Ownership. While not exactly a scientific method, it is indicitive of the market supply and demand for such topics.

But let’s take this a step further. Software Engineers, when they have a college degree, often have a degree in Computer Science, Mathematics, Software Engineering, or Informatics. Yet what degrees exist in traditional universities for Product Management? Carnegie Melon, University of Wisconsin, and New York University all offer a Masters in Product Management from their business school, but there does not appear to be any bachelor degrees for Product Management. This leads to a disparity in skills. While Software Engineers often have years of training before joining a team to write code, many Product Owners learn on the job, being mentored by those who have cleared a small path before them.

There are certifications available, like those for a Scrum Master, such as the Certified Product Owner, that provides a general introduction to product ownership, including writing stories, prioritize a backlog, and how to plan a sprint with a Scrum team. There are also training courses like Pragmatic Marketing, which provide more advanced training and a framework around discovering needs, crafting a plan, executing, and releasing a product.

And while these trainings can help a Product Owner get up to speed on their role, the simple matter is that the Product role requires heavy reliance of soft skills and influence. Technical skills, such as the steps needed to write an automated test, are simpler to learn in comparision. While one is crafting an automated test, they can refer to notes on the subject until they have mastered the steps, yet a Product Owner might get a sideways glance if they bring notes to a backlog refinement session, a meeting with a stake holder, or a sprint planning.

Your traditional training tries to assuage this by going through “simulations” in order to give Product Owners a feel for the job. And this is a good approach, but it is just once, must be done in a group, and the pace of most clasees allows little time for reflection.

But dedicated practice and exercises are a great way to build product skills and confidence. The first challenge is finding time to practice. I personally find Friday afternoons at the quietest time of the week. A couple hours after lunch are a good time to set aside to learn and practice.

The second dificulty then is how do you practice product ownership? Hear are a few exercises you can try to practice writing stories, defining acceptance criteria, and prioritizing a backlog. There’s more to product ownership than this, but this provides a good foundation for the rest of the skills.

Product Ownership Exercise

First, identify a software product or feature you use everyday, such as the latest Facebook feature, a “Pizza Tracker” for a pizza shop, or your Out-of-Office feature of an electronic calendar.

  • what is your vision of what this product or feature will be?
  • What stories do you need to implement this product or feature?
  • What would you name the feature?
  • What description for hte user stories?
  • What acceptance criteria would you identify?
  • Finally, what order would you want to implement these stories so that you can maximize value delivered?

For the purposes of this exercise, ignore any technical implementation details, technical dependencies, and ignore any technical concerns in terms of priority order. It’s the responsibility of the development team to serfuace these, which you would normally uncover when refining, estimating, and/or planning these stories with the team.

As a bonus exercise, find a peer, each choose the same product and feature, and independently build your product backlogs. When complete, compare your backlogs and discuss how you each choose to write the stories and prioritize them. What simularities did you have? What vision did you have when creating your backlog, and how do your product visions differ and did these differences lead you to different backlogs?