Skip to main content

Module 1.2: Scoping — Kill Your Darlings

Scoping is the hardest part of building an MVP. Not because it is technically complex — because it is emotionally painful. You have to look at your beautiful, feature-rich vision and hack it down to one thing. The features you cut are the ones you are most excited about. That is exactly why you need to cut them.

This lesson gives you a battle-tested framework for deciding what stays and what goes. By the end, you will have a one-page scope document that fits your 1-week timeline.

The Scope Equation

Every feature in your MVP must pass this test:

Does this feature directly help a user experience the core value proposition?

If the answer is no, cut it. If the answer is "kind of" or "it would be nice," cut it. If the answer is "yes, but only for power users," cut it. Only features that are essential for a first-time user to experience value should survive.

The One-Sentence Value Proposition

Before you can scope, you need to articulate your value proposition in exactly one sentence. Not a paragraph. One sentence.

Examples:

  • Bad: "We help businesses manage their customer relationships with AI-powered insights, automated follow-ups, and team collaboration tools."
  • Good: "We tell sales reps which leads to call today, ranked by likelihood to close."
  • Bad: "A project management platform with time tracking, resource allocation, Gantt charts, and integrations."
  • Good: "Freelancers track hours and send invoices in one click."

Notice the pattern: the good versions describe one specific action for one specific user. Write yours now before reading further.

The Feature Prioritization Matrix

Take every feature on your wish list and place it in one of four categories:

1. Core (Build This Week)

Features without which the product literally cannot deliver its value proposition. For our sales lead example: the lead list, the ranking algorithm, and a way to mark leads as contacted. That is it.

2. Important (Build in Week 2-4)

Features that make the product significantly better but are not required for initial value. Email integration, CRM sync, team dashboards. These are real features that real users will want — just not on day one.

3. Nice-to-Have (Build in Month 2-3)

Features that round out the product. Dark mode, mobile app, export to CSV, custom branding. Users will request these eventually, but nobody ever refused to pay for a product because it lacked dark mode.

4. Never (Kill These)

Features that sound good but do not actually serve your core user. Be honest with yourself. If a feature serves a different user persona than your primary target, it goes here.

The Practical Scoping Exercise

Here is how to run this exercise in under an hour:

  1. Brain dump (10 minutes): Write every feature you have ever imagined for this product on sticky notes or in a list. Do not filter — get everything out.
  2. Categorize (15 minutes): Place each feature in one of the four categories above. Be ruthless. If you are debating between Core and Important, it is Important.
  3. Estimate (15 minutes): For each Core feature, estimate how long it takes to build the simplest possible version. Not the good version — the version that works.
  4. Cut again (10 minutes): Add up your Core estimates. If they exceed 16-20 hours of coding time (about 2 days of focused work), you need to cut more. Move the least essential Core feature to Important.
  5. Write the scope doc (10 minutes): One page. What you are building, what you are explicitly not building, and your success criteria.

Scoping Patterns That Work

After building dozens of MVPs, we have seen consistent patterns in what to cut:

Cut: User Authentication

For your first 10 users, send them a magic link or use a simple password. Do not build OAuth, social login, or role-based access control. Use a service like Supabase Auth or Clerk that gives you auth in 15 minutes.

Cut: Admin Panels

You are the admin. Use the database directly, or build a simple script. Your first 10 users do not need self-service admin tools.

Cut: Notifications

Email notifications, push notifications, in-app notifications — all of these add complexity. For week one, if users need to check something, they open the app. You can manually email them if something important happens.

Cut: Onboarding Flows

For 10 users, you are the onboarding flow. Get on a call with each user, walk them through the product, and watch them use it. This is actually better than automated onboarding because you learn more.

Cut: Edge Cases

What happens if a user enters a 500-character name? What if they upload a 2GB file? What if they try to use the product in Internet Explorer? These are real problems — for week 4. In week one, tell your users what the constraints are and move on.

The Scope Document Template

Use this template for your one-page scope document:

## MVP Scope Document

### Value Proposition (1 sentence)
[Your one-sentence value prop]

### Target User
[One specific persona]

### Core Features (build this week)
- Feature 1: [brief description + estimate]
- Feature 2: [brief description + estimate]
- Feature 3: [brief description + estimate]

### Explicitly NOT Building
- [Feature A — reason]
- [Feature B — reason]
- [Feature C — reason]

### Success Criteria
- [Measurable outcome 1]
- [Measurable outcome 2]

### Known Limitations
- [Limitation 1 — acceptable because...]
- [Limitation 2 — acceptable because...]

The "Explicitly NOT Building" Section

This is the most important section of your scope document. Writing down what you are not building does three things:

  1. Prevents scope creep. When someone (including you) suggests a feature, you check the list. If it is there, the conversation is over.
  2. Communicates intentionality. It shows stakeholders you have thought about these features and made a deliberate decision — not that you forgot about them.
  3. Creates a roadmap. Your "not building" list is your week 2-4 backlog. You are not saying no forever — you are saying not yet.

Key Takeaway

Scoping is the highest-leverage activity in MVP development. An hour spent scoping saves days of building the wrong features. Use the prioritization matrix, be ruthless about cutting to Core features only, and document what you are explicitly not building. Your MVP should do one thing well, not ten things poorly.

In the next module, you will choose the technology stack that lets you build this scope in the time you have. Speed of development is the primary selection criterion — not scalability, not elegance, not what is trending on Hacker News.