Back to field notes

Before you build an MVP, decide what it needs to prove.

A useful first product tests a business assumption. Its scope should follow the evidence you need, not a list of every feature you can imagine.

/ Yarvix field note

Original perspective · editorial review required before production publication

01

Name the uncertainty

“We need an app” describes a delivery format, not a problem. Start with a specific person, task and failure in the current approach. Then identify the assumption that matters: will a buyer pay, will an operator adopt the workflow or can the service fulfil the request?

02

Choose one complete journey

A small complete journey is more useful than disconnected screens. Follow one user from a starting point to a meaningful outcome, including validation, permissions, confirmation and recovery. Keep attractive but nonessential features in a separate list.

03

Define the observation before release

Agree what you will observe and what would change the next decision. A sign-up count can hide the fact that nobody completes the important task. Track genuine use, combine it with direct conversations and avoid inventing a target just because it looks persuasive.

Ask Yarvix

Explore how we work, find a solution, or shape your project brief.