Product Owners Maximizing Value

The Product Owner is responsible for maximizing the value of the work done. Check out this list of responsibilities from the Scrum Guide (2013):

• Clearly expressing Product Backlog items;
  
• Ordering the items in the Product Backlog to best achieve goals and missions;
  
• Optimizing the value of the work the Development Team performs;
  
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
  the Scrum Team will work on next; and,
  
• Ensuring the Development Team understands items in the Product Backlog to the level
  needed. 
  

Optimizing value is a funny thing to think about when does "value" even mean?  

To an industrial-age mindset, "Value" correlates to "Output."  If I make seventeen yachts, I have more to sell, and then potentially make more money than if I have three. 

If I have twenty features or stories or jobs done, then theoretically I make more money, and thereby have maximized value. 

This is doubly-strongly reinforced when you are hiring staff augmentation to create a pre-planned feature set which was determined (complete with end date) before the contract took effect. It seems clearly that "reaching the milestones" and "getting the most for our contracting dollar" are maximizing value. 

The role of the Product Owner must be, therefore, to wring the maximum output from the developers on the teams assigned to his/her product. 

Except that it doesn't work that way in software, and that wasn't what was intended. 

Given a development team with its current skills, headcount, tools, and process, you will get a more or less the same amount of output per any given period. The only way that you can change that number is to change the factors that go into it. New, useful skills will allow more to be done. New, useful tools will allow more work. Useful knowledge will increase speed sometimes. Reducing the causes of friction, wait states, and other wastes can speed the process. 

However, all of these are things a PO is not allowed to do in scrum. Remember:

• "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality" -- The Scrum Guide 2103
  

It sounds to me like the team can't be driven into practices or demanded to violate sustainable pace or any such thing by the PO.

The PO has no mechanism to maximize output. 

So how is the PO to "optimize value?" 

It seems that the trick is to divorce "value" from "output." It's not HOW MUCH, because that's governed separately, but HOW MUCH DIFFERENCE IT MAKES to the users.  In other words, it is by considering outcomes instead of outputs.

If we only have 13 idea days or 13 story points or 13 gummy bears to work from this sprint, then what is the best 13 we can work on? What will teach us the most? What do we need feedback about soonest? What will 

• Ordering the items in the Product Backlog to best achieve goals and missions;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
  the Scrum Team will work on next;

From here, we can look at thin slicing, story mapping, and options .. but I leave that as an exercise for the graduate student.

But the take-away here is that the PO isn't to drive the team to maximum output (he's not the Development Team Owner), and lacking that ability the PO instead steers the product to the best outcome possible given that the outputs are going to be roughly the same.

A secondary take-away to consider, though: shouldn't the PO leave enough capacity unclaimed to allow the development team to improve their tools, knowledge, skills, and process so that perhaps more output might become possible in the near future?