Before You Build an MVP, Prove the Problem Is Worth Solving

The First Question

Start by describing the expensive or frustrating situation in plain language. Who encounters it? How often? What do they do today? What does the current workaround cost in time, missed revenue, errors, or attention? If the answer is only that the proposed feature would be useful, the problem is still too abstract.

Look for behaviour rather than compliments. A person who already keeps a spreadsheet, pays for a workaround, hires someone to handle the task, or has tried several tools is giving you stronger evidence than someone who says the idea sounds good. The point is not to collect polite agreement. It is to learn what the problem has already made people do.

Before the Prototype

Map the alternatives. Include direct competitors, spreadsheets, agencies, internal staff, open-source tools, and the decision to do nothing. Note who each option serves, what it costs, where it breaks, and why people tolerate those weaknesses. A competitor is evidence that a category exists; it is not automatically a reason to build another version.

Talk to people who perform the work and inspect the artefacts it produces. A form, report, inbox thread, checklist, or handoff often reveals more than a feature request. Ask what happens before and after the visible task. Founders frequently discover that the proposed app is only one step in a larger process, and that the real opportunity is a clearer handoff or a smaller service.

This is the research stage for the MVP Building and Product Design lessons: learn, plan, find the pain, estimate the waste, and only then choose the shape of the answer. It can prevent a polished interface from hiding an untested assumption.

The Design Decision

The answer may be a SaaS product, but it may also be a service, a small custom tool, an open-source project, or a simpler process. A service is often the right first version when the workflow is still changing and the founder needs to learn alongside the customer. Open source can fit a repeatable technical need where inspection, portability, and community contribution matter. Custom software makes sense when the process is specific, valuable, and unlikely to be served well by a general product.

A SaaS product earns its place when the same problem appears for enough customers, the workflow can be made repeatable, and the support and operating costs are understood. Do not choose it because recurring revenue sounds attractive. Choose it when repeatability is already visible.

A useful test is to ask what must be true for the smallest paid outcome. If a founder can deliver that outcome manually for three customers, the first MVP may be a service with a thin internal tool. If people need a shared interface before they will commit, build only that path. The product shape should follow the evidence.

The MVP

Write the assumption before writing the feature: “This type of customer will give us this information and accept this result because it solves this costly problem.” Then choose the cheapest credible test. It might be a landing page with a serious call to action, a concierge service, a clickable prototype, a manual report, or a narrow working flow with a real user.

A successful test should leave evidence that changes your next decision. Record who tried it, what they completed without help, where they stopped, what they asked for, and whether they committed time or money. A demo that receives praise but no follow-through is a signal to revisit the problem, audience, or offer.

Keep the first build easy to discard. Product scope expands quickly when every idea is treated as part of the MVP. A small test gives the team permission to learn, change direction, or stop before infrastructure and marketing make the original assumption expensive.

AI-Assisted Building

AI makes it easier for more people to build software. That is useful when the founder already knows what needs to be tested. It becomes dangerous when a fast prototype is mistaken for product insight. AI can generate a plausible feature for an audience that never asked for it, and it can make a weak idea look finished enough to defend.

Use an assistant to turn research into a test plan, compare implementation options, scaffold a narrow flow, explain trade-offs, and help document what was built. Keep the human responsible for the customer, the acceptance criteria, the data, the security boundaries, and the decision to continue. Good engineers use AI to prototype faster and review more carefully; the tool does not remove the need to understand the system.

The same discipline applies when evaluating an agency or an AI-built proposal. Ask what evidence supports the problem, what will be tested first, who owns the resulting code and accounts, how the work will be reviewed, and what happens if the test fails. A confident proposal is not a substitute for a clear learning plan.