DEV Community

Cover image for Building an MVP? Start With the Question, Not the Feature List
Nasif Sid for 6sense HQ

Posted on

Building an MVP? Start With the Question, Not the Feature List

Most MVP discussions start in the wrong place.

The team opens a doc, writes a long list of features, then starts cutting things until the scope feels “small enough.”

That sounds reasonable, but it often creates a weak MVP.

Because an MVP is not just a smaller product.

An MVP is a focused way to test whether a specific idea is worth building further.

So the better starting question is not:

What features can we fit into version one?

The better question is:

What do we need to learn first?

Once you think about MVPs this way, the whole development process changes.

The MVP is a learning tool

A good MVP should help you answer a real product question.

For example:

  • Do users actually have this problem?
  • Are they already trying to solve it somehow?
  • Will they trust our solution?
  • Can they complete the core workflow without help?
  • Would they pay for this, or at least keep using it?

These questions matter more than the number of screens, integrations, or dashboard widgets you can ship.

A product with five features can still be too much.

A product with one feature can still be unclear.

The point is not to build less for the sake of building less. The point is to build only what helps validate the main assumption.

Start with the riskiest assumption

Every startup idea has assumptions.

Some are small.

Some can kill the product.

For example, imagine you are building a tool that helps agencies collect feedback from clients.

The assumptions might be:

  • Agencies struggle to collect clear client feedback.
  • Clients are willing to use another tool.
  • The tool saves enough time to become part of the agency workflow.
  • Teams will invite clients into the platform.
  • Agencies will pay for it monthly.

All of these matter, but not equally.

The riskiest one might be:

Will agencies actually move client feedback out of email, Slack, or Google Docs?

If the answer is no, the product may not work no matter how polished the dashboard is.

So the MVP should focus on testing that behavior first.

Not billing.

Not advanced roles.

Not analytics.

Not white-label settings.

Those might matter later, but they are not the first thing to prove.

Build the smallest complete experience

“Minimum” does not mean broken.

It does not mean ugly.

It does not mean confusing.

It means focused.

The user should still be able to understand the product, complete the main action, and experience the core value.

For example, if the MVP is a feedback tool for agencies, the smallest complete experience might be:

  1. Agency creates a feedback request.
  2. Client opens a simple link.
  3. Client leaves structured feedback.
  4. Agency sees the response in one place.
  5. Agency decides whether this is better than their current workflow.

That is a complete learning loop.

You do not need team permissions, custom branding, AI summaries, payment plans, Zapier integration, or a mobile app yet.

But the core flow should feel usable.

If users cannot understand what to do, you are not testing the idea properly. You are testing their patience.

Avoid building “just in case” features

A lot of MVPs become bloated because of “just in case” thinking.

  • “Let’s add admin roles just in case teams need them.”
  • “Let’s add exports just in case someone asks.”
  • “Let’s support multiple industries just in case.”
  • “Let’s add customization just in case users want flexibility.”
  • “Let’s add integrations just in case it helps adoption.”

This is how a simple MVP turns into a much bigger build.

The problem is not that these features are bad. Many of them may be useful later.

The problem is timing.

Early on, every extra feature creates more design decisions, more edge cases, more QA, more bugs, and more confusion around what you are actually trying to learn.

A good MVP has strong boundaries.

It says:

This version is only meant to prove this one thing.

That kind of constraint is useful.

Manual work is fine in an MVP

Not everything needs to be automated in the first version.

This is especially true when you are still learning what users want.

For example:

  • Reports can be generated manually behind the scenes.
  • Onboarding can happen through a call.
  • Recommendations can be prepared by the team.
  • Data imports can be handled with CSV files.
  • Support can be direct and personal.
  • Some admin work can happen outside the product.

This may not scale, but that is okay.

The MVP is not supposed to scale perfectly.

It is supposed to teach you what deserves to be scaled.

Automation too early can waste a lot of time. First, prove that the workflow matters. Then improve the system behind it.

Define success before launch

Before shipping an MVP, decide what success looks like.

Not in vague terms like:

We want good feedback.

That is too soft.

Use clearer signals.

For example:

  • 10 users complete the full workflow.
  • 5 users come back and use it again.
  • 3 users ask for access for their team.
  • 2 users say they would pay for it.
  • A user stops using their old workflow.
  • A user asks for one specific improvement instead of questioning the whole product.

These signals are more useful than page views or casual compliments.

People may say an idea is interesting.

That does not mean they will use it.

The MVP should create behavioral evidence.

The timeline should match the learning goal

Not every MVP needs the same timeline.

A landing page test may take days.

A clickable prototype may take a week.

A no-code MVP may take a couple of weeks.

A custom SaaS MVP may take longer, depending on the workflow, integrations, and technical complexity.

The important thing is to avoid treating the MVP timeline like a random deadline.

The scope, timeline, and validation goal should match each other.

This breakdown of MVP development phases and timeline is a useful reference if you are trying to understand what usually happens before, during, and after the first build.

The key is not rushing into development before the learning goal is clear.

What developers should ask before building

Developers can add a lot of value before the first sprint starts.

Not by saying “no” to everything, but by asking better questions.

Some useful questions:

  • What is the main assumption we are testing?
  • Which user type are we building for first?
  • What is the one workflow that must work well?
  • Which features are required for validation?
  • Which features are only nice to have?
  • Can any part of this be manual for now?
  • What data do we need to collect?
  • What would make us stop, continue, or pivot after launch?

These questions prevent wasted effort.

They also help the team avoid building a product that is technically finished but strategically unclear.

Final thought

The best MVPs are not the ones with the fewest features.

They are the ones with the clearest purpose.

A strong MVP knows what it is testing. It gives users a complete enough experience to respond honestly. It avoids unnecessary complexity. It creates evidence the team can use.

So before building your next MVP, do not start with the feature list.

Start with the question.

Then build the smallest useful thing that can answer it.

Top comments (0)