1. Approach
1.1. Every business problem has many possible solutions
1.2. The challenge is figuring out which solutions are viable and then, of the viable ones, the most valuable
1.3. Assumption: our initial product designs will be wrong
1.3.1. In most cases, it's impossible to predict the right solution in advance
1.3.2. "People will tell you what they want when you have given them what they asked for"
1.4. Process
1.4.1. 1. Treat each design as a hypothesis — a proposed business solution
1.4.1.1. what is the smallest, simplest, cheapest, fastest thing you can build to test the hypothesis?
1.4.1.1.1. This is your MVP
1.4.1.2. Focus on the highest risk and uncertainty (of the core functionality critical for success), then focus on highest value
1.4.1.2.1. it's about the speed at which you learn and mitigate risks
1.4.2. 2. Validate the hypothesis as quickly as possible
1.4.2.1. Seek customer/user feedback against a working system/prototype
1.4.3. 3. Adapt design and plan according to feedback and learnings
1.4.3.1. You collect what you learn from your MVP, develop your ideas and adapt invalid assumptions
1.4.4. 4. Rinse and repeat
1.4.4.1. Then you do it again
2. Collaboration over contract negotiation
2.1. High trust and close collaboration creates alignment more effectively than written communication, argument, and elaborate defence (contract negotiation)
3. Continuity of people involved and the importance of flow of delivery
3.1. The tacit nature of knowledge is difficult to transfer and it's value diminishes over time
4. Challenging the status quo
4.1. Dealing with these common pitfalls:
4.1.1. ‘We know what to build’
4.1.1.1. no user research needed!?!
4.1.2. 'We love the solution'
4.1.2.1. you should fall in love with the problem instead
4.1.3. 'The incrementalism trap'
4.1.3.1. You get so focused on improving incrementally that you miss the available innovative leaps possible
4.1.4. 'We must follow the roadmap'
4.1.4.1. at the expense of building the right product
4.1.5. 'Self-fulfilling prophecy'
4.1.5.1. Defining personas so as to confirm your bias
4.1.6. 'No shared understanding'
4.1.6.1. Stakeholders not on the same page