The Scope Compression Session: How I Cut Every 0→1 Product to Its Irreducible Core

The Problem Nobody Names

I have sat in enough product kickoffs to know what the first hour sounds like. The founder has a clear vision. The features are already planned. The roadmap exists. The team is aligned.

And the scope is too big by a factor of three.

This is not a failure of ambition. It is a failure of compression. The founder built the roadmap from everything they know about the problem. They included the edge cases because the edge cases are real. They added the integration because a customer asked for it. They kept the reporting module because it was in the first deck.

By the time I get involved, the MVP is no longer minimal. It is a mid-stage product plan dressed up in MVP language.

The scope compression session is what I run to fix this. It is the first thing I do in every 0→1 engagement, before any design work, before any sprint planning, before any team structure conversations. It is one day of structured pressure on the product definition. The output is a scope document that the team can actually ship in six to ten weeks.

What Scope Compression Is Not

Scope compression is not cutting features randomly. It is not asking "what can we remove?" and waiting for people to volunteer their favourite ideas. It is not a negotiation about what the product manager can live without.

It is a structured argument for what the product must do on day one to earn the right to exist.

The distinction matters because it changes who is doing the reasoning. Random cutting produces a product that does less. Compression produces a product that does one thing precisely enough to generate signal.

Signal is what a 0→1 product is for. Not revenue, not retention, not NPS. Signal. Evidence that the problem is real, that people will change their behaviour to solve it, that the proposed mechanism actually works. Everything else comes after signal.

The Three Questions

The compression session runs three questions in sequence. Each one narrows the scope. By the end, you have a definition that the team can build and ship without scope creep, because there is no room for it.

Question One: Who changes their behaviour on day one?

Not "who is the target customer." Behaviour change is harder to answer and more honest.

The feature list grows because founders think about customer segments, and segments are large. Behaviour change forces precision. You cannot say "small business owners" and then describe a behaviour change. You have to say "a Malaysian F&B operator who currently tracks stock in a WhatsApp group and loses an average of RM 400 per month to ordering errors."

That specificity cuts two thirds of the feature set immediately. Because the WhatsApp F&B operator does not need a reporting dashboard on day one. They need one thing to work reliably enough that they stop using the WhatsApp group.

Run this question until the founder can name the behaviour change in one sentence. Not a persona, not a segment, a specific action that currently happens and will happen differently when the product exists.

Question Two: What is the one mechanism that produces that change?

Not "what does the product do." The mechanism.

A product does many things. The mechanism is the single causal chain that connects the user's current problem to the behaviour change you identified in Question One. Everything else in the product is either support for that mechanism or noise.

In the F&B stock tracking example, the mechanism is not "stock management software." The mechanism is "a shared view of current stock that updates when items are used, visible to everyone in the operation without a training requirement."

That is specific enough to scope. The shared view needs a data model and a display. The update trigger needs an input method. The visibility constraint rules out login-heavy architectures. Three product decisions fall out of the mechanism definition, and none of them require a dashboard, a reporting module, or a third-party integration.

Run this question until the founder can describe the mechanism without mentioning features. Features are implementations of mechanisms. The mechanism is what you are building.

Question Three: What is the minimum footprint that proves the mechanism works?

This is the compression step. You have a behaviour change and a mechanism. Now you cut everything that is not necessary to prove the mechanism in the hands of ten real users.

I use ten as the number deliberately. Not a thousand users, not product-market fit, not scale. Ten users who experience the mechanism, whose behaviour changes, and whose experience generates signal that the mechanism works.

The ten-user threshold is small enough that you can qualify each person individually. That changes what you need to build. You do not need onboarding flows for ten users. You do not need an automated billing system for ten users. You do not need a self-serve setup flow for ten users.

You need the mechanism to work. That is all.

Everything that is not the mechanism goes into a parking lot document. Not deleted, parked. The parking lot exists to absorb the team's ambition without letting it expand the sprint.

What Comes Out

The output of a scope compression session is three documents, none longer than two pages.

The mechanism statement. One paragraph. Describes the behaviour change, the causal chain, and the user who experiences it. This is the product definition. Not the vision, the definition. Anything that does not serve this statement is out of scope.

The ten-user test plan. Names, if possible. At minimum, a description of who the ten users are, how they will be recruited, and what observable evidence will confirm that the mechanism worked. This document prevents the team from treating "launched" as success. Launched is table stakes. The mechanism working in ten real users' hands is the success criterion.

The parking lot. Everything that was in scope before the session that is now deferred. This document is important because it answers the team's implicit question: "does the founder still care about the reporting module?" Yes. It is in the parking lot. We are building the mechanism first.

Why This Takes a Full Day

The session sounds simple. Three questions, three documents. Founders sometimes expect it to take two hours.

It takes a full day because the compression pressure is uncomfortable. Every time you apply Question One, someone will try to add a second behaviour change. Every time you apply Question Two, someone will describe a feature instead of a mechanism. Every time you apply Question Three, someone will argue that the ten-user test is not representative of the real market.

These arguments are not wrong. They are premature. The session's job is to hold the compression long enough that the team builds something they can ship and learn from, rather than something they are proud of but cannot finish.

I have run this session with a payments company that had forty features in their MVP and left with six. I have run it with a proptech team that was building a three-sided marketplace and left with one side. I have run it with a management accounting tool that was scoping a full ERP replacement and left with a single reconciliation workflow.

In each case, the team shipped faster than they had before. In each case, the mechanism worked or did not work within ten weeks, and the team had real signal to act on. In one case, the mechanism clearly did not work, and the team pivoted before they had spent six months building the wrong thing.

That last outcome is the one that matters most. Compression does not guarantee success. It guarantees that you find out faster.

The Rule I Apply Every Time

If the founder cannot describe the product's day-one success criterion in a single sentence, the scope is too large.

Not "we will have launched." Not "we will have X users." A sentence that names a specific behaviour change in a specific kind of user, caused by a specific mechanism, observable within a specific time window.

When that sentence exists, the scope falls out of it almost automatically. When it does not exist, no amount of sprint planning or feature prioritisation will save the project.

Compression is the work. Everything else is execution.