· technical  · 9 min read

The "Narrow But Complete" Rule: How I Think About MVPs That Actually Land

I’ve shipped a lot of products. Some succeeded. Most didn’t.

The ones that failed? Almost always for the same reason: too ambitious, too unfocused, too “wouldn’t it be cool if we also…” Too many features that half-worked instead of one feature that fully worked.

The ones that succeeded? They followed what I now call the Narrow But Complete Rule.

Pick one problem. Solve it completely. Ship it. Everything else can wait.

This sounds obvious. It’s not. Because “narrow” and “complete” are in tension with each other, and most founders resolve that tension in the wrong direction.

The Rule Explained

Here’s the framework:

Narrow means:

  • One specific user
  • One specific problem
  • One specific workflow

Complete means:

  • That workflow works end-to-end
  • Reliably, without workarounds
  • Users can fully accomplish their goal

Not means:

  • Many workflows that are 50% done
  • Features that “mostly work”
  • Things users have to hack together

Visually, think of it like this: Most MVPs try to be wide but shallow—they touch many use cases but none deeply. Narrow But Complete MVPs are narrow but deep—they fully solve one thing.

Why this works: Depth creates value. Breadth creates confusion.

Users don’t want 10 things that sort of work. They want 1 thing they can rely on.

How to Apply It: The Scoping Exercise

Here’s how I scope every new product:

Step 1: Define your ideal user.

Not “freelancers” or “small business owners.” Be specific.

“Sarah is a freelance graphic designer who juggles 4-6 client projects at a time, uses Figma for design work, and struggles to keep track of client feedback across email, Slack, and random text messages.”

The more specific, the better. If you can picture one person, you can design for them.

Step 2: Identify their acute problem.

Not a general pain point. An acute problem—something they feel right now, multiple times per week, that they’d pay to fix.

For Sarah: “I lose track of client feedback and have to dig through Slack/email to find it when I’m ready to make revisions.”

Step 3: Map the complete solution journey.

What does Sarah need to go from problem → solved?

  1. Capture feedback from anywhere (email, Slack, text)
  2. Organize by project and client
  3. Search when she needs to find something
  4. Mark items as complete when addressed

That’s the narrow but complete workflow. She can fully accomplish her goal—managing client feedback—without workarounds.

Step 4: Cut everything else ruthlessly.

What about:

  • Sharing feedback with clients?
  • Time tracking?
  • Invoice integration?
  • Team collaboration?
  • Automated follow-ups?

All great ideas. All V2 or later.

Step 5: Build that path to 100%.

Not 80%. Not “mostly works.” 100%.

Because if it’s 80%, Sarah still has to use her old system as a backup. And if she’s using two systems, she’ll use neither.

Here’s the template I use:

“This helps [specific user] [complete specific task] so they can [achieve specific outcome].”

For Sarah: “This helps freelance designers capture and organize client feedback so they can find what they need when making revisions.”

One sentence. One user. One task. One outcome.

If you can’t write this sentence, your MVP is too broad.

Real Examples of Narrow But Complete

Let’s look at some products that got this right:

99 Minds (my product)

V1 was: Voice capture + AI organization + search.

Not: Sharing, collaboration, export, integrations with other tools, mobile app, web clipper, calendar sync, task management.

Just: Speak your thoughts, we organize them, you search them later.

Narrow? Extremely. One user (me), one problem (brain dump overload), one workflow (capture → organize → retrieve).

Complete? Totally. I could fully accomplish my goal without workarounds.

Result: I used it every day. So did early users. Because it worked.

Stripe (the famous example)

V1 was: Accept credit card payments via API.

Not: Subscriptions, billing, invoicing, fraud detection, tax handling, multi-currency, connect, terminal.

Just: Drop in 7 lines of code, charge a card.

Narrow? Yes. One user (developer), one problem (accepting payments is hell), one workflow (integrate and charge).

Complete? Absolutely. Developers could go from “no payments” to “accepting payments” in 10 minutes.

Result: Became the default. Because it worked.

Instagram (before it was Instagram)

V1 was: Post a photo, apply a filter, share to feed.

Not: Stories, video, DMs, shopping, reels, IGTV, live streaming, hashtag following.

Just: Make your phone photos look better, share them.

Narrow? Very. One user (iPhone owner who wants better photos), one problem (phone photos look meh), one workflow (shoot → filter → post).

Complete? Yes. You could fully accomplish the goal—sharing a good-looking photo—in 30 seconds.

Result: 100M users in two years.

Superhuman (the modern example)

V1 was: Email, but faster.

Not: Calendar, tasks, notes, CRM, document collaboration, video calls, project management.

Just: Email. But every interaction is keyboard-driven, instant, and delightful.

Narrow? Insanely. One user (busy professional), one problem (email is slow and painful), one workflow (inbox zero, fast).

Complete? Completely. You can fully manage email—better than any other tool.

Result: Cult following, $30/month price point, profitable.

What They Have in Common

Look at these examples. What do they share?

They all do one thing so well that users can’t imagine not using them.

That’s the test.

If someone tries your MVP and thinks “this is neat, but I can’t fully switch because it doesn’t do X,” you’re not narrow-but-complete yet.

If they think “holy shit, this solves my problem better than anything else,” you nailed it.

