Decision note
Before building the MVP, decide what does not belong in it.
An MVP is not a small version of the final product. It is an instrument for proving the assumption that matters most.
The operating view
Reduce the decision before increasing the technology.
Name the assumption
Market demand, operational feasibility, pricing, retention and technical feasibility need different MVPs.
Remove everything that does not test it
Features that feel necessary because competitors have them often belong after the first proof point.
Design enough architecture for the next step
Avoid both throwaway prototypes and enterprise architecture for a market that has not yet answered back.
Define the next decision
A good MVP tells leadership what to do after the result, whether the result is positive or negative.