Before the MVP, Find the Decision You Need to Make

Imagine a founder in Wayanad preparing to discuss an enterprise software idea with a potential customer in Bengaluru. In this hypothetical scene, the presentation is ready: the problem, the proposed platform and a list of features. Yet one question remains unanswered: what could that customer say or do that would make the founder change the plan?

My direct answer is this: useful founder mentoring should turn an idea into a decision that evidence can inform. Before asking what belongs in the MVP, I would ask which uncertainty the MVP needs to resolve.

The distance between an idea and a product is not primarily geographical. It is the distance between a convincing explanation and a testable claim.

Start with the decision, not the feature list

My work in enterprise technology and SaaS product building shapes how I think about mentoring. I am less interested in making an early idea sound complete than in making its next decision clearer.

“Should we build this platform?” is usually too large a question. It bundles together the user, the problem, the workflow, the buyer and the proposed solution. A positive response can leave all five uncertain.

A more useful question might be: “Does this particular team have a recurring handover problem that it is willing to change its working habits to solve?”

That question does not yet justify a platform. It does give the founder something specific to investigate.

I would want a mentoring conversation to end with a sentence such as: “We need to decide whether to pursue this workflow, and here is the evidence that would help us decide.” The value lies not in sounding confident, but in identifying what confidence must rest on.

Give the idea a working environment

Consider a hypothetical founder proposing an internal request-management tool. The initial description might promise a single place for requests, approvals and status updates.

Instead of expanding the feature list, I would narrow the setting. Who submits the request? Who acts on it? Where does responsibility become unclear? What happens when the request is delayed?

In enterprise SaaS, I would also separate the person experiencing the difficulty from the person authorising a purchase or accepting an implementation. Their concerns need not be identical.

A user might want fewer follow-ups. A manager might need clearer ownership. A technology team might question how another tool would fit the existing environment. These are hypothetical possibilities to investigate, not requirements to assume.

The resulting product question could be: “Would making ownership visible at one handover point reduce the need for manual follow-up enough for this team to adopt a different process?”

Now the founder has a boundary. The whole organisation does not need to be redesigned to learn whether that handover matters.

Choose the smallest honest test

I use “honest” deliberately. A demonstration can show that a screen is understandable without showing that a team will use it. An enthusiastic conversation can indicate interest without establishing purchase intent.

Different evidence supports different conclusions.

For our hypothetical request-management idea, a workflow sketch might help reveal misunderstood responsibilities. A manually supported trial might explore whether clearer ownership changes behaviour. A limited prototype might test whether people can complete the intended task.

None of these automatically answers every commercial or technical question. The founder should name what remains unknown rather than allowing one encouraging signal to stand for the whole business.

Modern Innovation Hub in Wayanad supports founders through mentorship, MVP development and investor connections. I see the product question as a useful thread connecting those forms of support: it gives mentoring a focus and MVP development a learning objective. It can also make a founder's explanation of the opportunity more precise, without implying any promised outcome.

Leave with a question and a stopping rule

Before committing to an MVP scope, I would use this checklist:

• Name the user: Who encounters the problem directly?
• Locate the moment: At what specific step does the workflow become difficult?
• Describe the current response: How is the work handled today?
• Expose the assumption: What must be true for the proposed product to matter?
• Choose the evidence: What observation or action would support that assumption?
• Set a stopping rule: What result would make us narrow, revise or abandon the approach?
• Limit the conclusion: What will this test still leave unanswered?

For me, mentoring is not about replacing a founder's judgement with a mentor's certainty. It is about helping that judgement become more explicit and open to correction.

A founder should leave with ownership of the idea intact, but with a sharper understanding of what to learn next. Sometimes the most valuable progress is not another feature. It is a question precise enough to reveal that the feature is unnecessary.