Define the testable MVP

### Define a testable Minimum Viable Product

An MVP is the smallest possible increment of your solution that delivers enough value for you to be able to ship it and learn from customers as quickly as possible.

- [ ] Agree as a team: from your paper prototype and lean canvas, what's the riskiest assumption you're making?

For example, if you were building a device that would automatically pour beer for you, the riskiest assumption might be technical - how do you know how much volume of beer to pour? If you were building AirBnB, the riskiest assumption wouldn't be tech, but instead would be trust - will users rent out a bedroom in their house to a stranger?

- [ ] Take your riskiest assumption and figure out the smallest increment you need to build to test that assumption.

- [ ] Take that increment and create cards on your board to represent what your team needs to get done in the next Sprint to build that iteration. Think about what it will take to test your MVP - it's not just about building something, it's about building something you can use to learn from *as fast as possible*.

This backlog of work can be used in your pitch too, to answer "What's next?"


Start by reviewing the paper prototype and lean canvas, then identify and agree on the team's riskiest assumption. Define the smallest increment that can test it, turn the required work into cards for the next Sprint, and document the resulting backlog for the pitch.

Written by the indexing model from the issue text.