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?"


The issue names no files, tests, or entry points. Start by reviewing the paper prototype and lean canvas referenced in the checklist; done means the riskiest assumption is documented, the smallest testable increment is identified, and Sprint cards capture the work needed to test it.

Written by the indexing model from the issue text.