The answer in brief

Reduce scope by identifying the one experience the project must deliver, then removing every feature that is not necessary for that experience to begin, develop, and end. The smallest finishable version is not a fragment. It is a complete promise sized to the people, time, money, and skills actually available.

Why does reducing scope feel like betraying the idea?

Creators often meet an idea in its largest form. A world arrives with history, characters, mechanics, images, sequels, and business possibilities already attached. Cutting any part can feel like cutting the identity of the project.

That is why scope discussions become emotional. We confuse the project we may build over years with the version we can finish now.

In the book, I describe a science fiction role-playing game that had grown into a roughly 300-page rulebook. The world was full of professions, planets, danger, character possibilities, and a tone shaped by the action films we loved. The game worked in playtests, but the book was not ready for another person to buy and use.

We did not respond by reducing the promise. We added a publishing plan, professional writing and illustration needs, a reseller relationship, a catalog, a national advertisement, a website, payment handling, purchasing, packing, and shipping.

The idea did not die from being too small. The delivery system collapsed under what we asked it to carry.

What is the core experience?

The core experience is the change or encounter that must survive every cut.

For a role-playing game, it might be that a group creates characters, enters one dangerous situation, makes meaningful choices, and reaches an outcome using the rules.

For a short film, it might be that the audience follows one character through one irreversible decision.

For a production service, it might be that a client submits approved material and receives one usable finished deliverable by a stated date.

Write the core experience without describing scale, prestige, or future expansion. If the sentence depends on several formats, a large cast, a marketplace, or a complete fictional universe, it is probably describing the dream rather than the first finished version.

How do you cut scope without producing a demo?

A demo shows potential. A minimum finishable version completes a promise.

The difference is an ending and an acceptance condition. A playable game needs enough material to complete a session, not merely create a character. A film needs final picture and sound, not merely a compelling teaser. A publication needs a complete reader journey, not three designed chapters and a list of what is coming.

Protect three elements:

  • Entry: The audience can begin without private explanation.
  • Experience: The central value or story is actually present.
  • Exit: The work reaches a clear end and can be delivered, reviewed, or used.

Everything else must argue for its place.

Which features should be removed first?

Remove features that create entire new departments.

A second location can create transport, permission, sound, lighting, art, and schedule needs. An online shop can create catalog, payment, support, fulfillment, and inventory needs. A larger fictional world can create more rules, illustrations, testing, and explanation.

Use a dependency test:

  • Does this feature require a new person or specialized skill?
  • Does it create a new approval path?
  • Does it add a location, format, platform, or delivery method?
  • Does it require knowledge the team does not yet possess?
  • Can the core experience remain intact without it?
  • Would removing it shorten the route to a complete artifact?

If the answer points toward removal, move the feature to the next-version file.

How should resources define the version?

List what exists before listing what you hope to secure.

Count the people who have actually committed. Name the hours they can give. Identify the tools they can already operate. Confirm the locations, equipment, money, and review capacity currently available.

Then design the version around that reality.

Our early business plan depended on people whose participation was tied to personal relationships, skills we did not control, and a fulfillment process we had never completed. When those links broke, the project had no smaller operational core to fall back on.

A finishable version minimizes critical dependencies. It may still require courage and hard work. It should not require every uncertain condition to become favorable at once.

What belongs in a minimum finishable version brief?

Create a one-page brief before production expands.

  • Core audience
  • Core experience
  • Finished artifact
  • Maximum running time, page count, or feature count
  • Available team and hours
  • Essential tools and locations
  • Required beginning, middle, and end
  • Acceptance condition
  • Delivery date
  • Explicit exclusions
  • Candidate additions for the next version

Ask someone outside the project to read the brief. If they cannot tell what will exist and what is excluded, the scope is still moving.

Small is not the goal by itself. Complete is the goal. Small is the strategy that lets an independent team reach it.

Finish one true version. Then let evidence, audience response, and new capacity decide what deserves to grow.

Next production note

A well-sized idea still needs a working path from interest to delivery.

Continue to: A Good Idea Still Needs an Operating System

Notes From the Director Learn the craft. Build the system. Make the film.

Source note

This article is adapted from No One Gives a F Until It's Done, PDF pages 13-18. Wayne's Galactic Battles and game-store effort provides the production example of scope expanding beyond the team's delivery capacity.