How to choose your MVP features

Choose MVP features by starting with one person completing one useful journey. A feature belongs in the first version when the journey cannot produce a credible result without it, when it is needed to operate the test responsibly, or when it lets you observe the question you are testing.

That is a more useful filter than asking whether a feature sounds important eventually. A feature can be valuable in a later product and still be unnecessary for the next test.

Pick one person and one result

Imagine you want to help freelance photographers follow up on overdue invoices. Your first audience is a photographer who has already sent an invoice and wants a professional reminder without writing it from scratch. The result is a reminder they can review and send.

Your first question might be: “Can photographers complete the reminder task and find the draft useful?” That is narrower than asking whether they want an entire invoicing platform. With fictional details, you can observe task completion and ask about perceived usefulness; you cannot conclude that they would use it in a real overdue-invoice workflow.

Keep the initial scenario specific. If the person needs reminders in several languages, automatic accounting sync, and approval by a finance department, you are already describing a different journey. Those needs may be real, but they require separate decisions and possibly separate tests.

Map the journey from start to finish

Write the actions in the order a person takes them:

The photographer opens the reminder tool when an invoice is overdue.
They enter the client name, amount, due date, and tone they want.
They receive a reminder draft and check it for accuracy.
They can adapt the draft for their email and decide whether to send it.

The journey ends with a draft the person can use and a way to take it into their email. A screen that accepts details but produces no reminder is a component, not the whole journey. A copy button and an editable field are possible implementations, not requirements: selecting text and editing it in an email can provide the same capabilities for this test.

The initial implementation could even be a form followed by a manually prepared draft. Tell participants how the service works and when to expect the result. That tests a different experience from instant generation, so do not use it to claim users value the automated experience.

Sort features by what the test needs

For this example, a first cut could look like this:

Keep: enter invoice details. The reminder needs the right information. A short form can provide it.
Keep: produce and transfer a draft. The photographer needs text they can review, adapt, and use. Selecting text or a copy button can both work; the button itself is optional.
Keep: clear errors and a way to observe completion. Missing details should not silently produce a misleading draft, and you need to see whether the journey works. Use fictional data if real invoice details are not necessary.
Defer: accounting integration and automatic sending. Manual entry and the photographer’s own email can deliver the result for this question.
Defer: team permissions, payment collection, a dashboard, and multiple templates. None is needed for the selected journey. Record them for a later question rather than assuming they will never matter.

The categories are not permanent. If the question is whether reminders can be sent automatically without extra work, a copy button cannot answer it. You may need a different experiment, an email integration, and safeguards for actual sending. Change the scope when the question changes.

For every proposed feature, ask: “What breaks in this journey or learning if we remove it?” If the answer is “the result would not be possible,” keep it. If a manual step can replace it without hiding a material difference from participants, consider that step. If the answer is “the product would feel more complete,” defer it and record why.

Do not cut the parts that make the result trustworthy

A narrow feature set still needs to work for the people invited to use it. In the reminder example, show the complete draft before sending, do not send on the user's behalf without permission, and avoid implying that the amount or recipient has been verified. If you collect real invoice details, limit access and retention and explain their use before collecting them. If you cannot protect the data adequately, use fictional data or stop the test until you can.

A feature might also be necessary even though it is not visible on the happy path. Error messages, access controls, recovery, and support depend on the consequences of failure. Do not cut a safeguard merely to reduce the feature count.

Decide what to measure

Before inviting people, write down what counts as reaching the outcome. For the first journey, that could be the number of eligible participants who enter details, receive a draft they can use, and transfer it to an email. Before the test, choose a decision signal. For example, invite five photographers and plan to investigate the draft further if at least three reach and transfer a draft they say they can adapt. If all five complete the test and fewer than three do so, inspect where the journey or the proposed value breaks. If fewer than five complete the test, treat the threshold as inconclusive. This is an illustrative decision rule, not a statistical threshold. Ask what they changed and why, but distinguish their comments from observed actions.

This does not prove they sent the message unless you observe or verify that separately. A small, invited group can show where the flow breaks and suggest whether to run another test; it cannot establish a market size or a reliable conversion rate.

If people complete the journey but rewrite every reminder, improve the draft or revisit the assumed value. If they never enter details, ask whether the request is unclear or the data feels too sensitive. In a simulation, non-entry does not establish whether the problem is urgent. Assess real-workflow use or urgency separately with appropriate consent. Do not assume a missing feature is the answer before checking.

Make the cut

Write your version of this sentence: “[Person] can [action] and receive [useful result]. We will observe [behavior] to learn [question].” Map the steps, then put each proposed feature beside the step or safeguard it supports. Anything with no clear link goes on a later list.

Once the journey is small enough to test, choose the cheapest honest way to deliver it. A manual service, a prototype, or an application can each be right for a different question.