Iconic minimal products that succeeded through focused excellence

How to Know What to Cut

The hardest part isn’t understanding the rule. It’s applying it. Because every feature sounds important when you’re building.

Here are the questions I ask:

Question 1: Is this required for the core workflow?

If you removed it, could users still accomplish their primary goal? If yes, cut it.

For 99 Minds, “share with team” is not required for “capture my thoughts.” Cut.

Question 2: The 3-month test.

“If we can only ship 3 features in 3 months, which 3?”

Whatever makes that list stays. Everything else is V2.

Question 3: The embarrassment test.

“Would I charge money if this feature was missing?”

If you’d be embarrassed to charge without it, it’s core. If not, it’s nice-to-have.

Question 4: The substitution test.

“Can users work around this temporarily with an existing tool?”

If yes—even if it’s annoying—cut it.

Example: Export to CSV. Users can manually copy/paste for now. Not ideal, but not a blocker.

Question 5: Be ruthless.

Your mantra: “That’s a great idea for V2.”

Say it out loud. Write it in your notes doc. Actually plan for V2.

But don’t build it in V1.

The Expansion Strategy

So you ship narrow-but-complete. Now what?

Here’s the pattern:

V1: Narrow but complete → Launch, get users, validate

V2: Add one adjacent narrow-but-complete workflow → Keep it focused, ship it fully

V3: Connect workflows, add power-user features → Now you’re expanding thoughtfully

Don’t: Try to do V3 as your MVP.

Example with 99 Minds:

  • V1: Solo voice capture → organize → search
  • V2: Share specific notes with others (complete sharing workflow)
  • V3: Team workspaces, integrations, advanced search

Notice: Each version adds one complete thing, not five half-things.

This is how you expand without losing focus. Stripe did this. Instagram did this. Notion did this.

All started narrow. All expanded intentionally.

Architectural metaphor: building depth before breadth, focused growth strategy

When Narrow Goes Too Narrow

Can you go too narrow? Yes.

Warning sign 1: The market is too small.

If your “specific user” is so specific that only 100 people exist, you’ve overfit.

Solution: Zoom out slightly. “Freelance designers” → “Solo creative professionals.”

Warning sign 2: Users keep asking for the same missing feature.

If 80% of users say “I love this, but I need X to fully switch,” X might be part of the core workflow.

Solution: Re-evaluate. Maybe X is narrow-but-complete, and you cut too much.

Warning sign 3: The core workflow requires features you cut.

If users have to hack together workarounds to complete the basic task, you’re incomplete, not narrow.

Solution: Add back what’s required for end-to-end completion.

The balance: Narrow enough to ship fast. Broad enough to matter.

Why This Beats Feature Parity

Here’s the trap: You look at competitors and think “they have 50 features, I need 50 features.”

Wrong.

Established products have: 100 features, you use 10, you ignore 90, and you’re annoyed by the clutter.

Your MVP should have: 3 features, you love all 3, zero wasted clicks.

Compete on depth, not breadth.

Users are willing to sacrifice features for quality. They’ll use a tool with fewer features if those features work better.

Superhuman vs. Gmail: Gmail has 10x the features. Superhuman has 10x the quality.

Which one do power users choose? Superhuman.

Because they don’t want more. They want better.

The Failure Story (Because I Learn More From Failures)

I once tried to build a “productivity dashboard.” The idea: Connect everything—calendar, tasks, email, notes, habits—into one interface.

Ambitious? Very. Narrow? Not at all.

I spent 6 months building half of everything:

  • Calendar sync (kinda worked)
  • Task import (buggy)
  • Email preview (slow)
  • Notes capture (half-baked)
  • Habit tracking (meh)

Result: Nothing worked well enough to use daily. I kept using my old tools because they worked better.

The product never shipped.

Why? I tried to do five things at 60% instead of one thing at 100%.

If I’d followed Narrow But Complete, I would’ve picked one of those—say, habit tracking—built it perfectly, and shipped it.

Would fewer people want it? Yes. Would the people who wanted it actually use it? Also yes.

And usage beats potential users every time.

The Success Story (To Balance It Out)

The law firm tool I mentioned in “Your MVP Is Trash.”

Initial scope: 8 features (document automation, client portal, time tracking, billing, task management, email integration, calendar sync, reporting).

I convinced them to narrow to 2: Document automation + client signatures.

Why those two? Because that’s the complete workflow attorneys needed most: Generate document → Send to client → Get signature → Done.

We built those two features to 100%. Everything worked. No workarounds needed.

Result: Attorneys started using it immediately. Paying for it. Referring others.

Then we added billing. Then time tracking. Then the rest.

But V1 was narrow, complete, and valuable.

That’s the rule in action.

Success through focus: celebrating validation and user adoption

Final Thoughts

Most products die in the “maybe someday” zone. Too ambitious to ship quickly, too unfocused to be great at anything.

Narrow But Complete fixes this.

Pick one user. One problem. One workflow. Build it completely. Ship it.

Everything else—every brilliant idea, every “wouldn’t it be cool if,” every competitor feature—can wait.

Because here’s the truth: Users don’t remember what you didn’t build. They remember what works.

Build narrow. Build complete. Ship it.

Then expand.

That’s how you win.

Share:
Back to Blog