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?"
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.
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?
This backlog of work can be used in your pitch too, to answer "What's next?"