Your MVP doesn’t need fewer features. It needs one clear job.

Every founder building a first product hears the same advice: cut features. Ship less. Keep the MVP minimal.

It's good advice. It's also incomplete.

If you cut features without a clear reason, you won’t get a more focused product. You’ll just have a smaller, still unfocused one. There might be fewer screens, but the confusion stays. The real problem isn’t how many features you have. It’s that no one has decided what the product is for.

An MVP doesn't need fewer features. It needs one clear job.

Why feature-cutting goes wrong

Most first products start as a list. A list of things the founder has imagined, things investors asked about, things a competitor does, and things a potential customer mentioned once in a call. Each one makes sense on its own.

When budget and time come into play, the list gets cut down. But just cutting the list doesn’t give the product real direction. People often choose based on what’s cheapest or who pushes hardest, not what the product actually needs to prove.

The result is a product that does several things okay, but nothing stands out. Users try it, aren’t sure what it’s for, and move on. Since no one defined success clearly, it’s hard to know whether the idea failed or was just poorly executed.

That's the outcome every first-time founder fears most: spending a huge part of the budget and still not knowing if you built the right thing.

Finding the one job

A product’s “one job” is the main thing one specific person needs it to do. It’s not about everything the product could do. It’s the thing that, if it works, makes building the rest worthwhile.

It usually comes out of three questions:

1. Who is the very first person this needs to work for? Not just “small businesses” or “anyone who needs X.” Think of one specific person, in a real situation, with a problem they already feel.
2. What are they doing right now instead? Maybe it’s a spreadsheet, a WhatsApp group, a phone call, or some workaround they dislike. Your product is competing with those, not with a blank slate.
3. What needs to be true after they use it once? Maybe they saved an hour, got paid faster, or didn’t have to call anyone. That outcome is the job.

Once you have clear answers, the job usually fits into one sentence: “Help [this person] [do this] without [the painful workaround].” If you can’t write that sentence yet, hold off on designing screens. Talk to more real users first.

Designing around the job

When the job is clear, decisions that used to feel tough become much easier.

For every feature, ask: does this help the person do the main job, or is it for something else? If it’s for something else, put it on hold. Not forever—just until the core job is proven.

Start by designing the golden thread. Map out the shortest path from “I’ve just arrived” to “the job is done,” and focus on that journey first. Settings, dashboards, and extras can be rough for now, but the golden thread needs to be solid.

Success becomes something you can measure. If the job is “get paid faster,” you can see if people really do get paid faster. That’s much more useful for you and your investors than just counting sign-ups.

The design system grows out of real needs. Instead of making fifty components right away, you build only what the core journey needs, but make sure it can scale. The product grows from a strong centre, not from a long list.

The good news is this approach doesn’t make your product smaller. It makes it sharper. And sharp products are much easier to grow than vague ones.

Here's the one-job test

Before you brief a designer or a developer, try to finish this sentence regarding your product:

"It helps [one specific person] [do one specific thing] without [the workaround they use today]."

Next, go through your feature list and mark every item that directly supports that sentence. Anything unmarked goes into a “later” column.

If most of your list is marked, you’re on the right track. If you can’t write the sentence yet, don’t worry. That’s not a failure. It’s actually the best thing to learn before you spend your build budget, not after.

A feature list tells you what you could build. A clear job tells you what to build first.

Decide the job. Then design the product.

Want to go deeper?

If you'd like to dig further into the thinking behind this post, these are worth your time:

• Minimum Viable Product – Marty Cagan, Silicon Valley Product Group. A clear take on what an MVP is actually for, and what it isn't.
• The Lean Startup: Principles – Eric Ries. Where the MVP idea and the build-measure-learn loop come from.
• UX Prototypes: Low Fidelity vs. High Fidelity – Nielsen Norman Group. How to test your core journey cheaply before you commit to building it.

Read next: The brief you wrote isn't the problem you have