Great product owners don't count on miracles

As a CTO or Director of a game studio, one of my principles was to hire the best people possible (the most talented and committed) and trust them to do their job. 

This always got the job done, but at a cost.  Those talented people showed their commitment by working grueling long hours and wasting weeks of effort.  I'd given them plenty of rope to hang themselves from and they used it.  I expected miracles as part of planning process.

When we started using Scrum, one of the biggest challenges was the product owner role.  Casting an existing role, like a lead designer, into it wasn't enough.  The transition of thought, from executing on a detailed plan, to iterating with a critical eye on emergent value, doesn't happen overnight. 

At first, we iterated on a fixed and detailed plan.  This led to a phenomenon, described in my book, (chapter 12, Agile Design) called "parts on the garage floor".  In doing this, we produced separate polished parts of a mechanic.  However, the value of the mechanic didn't prove itself until all those parts were integrated together in a production level and demonstrated.  By the time this happened, if the value emerging wasn't good enough, it was too late to do anything about it.

The art of great product ownership requires a different mindset:

• Product owners have to trust the team to do miraculous things within a sprint, but not count on miracles beyond that.
• Product owners should not fall in love with their vision.  The must take the truth from the working game and use it to "true up" their vision.
• Product owners should demand value be added every sprint.
• Product owners must be honest and transparent with the team.  Even when it hurts.
• Product owners must take council from their domain experts and prioritize based on cost and risk as well as value.

The last point was crucial to my role as the CTO-who-depended-on-miracles.  Although I couldn't create these miracles, I certainly could foresee where they were needed.  I knew where the risks usually lay (when you are burned enough times, you eventually figure out that fire is hot).  The knowledge of risk was applied to the order of the backlog.  For example if porting our engine to the next generation platform is a major risk, we should do something about it earlier than later.  Then we won't need the miracle.

It's important for the product owner to understand risk and use it to prioritize the backlog. They are responsible for the direction of the project outside the sprints.  They have their hands on the steering wheel of the project and need to steer it in the right direction.