Define the person and the moment
An MVP becomes clearer when it is built for a specific person in a specific situation. Describe what that person is trying to accomplish, what happens today, and why the current option is not good enough.
Avoid beginning with a long feature list. The most important question is what useful action the first version must make possible.
Decide what you need to learn
The first release should test an assumption that matters. That might be whether people will complete a workflow, provide information, return to the product, invite teammates, or pay for a result.
- Who is the first user?
- What behavior shows that the product helped?
- What assumption could make the idea fail?
- What evidence would justify building more?
Bring examples, not perfect requirements
Screenshots, spreadsheets, sketches, competitor references, sample documents, and recordings of the current process are valuable. They expose the information and edge cases that abstract descriptions miss.
You do not need to choose the architecture or write a technical specification. A responsible development partner should help convert the business idea into testable requirements.
Plan for the unglamorous parts
Accounts, permissions, data handling, errors, support, analytics, and administration can determine whether an MVP is usable. They do not all need to be elaborate, but they must be considered.
A focused scope, a named decision-maker, access to representative users, and a plan for feedback will do more for the MVP than adding another feature before anyone uses it.