An MVP is a question. Not a feature list.

Start with the uncertainty

The first version of a product can easily become a smaller version of the founder’s entire vision. The roadmap shrinks, but the underlying assumptions stay intact. A more useful starting point is a question: what do we need to learn before the next investment makes sense?

That question might concern customer demand, a difficult workflow, technical feasibility or willingness to pay. Each calls for a different experiment. A polished interface will not answer whether a data integration is viable. A working integration will not establish whether anyone wants the product.

Choose one meaningful promise

Describe the first release in terms of a person and a job. For example: a service manager needs to understand which requests need attention, without reading every message. This gives the team a clear experience to design and a clear outcome to observe.

Then ask which features are essential to deliver that promise. Administration, advanced reporting and broad configurability may matter later. Include them now only if the first user journey cannot work or be evaluated safely without them.

• Who is the first user?
• What important job are they trying to complete?
• What change would show that the product helped?
• What evidence would make us reconsider the idea?

Make the learning plan part of the scope

Before development begins, agree how the first users will be recruited, what behaviour will be observed and who will conduct follow-up conversations. Define the pilot’s limitations. A friendly participant giving positive feedback is a different signal from a customer repeatedly choosing the product in their daily work.

Record a baseline where possible. Pair usage data with conversations that explain the behaviour. Decide in advance when the team will review the evidence, so launch does not quietly become the end of the project.

Keep quality proportional to the risk

A small scope is not permission to ignore security, privacy, accessibility or reliability. A pilot that touches sensitive data or an important operational process needs controls appropriate to that context.

Reduce the breadth of the release rather than removing the conditions that make it safe and meaningful to use. Manual operations behind the scenes may be reasonable; unclear responsibilities or unmanaged data exposure are not useful experiments.

Decide what happens next

The first release should leave the team better informed. Continue when the evidence supports the idea. Change the audience, problem or experience when the signal points elsewhere. Stop when the underlying case does not hold.

At CoCreate, we connect the MVP build to the decision it needs to unlock. That keeps strategy, design, engineering and market feedback focused on the same question.