When asking product managers on the main principles of agile product development, you should roughly get the following answer: Cut the product in the smallest possible, viable and testable pieces (also called MVP). Deliver those, piece by piece (incremental), to the customer to learn as quickly as possible from real feedback from real customers on the real product if the way it is realized satisfies the users main needs. The objective is to still be able to change qualities and properties as well as priorities during development. In the end, you should have a product developed in time and budget that fulfills the users’ needs in the best possible way.
Or: If our agile Granny Berta wants to make her loved Grandchild Max a hand knitted jumper as a birthday present, she first tries to find out if Max would love such a jumper (anyway – we know: she may not simply ask Max that question because of several serious biases and social and other matters rooted in cognitive science). In case of a positive answer, and only then, she can schlepp Max to the next knitting store, for him to chose his favorite wool and a delightful, sharp cut for the jumper. While knitting, Granny Berta, of course, will test her technical realization of the jumper directly with max, so that she can adapt to his taste, based on his feedback, to avoid wasting time on the wrong jumper.
Not working this agile way (like indeed most Grannies do, as you certainly know!) would hold a relatively small chance for a happy Granny and a happy Grandchild: Granny would suffer the terrible, devastating moment of epiphany, realizing that Max wants a scarf in the colors of his football team (in this case red and white) and by the way the jumper doesn’t fit at all and the colors are beyond belief for Max.
So, Granny and Product Managers should better follow 3 main principles:
- Cut the product in the smallest, self contained, usable and testable pieces and deliver them as quickly as possible.
- Learn quickly if the qualities and properties of the product realization meet the users needs.
- Realize the learnings in time and budget, given our companies demands on quality, validity, completeness, etc.
What is written down and read with ease, is hard stuff in the real world of companies. Many enterprises invested heavily in ‘getting agile’ but could never get further than realizing the first of the principles. By that they simply cut the big waterfall they came from into many, smaller waterfalls. This is a big achievement, but leaving out the other principles means leaving out further potential of real agile product development: User centricity and the opportunity of fast user feedback and holistic learning on the users needs, the effect of the product and the market.
We have seen five patterns for missing user centricity in the companies we encountered, and there may be good reasons for each of them:
- The enterprise simply doesn’t want to learn about the customer. Or: “I am knitting a jumper for Max every year and ‘til now there’s been nothing wrong with it.”
- The company does not know what to learn or how this works (known or unknown unknowns).Or: “How should I get to know what Max likes?”
- The company doesn’t dare to show the client a half done product. Or: “I can’t show this to Max, how would that look like, no arms yet!”
- The company wants to learn but doesn’t give itself time and space to apply the learnings because the next project or feature is standing in line. Or: “I’d actually like to apply the stars that Max wanted so desperately, but I need to come up with that scarf that I promised Maggie”“
- The company does not dare to learn, as the product shall remain secret until the big bang release. Or: „Oh my god, the jumper is meant to be a birthday surprise!”
There may be good reasons for all five patterns (after all: product development is not a means in itself, but a tool to achieve customer satisfaction through customer centricity). But it is a problem, if these patterns are not applied out of explicit reasoning, but simply ‘just happen’. Companies striving for sustainable and resilient agility should ask themselves if they really are capable of all three principles of agile product development and if not: Why?
Photo by Phil Campbell on flickr under CC License