How to define MVP

Overall Guidance:
1. MVP is full of bugs and issues. That is ok. As long as MVP can meet the goal, it is good.

Knowledge Sharing:
1. The motivation for building an MVP is to verify any assumptions you might have about customers’ problems and your ability to solve them.
2. By its minimal nature, an MVP will never cover the needs of a mass market, not even multiple groups of early adopters. Hence, a key discriminator between the beta and the MVP is a clear notion of a customer segment: A set of people who experience the problem you are trying to solve to a degree that makes them interested in buying a minimal, immature, change-prone product.
3. My driver here, which is basically anything but the learning part, will almost certainly make me design an MVP which is far from minimal, but still cannot be stripped down further once everybody had their say.
4. The difference is how the development teams focus their work. Focusing on a single change for a limited segment of users, and building from there will have a much higher probability of really helping someone, compared to going out wide and generic, usually motivated by fighting of fierce competition, taking maximum advantage of resources and other pre-mature economy of scale factors.
5. So, if you’re currently building an MVP, I would like to encourage asking some randomly chosen team members the following: Who will experience a change because of what we are making? If you don’t hear a consistent answer, you might want to reiterate your MVP strategy.
6. Maybe it’s just internal communication. Most likely, however, you’re not minimal enough. You don’t have a minimum viable product, and you probably don’t have a minimum market segment and a clear notion of how to impact it.

7. 7. MVP is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
8. there is no business without revenue which also tends to be one of the riskier parts of the business model.
9. This is why whenever your users are also your customers, I am a strong advocate of capturing back some of that value which is just a fancy way of saying “charge from day one and get paid”.
10. 

Goals of MVP:
1. Spend less time to develop a MVP to demo the a customer about how the product can solve their product and get feadback.
2. Develop it in a week.

It is ok:
1. Have bad UI
2. Have missing features
3. I am shamed of the product.

Stage of MVP:

0. Biz Idea

1. Product Concept/Feature List

2. Architecture

3. POC for new technology

4. Prototype

5. Beta Release

6. Release

====================================

Idea: (User: Concept)

- Identify a problem, and a solution proposal to solve the problem for 1%.

POC: (User: Myself)

1. Technology Adoption

Team: Myself

Prototype: (User: Wife, In-Person users from Starbucks/Friends)

1. Core business logic

Team: Myself

Beta Release: (User: Invitated Remote Users)

1. Security

2. Session Timeout and Management

3. User Management

Team: Myself

Public Availability: (User: Public People, Investors)

Team: Myself and Team

Mistakes:
1. Don't try to use MVP to learn new technology. Very big mistake. Try to save time if possible in startup activities.
2. Don't spend too much time in job to learn new technology, hopefully one day it will help startup. Dreaming, Hypothetical, Unrealistic, etc.

References:
http://blog.iterate.no/2012/12/05/dont-substitute-mvp-for-beta/