Skip to content

Minimum Sufficient Solution

Implement the smallest solution that satisfies the core requirement without unnecessary features, scope, or complexity.

Solution archetype #
638
Problem family
Complexity, Entanglement & Change Burden
Problem subfamily
Unearned Scope & Accidental Complexity

The Diagnostic Story

Symptom: The scope keeps expanding before the core requirement is stable. Features, process steps, controls, and variants are added because they might be needed, because a stakeholder asked, or because they seem like good ideas. Delivery slips, the solution becomes harder to maintain, and the additional complexity makes it harder to see whether the essential requirement is actually met.

Pivot: State the core requirement explicitly. Identify the invariants that must be protected — safety, legality, accessibility, operational usability — and filter out everything that does not serve those constraints or the core requirement itself. Validate that the remainder is sufficient, and define the explicit trigger that would justify adding scope back.

Resolution: Delivery is faster and the result is easier to maintain because it reflects only what the requirement actually needed. The sufficiency boundary is legible, so the team can make principled decisions about what to add next rather than accumulating features by default. The expansion path is preserved, but expansion requires evidence rather than speculation.

Reach for this when you hear…

[startup product] “We spent three months building the admin dashboard before we had a single paying customer — turns out none of them cared about the dashboard.”

[emergency response] “In the field you need a protocol that gets you to the right answer with what you have, not the optimal protocol for ideal conditions.”

[regulatory drafting] “Every exception we add to make the rule more precise creates a new loophole — sometimes the best rule is the shortest one that covers the core case.”

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

A solution effort expands beyond the essential requirement, increasing cost, delay, maintenance burden, implementation risk, user confusion, or governance overhead before the extra scope has earned its place.

What this problem means

The structural problem is overbuilding before sufficiency has been defined. A project, process, policy, product, or intervention grows by accretion: one feature for a possible user, one approval for a possible failure, one extra document for a possible handoff, one dashboard for a possible report. Each addition may sound reasonable in isolation, but the combined solution becomes slower, harder to use, harder to maintain, and harder to change.

The deeper tension is that incomplete solutions can fail, but excessive solutions also fail. Overbuilt solutions consume implementation capacity, confuse users, create maintenance obligations, and delay the moment when the core need is actually served.

Show the applicability expression

Applicability expression4 distinct conditions

Additions precede stable coreandSpeculative needs delay deliveryandRequests default to requirementsandSolution-induced complexity drag
Algebraic1∧2∧3∧4

groundedpartly groundedopen

4 conditions, all required.

4Required in every casenumbered 1–4

These hold no matter which pattern applies.

1

Additions precede stable core · open

Features, process steps, controls, or deliverables are added before the core requirement is stable.

2

Speculative needs delay delivery · grounded

Delivery is delayed by implementation of speculative future needs.

3

Requests default to requirements · open

Stakeholder requests are promoted to requirements by default rather than tested against the core need.

4

Solution-induced complexity drag · grounded

Removable complexity introduced by the chosen solution approach creates operational or cognitive drag.

Other requirements and context (1)

Why these sit outside the expression

Deployment constraint — it constrains how the intervention must be deployed, not the situation that calls for it.

  • Deployment constraintThe system needs a usable solution under limited time, budget, attention, or implementation capacity.

Coverage

2 of 4 conditions grounded · 2 open.

Read the methodologyDownload the trigger-logic data

Mechanisms / Implementations

  • MVP-like Scoping: Draws the smallest product boundary that delivers the core value and lays the roadmap by which deferred scope returns.
  • Minimum Viable Process: Runs the smallest real version of a workflow that still does actual work, to reveal handoffs, exceptions, and throughput before formalizing it.
  • Lean Policy Design: Builds the simplest rule that achieves a governance purpose while protecting the non-negotiable invariants, with an exception path for the cases it cannot foresee.
  • Essential Feature Set: Names the capabilities a solution must have to work at all, tracing each to a real stakeholder need and parking the rest in a visible backlog.
  • Minimum Viable Documentation: Writes only the documentation a real operator needs to act, maintain, hand off, and escalate — and proves it by having a fresh reader complete the task.
  • Simple Intervention Package: Bundles the few active ingredients that actually drive a target effect, with a referral path for the cases the standard package cannot reach.
  • Pilotable Solution: Runs the scoped-down solution in one bounded setting to prove it actually satisfies the requirement before committing to a full build.
  • Must/Should/Could Filter and Scope-Cut Review: Must/Should/Could filters and scope-cut reviews are practical sorting mechanisms.
  • Must/Should/Could Filter: Sorts every proposed piece of scope into must / should / could / won't-now tiers so a team can defend a smaller release item by item.
  • Scope-Cut Review

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

Also references 8 related abstractions

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Minimum Viable Process · implementation variant · recognized

Use the smallest process that reliably performs the required coordination, control, or governance function.

Essential Feature Set · subtype · recognized

Define the smallest set of features or capabilities that lets the solution satisfy the core user or system need.

Minimum Viable Documentation · implementation variant · recognized

Create the smallest documentation package that lets the intended users operate, maintain, audit, or hand off the solution safely.

Simple Intervention Package · implementation variant · candidate

Bundle the few intervention elements required to produce the target effect while leaving optional supports out until needed.

Editorial Notes

Problem Classification

Classification: Complexity, Entanglement & Change Burden → Unearned Scope & Accidental Complexity

Problem kernel: solution scope expands beyond essential requirements

Rationale: Earliest causal condition: A solution effort expands beyond the essential requirement, increasing cost, delay, maintenance burden, implementation risk, user confusion, or governance overhead before the extra scope has earned its place.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A solution effort expands beyond the essential requirement, increasing cost, delay, maintenance burden, implementation risk, user confusion, or governance overhead before the extra scope has earned its place. That is a unearned scope and accidental complexity problem because A design, model, process, or successor system acquires more features, assumptions, detail, and support burden than its demonstrated purpose, evidence, understanding, or value warrants.

Review outcome: Independent reviewer agreement; high confidence.