Feature Scoping

Feature Scoping

> Part of the discovery-phase skill pack · scoping group · reads discovery-context.md (run profile-builder first if missing).

The boundary-drawing skill. Output is a scope doc precise enough that engineering can estimate it and the client can sign off on it. Built to be paste-able into a proposal or SoW (commercial documents) with minimal rework.

Step 1 — Read context

Read discovery-context.md (sections 3. Engagement, 5. Expected deliverable, 6. Constraints), opportunity-tree.md (solution direction), and risk-assumption-map.md (top assumptions to retire).

If discovery-context.md is missing, ask the BA inline: "(a) timeline + budget shape (days / weeks / month / quarter); (b) any hard constraints (NDA / regulatory / tech-stack lock-in)?" — tag the output [ASSUMED ENGAGEMENT]. If opportunity-tree.md is missing, ask for solution direction in one line, or proceed tagged [NO-SOLUTION-DIRECTION]. If risk-assumption-map.md is missing, ask for 1–3 top assumptions to retire, or proceed tagged [NO-RISK-FRAME]. Never block; recommend profile-builder / opportunity-mapping / risk-assumption-mapping for high-stakes work.

Step 2 — State the MVP job

One sentence. "The scope lets ` do in , such that ` is retired."

This anchors scope to assumption-retirement, not feature completeness.

Step 3 — Draw the scope line — 11 areas

Every row must have BOTH in and out. Ambiguity is where mid-build scope creep lives. If a row is genuinely "TBD", say so explicitly with a deadline for resolution, but don't leave blanks.

| Area | In | Out | |---|---|---| | Users / segments | Which segment / seats | Which segments excluded | | Core flow | The one happy path | Alternative flows | | Auth | Existing SSO / new login | Role-based permissions | | Data | Read / write, persistence | Migrations, historical data | | Integrations | The 1 must-have | All others | | UI polish | Rough / polished / designer-built | | | Error handling | Which errors shown, which swallowed | | | Observability | What we'll log to learn | Full prod telemetry | | Platforms | Web / mobile / CLI | | | Accessibility | A11y floor (e.g., keyboard-only ok, screen reader later) | | | i18n | English-only or specific languages | |

Step 4 — Define success metrics

Two pre-committed numbers:

• Leading metric — engagement signal during the build window (e.g., 40% of invited users complete core flow within 7 days)
• Lagging metric — the problem-canvas success signal at scope + 4 weeks

State pivot/kill thresholds (consumed by go-nogo-memo later).

Step 5 — Rollout boundary

Pick one based on engagement mode (per discovery-context.md section 3):

• Pre-sale demo: agency-hosted, no real users
• Discovery-sprint output: client internal dogfood
• Delivery-phase MVP: 5-10 friendlies, % feature flag on real users, or separate URL/product
• Staff aug: mirror client's existing rollout pattern

Include a rollback criterion ("if metric X drops below Y in 48h, disable flag").

Step 6 — Engineering size estimate

T-shirt: S (1 mo). If L, loop back to Step 3 and cut. Discovery-sprint scopes should be S or M.

The actual hour-level estimate is estimation skill's job. This skill produces the t-shirt for early reality-check.

Step 7 — Explicitly deferred list

5-15 bullet items titled "Explicitly deferred". This list gets referenced at every standup during build to prevent re-litigation. In a proposal/SoW context, this becomes the "Out of Scope" section.

Step 8 — Outsourcing-specific extras

Add at bottom:

• Assumptions of the client (from risk-assumption-map.md rows tagged [client] or [shared]) — what the client must do/provide for this scope to be valid
• Agency dependencies — what the agency needs from third parties or other team members

These flow directly into the proposal "what we need from you" / "our dependencies" sections.

Output

./discovery/scope-doc.md per ./template.md. Designed to be reused — proposal and sow-draft skills will pull sections from here verbatim.

Append to _log.md: [feature-scoping | YYYY-MM-DD] mvp_job: ; tshirt: ; deferred: ; client_assumptions: .

Anti-patterns

• Scope by feature list. Features without a user job create orphan UI. Lead with the job.
• Open-ended MVP. No date or success metric → not an MVP, just a build.
• Hidden auth/data/integration changes. "Just a small change to auth" is how 3-week projects become 3-month projects. Put it explicitly in in or out.
• Scope identical to opportunity-tree. OST names solutions; scope picks one slice of one solution. Same size = scope is too big.
• Skipping assumptions/dependencies for outsourcing. These exist in any internal scope too, but in outsourcing they become legally/commercially load-bearing. Be explicit.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: stanislavnianko
• Source: stanislavnianko/product-discovery-claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.