The document discusses the challenges of traditional product development, emphasizing the need for validated learning and continuous deployment to better understand customer needs and improve solutions. It highlights misconceptions about knowing customer wants and proposes methods for faster measurement and learning, such as customer validation and the '5 whys' root cause analysis technique. The aim is to minimize development time and encourage continuous improvement through iterative processes.

1. ExumaTech
Development
Process

2. Traditional Product Development
Problem: Solution:
Known Known

3. Common Misconceptions
• We know what customers
want (Problem)
• We know how to solve it
(Solution)
• Advancement is progress

4. Traditional Product Development
Problem: Solution:
Known Known

5. Commercial Software Reality
• Problem = Known
• Problem = Hypothesis
• Solution = Hypothesis
• Solution = Unknown

6. • Do customers recognize they
have the need?
• If there was a solution, would
they buy it?
• Would they buy it from us?
• Can we build it?

7. Minimize TOTAL time through the loop

8. Validated Learning

9. Code Faster:
Continuous
Deployment

10. Continuous Deployment
• Deploy new software to Q/A quickly:
Measure last check-in to Q/A
deployment
• Break large projects into small batches
• Tell a good change from a bad change
(quickly) and…
• Revert a bad change quickly

11. Envelope Stuffing
Your job is to stuff 5 envelopes and stamp them.
What’s faster?
1. Folding all five sheets, then stuffing, then licking,
then stamping?
2. Doing each envelope one at a time?

12. Measure Faster:
Customer
Validation

13. Customer Validation
• Indentify product champion or liaison
• Validate hypothesis through customer
use and interaction
• Measure response across a sample set

14. Learn Faster:
5 Whys Root
Cause
Analysis

15. 5 Whys Root Cause Analysis
• A technique for continuous improvement
of company processes
• Ask “why” five times when something
unexpected happens
• Behind every supposed technical
problem is a human problem

16. 5 Whys Example
1. A new release broke a key feature for customers.
Why? Because a particular server failed.
2. Why did the server fail? Because an obscure
subsystem was used in the wrong way.
3. Why was it used in the wrong way? The engineer who
used it didn't know how to use it properly.
4. Why didn't he know? Because he was never trained.
5. Why wasn't he trained? Because his manager doesn't
believe in training new engineers, because they are
"too busy."

17. Cam Collins
cam@exumatech.com
http://exumatech.com
@CamCollins (Twitter)