Making someone responsible to be a product owner, might make a development team feel absolved for ‘customery’ things. For a long time my gut feeling has been that the whole team (product owner, developers etcetera) should place themselves in the customers’ shoes. Attending presentations on product ownership in the eXPerience reports track at Agile 2007 confirmed that feeling.
Getting everyone to ‘crawl in the skin of’ their users creates simple to use products that do what they must and no more. Sometimes with amazing, simply beautiful interfaces.
There were presentations by:
- the BBC – Effective product ownership within a multi-component project by Mike Lowery and Marcus Evans,
- Yahoo – Less, Never more; Launching a product with critical features, and no more by Gabrielle Benefield and Scott Gatz, and
- Oxygen Ript (TM): Innovation and Collective Product Ownership by Ken H. Judy and Ilio Krumins-Beens.
The BBC story was on using the time of product owners wisely, I hope to write about that in a separate post.Yahoo’s and Oxygen’s stories are both about strong product ownership, focus on essentials, and last but not least: crawling under the skin of users. In the case of yahoo those were college students, in the case of oxygen women who are planning something, e.g. a home (re-)decoration or a wedding.
Both stories reminded me of ‘The Knowledge Creating Company’ by takeuchi and nonaka (1995). There is a chapter on how Panasonic created the first bread-baking machine. The chief engineer on that project had tried to understand bread baking from reading a book, and failed. Then he went to take lessons with a master baker in an Osaka hotel. He then tried to explain the bread-making and -baking process to his colleagues, and failed. Eventually groups of engineers would do internships with the master baker to get a ‘gut feel’ for breadmaking – this eventually helped them to resolve the myriad of constraints on a breadmaking machine.
Looking through the agile2007 proceedings, the written version of oxygen’s experience report actually mentions the knowledge creating company, I did not see that in the presentation.
If you are interested in product development, and haven’t read the knowledge creating company yet, I strongly recommend you do so. It is not an easy read (quite thorough), but you’ll come back with a more thorough understanding of product development.
The book also has good tips on how to collect knowledge and share it from one project to the next (or at the same time) – collecting and condensing knowledge takes time and concentrated effort – this gives project managers something to do with the spare time they get once their teams start to self-organise…