ExumaTech Dev Process
0 likes356 views
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.
ExumaTech Dev Process
- 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
- 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."