A non-goal is not a phase-two ticket
Discovery decks often end with a tidy Out of scope slide: wholesale quotes, multi-region, the admin console, mobile offline. Underneath, someone has typed phase two. That label feels like boundary-setting. It is usually a soft deferral wearing formal clothes. A non-goal says this engagement will not build the thing. A phase-two ticket says we already promised it — just not this sprint. Mixing those two is how BuilderHelp scopes grow a second surface nobody estimated, and how a Sanity marketing build quietly inherits a campaign factory that was never in the signed intent.
Boundary and promise are different sentences
A non-goal answers: what related work are we explicitly not doing in this engagement, even though it sits next to the problem. No wholesale quote path beside the cart. No second print destination. No public API for partners. The sentence is useful when it could disappoint someone in the room.
A phase-two ticket answers: what we already intend to build later. It needs an owner, a revisit date, and a place on a real queue — the same discipline as a post-date cut list. It is still ambition. It is not a wall.
Teams blur them because both keep a stakeholder from arguing today. One removes the outcome from the contract. The other parks it with implied consent. Only the first shrinks what the estimate has to carry.
Vague non-goals do not hold
“This is just phase one” and “we are not solving every edge case” look like boundaries. They are not. They do not name a surface, a role, an integration, or a data migration. When the mid-build Slack ask arrives, there is nothing specific to point at.
Useful non-goals are concrete enough to disagree with: we will not migrate historical invoices; we will not ship a field-app session separate from the dashboard; we will not add a second CMS locale in this handover. If nobody flinches, the list is probably still soft.
We write them in the same scoping notes as the minimum coherent product — not as a footnote on a slide that never makes the signed scope. If the SOW only lists in-scope outcomes, every adjacent ask can claim it was implied.
Where phase-two language sneaks back in
The failure mode is predictable. A non-goal gets accepted in the workshop. Someone comforts the room with “we will pick it up in phase two.” Two weeks later the ticket exists in the backlog with no trade against the build list. Engineering treats it as sequenced work. Product treats it as already sold.
On Al’s Flowers that sounded like “gift messaging after Valentine.” Without a written non-goal, gift copy started showing up as a clarification on the order ticket. On Endeo it sounded like “accounts later” while account-shaped sync assumptions leaked into the offline path. The phrase phase two did not schedule anything. It prevented the cut from sticking.
If the work is truly later ambition, put it on the deferred queue with an owner and a revisit date — separate from the out-of-scope list. If it is not in this engagement at all, leave it off every backlog the builders open.
How we keep the lists from merging
Scoping notes carry three buckets, labeled in plain language: in scope for this engagement; deferred with owner and revisit; out of scope for this engagement. Deferred items can become change requests later. Out-of-scope items do not enter the build unless someone signs a change and trades something else out the same day.
When a mid-project ask maps to the out-of-scope list, we do not re-open estimation as if the workshop never happened. We classify it as a change — same as a clarification versus change split elsewhere — and we refuse the soft path of “it was always phase two.”
Agents and new teammates reading the repo will follow whatever queue exists. A phase-two epic next to active sprint work is an invitation. A short out-of-scope appendix in the signed notes is a constraint. Choose which document you want the next PR to obey.
What we check before calling discovery done
Every out-of-scope line names a concrete outcome someone might still want. None of those lines say phase two, later, or nice to have. Anything that is later work lives on a deferred list with an owner and a date — or it is not written as a promise at all.
The signed scope (or the decision pack we leave discovery with) repeats the non-goals, not only the build list. Mid-build, we can open that page and answer an adjacent ask without reconstructing workshop memory from Slack.
If those checks fail, the boundary was theater. The useful discipline is simple: non-goals cut work out of the engagement; deferred tickets schedule ambition; phase-two language that sits under Out of scope is neither.
Questions
- When should something be deferred instead of out of scope?
- When the engagement already intends to build it after the first ship, with an owner and a revisit date. If you are only calming the room, write a non-goal — do not invent a phase-two ticket.
- Can an out-of-scope item come back mid-build?
- Yes, as a signed change with a same-day trade against the build or cut list. It does not re-enter by being relabeled phase two.
- How specific do non-goals need to be?
- Specific enough that a stakeholder could disagree. Name the surface, role, integration, or migration. Vague “phase one only” lines do not survive contact with a Slack ask.
Sources
- VividMap — How to scope a technical project — Non-goals as the highest-leverage scoping section; vague “phase one” non-goals called out as useless.
- Acquaint Soft — Discovery phase and out-of-scope baselines — Without explicit out-of-scope items, scope expansion stays frictionless and hard to distinguish from change.
- Related: A fixed date is not a fixed scope — Cut lists and post-date queues are deferred ambition with rules — not out-of-scope theater.
- Related: Leave discovery with decisions, not a backlog