Skip to content
BlackFig

Free tool, no sign-up

What features should your MVP have?

Write your idea, list the features, answer three questions about each, and get a must-have, should-have and later list you can print.

What do you want it to do?

Pick everything, even the wishlist. The questions below do the cutting.

Three questions for each

Tick what is true. Be strict: a feature you are not sure about can wait.

  • Sign up and login

  • Payments

How the scoping works

Most MVPs are too big. Not because founders are careless, but because every feature sounds necessary when you are the one who thought of it. This tool replaces "do I need this?" with three narrower questions that are easier to answer honestly.

You start with a one-line idea and who your first user is. Then you add features, either from the presets or in your own words. For each feature, you answer three questions.

  1. Does your first user need it to get value?

    Not a user in a year. The first person who uses it. If they can get what they came for without it, it can wait.

  2. Does it block taking payment?

    If a user cannot pay you without this feature, you cannot find out whether the idea is worth anything.

  3. Could you do it by hand at first?

    Many features are a job you could do yourself for the first few users: an email instead of a notification system, a spreadsheet instead of an admin panel.

The rules

The answers go through four rules, in this order. The first one that matches decides where the feature goes.

How the three answers become a priority
Result
Blocks taking paymentMust-have
First user needs it, and it cannot be done by handMust-have
First user needs it, but it can be done by handShould-have
Anything elseLater

Payment comes first because the most useful thing an MVP can tell you is whether people will pay. A product that cannot take money cannot answer that.

The by-hand question is where most of the savings are. If your first users need something but you could do it yourself for a while, it becomes a should-have. You might build it, or you might run it by hand until the volume tells you it is worth building. Either way, it is not what stops you launching.

What you get

  • A prioritised scope. Your features in three groups: must-have, should-have and later.
  • A cut list. Everything marked later, in one place. This is the list to hold firm on when a new idea arrives mid-build.
  • A one-page summary. Your idea, your first user and the scope on one page, to download or print. It is useful to hand to whoever builds it, so they quote for the right thing.

How to read the result

A short must-have list is a good sign, not a weak product. If almost everything ends up as a must-have, go back and look at the by-hand answers. Founders often answer "no" to "could you do it by hand" because doing it by hand sounds unprofessional. For your first handful of users, it usually is not. It is often the fastest way to learn what the feature should actually do.

If your must-have list still looks long, the idea may be two products. Pick the one your first user needs most.

Limits

  • The rules are blunt on purpose. They will not catch a feature that is technically essential but invisible to users, such as auth for an app with private data. Use your judgement.
  • The result is only as honest as the answers. The tool cannot tell whether your first user really needs something.
  • It does not price anything. To see what your must-have list costs, run it through the MVP cost calculator, or read what an MVP costs in the UK.
  • It is not a market test. A tight scope still needs real users to tell you whether it works.

Privacy

Nothing is stored. If you want to keep your scope, download or print the summary before you leave the page. Email is optional.

If you would like a second opinion on what you have scoped, book a call and bring the summary. I will tell you what I would cut.

What your result meansHiring a product designer who codes

Questions founders ask

What are the three questions?

Does your first user need it to get value? Does it block you taking payment? Could you do it by hand at first? The answers decide whether a feature is a must-have, a should-have or later.

Why does anything that blocks payment count as a must-have?

Because finding out whether people will pay is the main thing an MVP is for. If a feature stands between a user and paying you, you cannot learn that without it.

What does doing it by hand mean?

Doing the job yourself behind the scenes instead of building it. Sending invoices by email instead of building billing, or matching people yourself instead of building a matching algorithm. It is slower per user but much faster to launch.

Is my idea stored anywhere?

No. Nothing is stored. If you want to keep the result, download or print the one-page summary. Email is optional.

Can I add features that are not in the presets?

Yes. Pick from the presets or type your own. Every feature gets the same three questions.

More free tools

Free tool, no sign-upMVP cost calculatorPick your product type, platforms and features to see a price range in pounds for three routes, a rough timeline and what to build first.Estimate your MVP costFree tool, no sign-upVibe-code health checkEnter your live URL and tick a short checklist to get a score out of 100, the top five issues in plain English and what fixing them takes.Check your app for free

See if BlackFig fits your idea (it probably does)

A quick 30 minute call. No slides, no hard sell. You leave with a clear next step either way.

Intro call with Ant

30 min · video call

When suits you best?

Times shown in your time zone on the next step