Jeff Patton gave a talk at the UK Lean Conference 2009 on Lean Product Discovery. Jeff starts by sharing a story on how the most influence moment in his life came when he sat behind someone using software he created. He discovered that understanding what people wanted is critical to delivering value to them.
Jeff mentions that in software development we are balancing 2 concerns:
1. Delivery: building of a software product. Analysis, design, coding, testing, documenting… This side is visible.
2. Discovery: learning about the outside world and our product in it. Understanding the world, understanding the product, what problems it solves, what value it provides and how it fits in the word. Understanding customers, market, competition, users. Prototype and validate user experience, create UI, validate working software.
Discovery (problem customers have) and delivery (the solution) work hand-in hand and overlap as we deliver product increments.
Jeff notes that healthy delivery process build software incrementally. It requires a fully formed idea (up front discovery), accurate estimation and upfront product assumption. If we don’t continually ask if this is what we want to build we might end up off in terms of quality and final result.
We need to balance delivery with discovery. Traditionally we are out of balance. We do a lot of upfront discovery and then do only delivery. However, after delivery we learn more from users using the product and then we are back in balance between discovery and delivery, but this re-balance happens very late in the game. Jeff gives an example of drawing a painting, starting and completing one section and then moving on to another section and so on until we finish the last section.
Iterating and incrementing leverages discovery to iterate as we deliver. This allows us to move from vague idea to realization making course correction as we go along. Jeff gives an example of again drawing a painting, however this time we start with a rough sketch of the entire picture, then we fill in more details, and then we add some colors, etc...
Next Jeff discusses how to break things down in a way that lets us balance discovery with delivery. He recommends breaking down large features using these four splitting heuristics:
1. Bare Necessity: Feature contains minimal functionality to be minimally demonstrable but not necessarily releasable. Example is having a form for data entry but with no field validation.
2. Capability and Flexibility: Ability to perform same tasks in different ways. Example is calendar pop up for date selection.
3. Safety: This that protect the system and users. Invisible functionality. Example is data validation and enforcement of business rules.
4. Usability, performance, sex appeal: Making a feature easier or more desirable to use. Example is a sleek UI, or adding auto complete to form fields.
With early iterations we strive to build bare necessity and in later iterations we build up quality. Along the way we need to have assessments to find out or grade how releasable a feature is.
Finally, Jeff recommends dividing a release design and development into 3 phases:
1. Opening game: Skeleton that spans system and contains necessary features
2. Mid game: Add capability, flexibility and safety
3. End game: Finish with usability, performance, and sex appeal and reserve time for unforeseen additions and adaptations.
Jeff concludes that this helps us grow the software and at the same time increase our knowledge which in turn helps us mitigate risk.
This presentation is available on InfoQ at http://www.infoq.com/presentations/lean-product-discovery
