« On Losing| Main | Starship Enterprise Coming Next Year »

My Product Owner is a Robot

| | Comments (0)
robot
But I don't argue with him that much...


So a while back I was exposed to two agile teams that were building their own product owner robots. You know how it is, you need a product owner, of course, and sometimes there just isn't one around.

One of these teams I think is going to succeed, while another will struggle. I'll describe both teams and you can see if you make the same call. Then some commentary.

Team 1: Making you a better person: This team is chartered with taking an employee list of tens of thousands and making them better. More specifically, there are behaviors that management would like to see in it's new managers, and this team is charged with developing and implementing some sort of intervention to help the managers of tomorrow.

Their problem is that upper-level management says all kinds of things about what good managers should be. In addition, there is a plethora of industry material on what makes good managers. On top of that, seems like every other business consultant has some kind of program guaranteed to make better managers. There isn't a wrong or right answer, and the team is charged with determining how to take all of this input and make something useful out of it.

In order to accomplish this, Team 1 built a robot. The robot is a process that takes all the leadership phrases possible and condenses them into a bulleted list of how we would like future managers to behave. These future behaviors are then ranked -- what behaviors are most needed and what are least needed? This becomes a strategic backlog. The team then creates "interventions" -- courses, webinars, etc -- that are supposed to promote this future behavior.

The problem with Team 1's system is that everything is fuzzy. What's a "better manager"? Exactly what is the state of the managers in the organization, and how do we know we made a difference?


Team 2: Building Stuff the Big Enterprise Needs Next Year: This team works in BigCorp, where there are a lot of players and a lot of projects going on. They need to plan for the architecture of the future, making compromises between all the players.

Their problem is that BigCorp has a lot of players with a lot of different interests. Once again, messages and needs come from everywhere and they can't all happen at the same time. Heck, some of the things are in contradiction of each other. Team 2 is responsible for determining how to balance these needs, since the expert knowledge of needs balancing is only found in the team.

Team 2 created an architectural robot. Groups and subgroups have representatives that vote on structure items submitted into a list. Items with the highest vote are put forward. An item might be "install server cluster for DB2 into production" or "install SAS environment for test", or "Provide High Availability". Items can be of any size.

Because items can be of any size, it's not always clear to voters the _real_ choices they are making. Does voting this item to spot #1 mean the entire first half of the year is taken up delivering? Inter-relations are also not evident -- item #1 may be impossible to do without first doing item #7 and item #39. Does that then mean those items are also #1? What if item #39 is labor-intensive? The voters have no clear idea of what types of decisions they are making.

In addition, the feedback loop is loose and/or missing. How do I know what item #1 really means?

Finally, the list easily grows completely out of control. With such a huge list, it is not easy to talk about all of the items at one time without taking several hours.



We see these behaviors all the time, don't we? Startup companies use some kind of system for determining what people want. A recent posting on HackerNews talked about using AdWords as a way to determine product need.

So which team will fly, and which will struggle? I'll post tomorrow with the results.

Leave a comment

About this Entry

This page contains a single entry by Daniel published on November 12, 2008 2:22 PM.

On Losing was the previous entry in this blog.

Starship Enterprise Coming Next Year is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.23-en
Daniel Markham