Field notes / Startup & Product
Scoping a software build before you estimate it
A practical way to turn an ambiguous software request into a reviewable scope: outcome, constraints, exclusions, acceptance checks, and ownership.
A request for “a booking feature” is not a scope. It is the beginning of a conversation. Before estimating, I want to know which user needs to do what, what already exists, and how we will tell whether the result works.
The useful output is a small agreement that a product owner and an engineer can both inspect. It should expose uncertainty rather than hide it inside a confident delivery date.
Start with one observable outcome
Consider a hypothetical booking product. The initial request includes calendar sync, recurring appointments, reminders, staff availability, and payments. Trying to estimate that list immediately makes every unknown look like implementation work.
A smaller outcome is: a visitor chooses an available slot, submits their details, and receives a clear confirmation. The owner can find the booking afterward. This is an illustrative example, not a client engagement or a delivery promise.
Write the outcome in a sentence, then describe what the user sees before and after the action. Ask who can accept the work. If the answer changes between conversations, the scope is not ready yet.
Software build: brief to estimate
A brief is ready for estimation when the user problem, constraints, exclusions, and acceptance checks are explicit.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Flowchart from a software build brief through user problem, constraints, exclusions, and acceptance checks to an estimate-ready scope. A brief is ready for estimation when the user problem, constraints, exclusions, and acceptance checks are explicit.
Make constraints and dependencies visible
The booking flow may depend on an existing calendar API, account access, usable test data, and an owner who can answer questions. Those dependencies are not footnotes. They affect which implementation options are realistic and which parts of an estimate are conditional.
Record the current platform, who owns each external system, security boundaries, and any immovable dates. Separate a real deadline from a preferred date. For every unresolved dependency, name a next action and the person who can resolve it.
If access to the calendar is not available, a useful next step might be an integration spike with a fake calendar adapter. The output of that spike is evidence about the contract, not a claim that the full feature is nearly finished.
Write down what this release excludes
For the example release, reminders and recurring appointments can be explicit exclusions. Calendar access can be an external dependency. The basic booking and confirmation flow can be included work.
Draw the boundary before the estimate
An illustrative scope for an appointment-booking release; this is a planning example, not a client result.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Three scope cards for an example booking release: included booking flow, external calendar dependency, and deferred reminders. An illustrative scope for an appointment-booking release; this is a planning example, not a client result.
Exclusions make a scope more useful. They give both sides a way to recognize a new request. If recurring appointments become necessary, revisit the scope, estimate, and acceptance checks together. Do not quietly absorb the change and keep an obsolete commitment in place.
Define acceptance before implementation
For this booking slice, useful checks include:
- A visitor can select a slot that is actually available.
- A failed save does not display a success confirmation.
- Retrying an unchanged request does not create a second booking.
- The owner can identify the saved booking and its status.
- Someone is responsible for diagnosing a failed integration after handoff.
These checks cover behavior and ownership. They do not prescribe every internal function or force a particular framework. An engineer should still be able to choose a simpler implementation that meets the agreed outcome.
Estimate the known work and name the unknowns
An estimate should make its assumptions readable. State which slice it covers, which dependencies must hold, and where uncertainty remains. A range with clear assumptions can be more useful than a precise number built on missing information.
Use review points to learn. After the integration spike, review the contract. After the first working flow, review the user experience. Before handoff, verify how someone else will run and change the system.
The test of a good scope is whether a new person can understand what will be delivered, what will not, and how the team will decide that it works.
Put the scope to work
The SaaS MVP guide provides more context for choosing a useful first release. For the delivery side, duplicate-safe workflows explain one of the failure modes the booking example needs to handle.
If you have a product that needs to move, discuss a contract build. Bring the problem and the constraints; a rough brief is enough to start.
From the idea to the work
Make the workflow useful in a real product.
Bring a product idea, an internal tool, or an AI-assisted workflow that needs a working implementation.