Teams with a new product idea often arrive at the first meeting with a long feature list. The list is usually reasonable; the problem is trying to fit all of it into version one. As the first release grows, the schedule stretches. The market changes, and by launch the assumptions behind the list may be out of date.
We ask three questions to narrow the scope. They are simple. What makes them work is recording the answers and moving every cut feature, by name, to a later-release list.
1. Will the first customer pay without this feature? #
The first question puts the customer before the feature. “Users will want this” is not enough. We ask whether a specific customer, doing a specific job, would keep using the product without it. If yes, the feature leaves the first release.
The first cuts are often reporting screens, detailed settings and a second user role. All three may matter as the product grows, but rarely determine the first customers’ decision.
2. Can this be done manually for a while? #
The second question examines the cost of using a person instead of software. Billing, welcome emails and data imports can be handled manually in the first months. Spending weeks building something that takes a few hours a week is often not the right investment for a first release.
We record manual tasks in a table: the task, its owner and weekly time spent. Once a row crosses a threshold agreed by the team, it becomes a candidate for the next release. Scope is then driven by tracked time rather than estimates.
3. What breaks if we add this after the first release? #
The third question reverses the logic. Some decisions cannot be postponed without changing everything: multi-tenant data architecture, user roles and payment foundations. They may be invisible on screen, but need to be established in the first release.
We therefore split scope into two columns: user-facing features and infrastructure decisions. We shorten the first and rarely shorten the second. Reverse that approach, and screens multiply while the foundations wait; version two can become a rewrite.
Our own product Reshape illustrates this decision. The storefront set and the system running the shop were built as separate layers from the outset. Changing the set leaves products, orders and settings intact. The separation is invisible on screen but costly to introduce later. Making design and development decisions together helps establish it. In our SaaS and business software work, the scope document uses these two columns.
What happens to cut features? #
A cut feature has three possible futures: it is added as planned, added in a different form based on early users’ requests, or never added. The first meeting cannot tell us which path each feature will take. That is why we keep the list rather than delete it.
The third group teaches us the most. A feature called “essential” in the first meeting may disappear from discussion once real users arrive. Narrowing scope saves more than time: it avoids work that later proves unnecessary.
How initial scoping works #
- Put the feature list in one table and answer all three questions for every row.
- Separate screens from infrastructure decisions.
- Keep cut features in the same table under “later release”.
- Assign an owner and a time-tracking measure to manual tasks.
- Have both sides approve the scope document, and record later changes in the same table.
This document becomes the shared reference throughout development, and the first place to look in schedule and scope discussions. We explain our approach for startups on the For Startups page.
Sources #
- The Lean Startup, Eric Ries; the source of the MVP concept
- Shape Up, Basecamp; defining scope and the “appetite” approach
