Essential Feature Set¶
Requirements artifact — instantiates Minimum Sufficient Solution
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.
An Essential Feature Set is the durable, named artifact that lists the capabilities a solution genuinely must have to do its job — and, just as importantly, the list of everything wanted-but-not-required, parked where everyone can see it. Its defining move is that it is a standing document, not an act: it does not grade proposals or test a build, it records the roster. Each entry earns its place by being traceable to the core job and to a concrete person who needs it; a capability nobody can attach to a real task is the tell that it belongs on the parked list. The artifact's whole value is that it turns "what's in scope?" from a recurring argument into a single object a team can point at, contest, and revise.
Example¶
A hardware startup is building its first smart thermostat and has a wishlist of forty features. The Essential Feature Set names the seven the product cannot ship without: read the room temperature, hold a setpoint, run a daily schedule, accept a manual override, show a legible display, fail safe to a default temperature if the network drops, and match the wiring in ordinary homes. Each is written next to the person it serves — "a homeowner who wants the house warm by 6am" sits beside the schedule capability; "an installer working in a dark utility closet" sits beside wiring compatibility. Geofencing, energy reports, voice control, and multi-zone support are all real and all wanted, so none are deleted — they go onto a labeled backlog, each tagged with who asked for it and why it was deferred. When a stakeholder later insists voice control is "obviously required," the team opens the artifact: no shipped-thermostat task depends on it, so it stays parked, on the record, with an owner.
How it works¶
- Anchor every candidate to the core job. A capability is admitted only if it is traceable to the stated core job — not because it is possible, requested, or fashionable.
- Trace each admitted capability to a named need. Write the concrete user and the task beside every entry; an entry with no traceable task is a signal to move it to the backlog.
- Park, don't delete. Wanted-but-nonessential capabilities are recorded with requester and rationale, so deferral is accountable rather than silent.
- Keep it as a living object. The set is re-derived as the requirement sharpens; it is consumed by the roadmap and build, not filed away.
Tuning parameters¶
- Inclusion strictness — how hard the "would it fail without this?" bar is set. Stricter yields a leaner ship but risks omitting a capability that turns out load-bearing.
- Entry granularity — whether entries are coarse capabilities or fine features. Finer entries trace to needs more precisely but multiply the maintenance of the artifact.
- Trace depth — how much evidence of need each entry must carry, from a name to a validated task. Deeper traces resist pet-feature smuggling but slow the drafting.
- Backlog prominence — how visibly parked items are surfaced. High visibility guards against silent neglect but invites renewed scope pressure.
When it helps, and when it misleads¶
Its strength is making the solution boundary a concrete, contestable object: "possible" stops being a synonym for "required," and the parked list keeps every deferral honest and revivable. Its failure mode is that the set is only as trustworthy as the need-traces behind it — a team can smuggle a favorite feature in by inventing a hypothetical user, dressing up a delighter as a basic need in Kano terms.[n1] The classic misuse is freezing the artifact and letting the backlog rot into a graveyard nobody revisits. The guarding discipline is to require a named stakeholder and a concrete task for every "in," and to keep the parked list alive with owners rather than treating it as a place things go to die.
How it implements the components¶
core_requirement— the set is the enumerated answer to "what must this solution do"; every admitted capability is justified against that core job.stakeholder_need_trace— each essential capability is written beside the named person and task it serves, so no entry survives without a traceable need.deferred_enhancement_backlog— the parked "later" list, each item tagged with requester and reason, is a first-class half of the artifact.
It records which capabilities are in, but it does not run the graded per-item nonessential_feature_filter sort that decides them one at a time — that is Must/Should/Could Filter, its nearest twin — and it never runs a live sufficiency_test to confirm the shipped set actually works, which is Pilotable Solution's job.
Related¶
- Instantiates: Minimum Sufficient Solution — the essential feature set is the artifact form of the archetype, naming the smallest capability roster that does the job.
- Consumes: Must/Should/Could Filter supplies the graded verdicts the roster records as "in" or "parked."
- Sibling mechanisms: Must/Should/Could Filter · Lean Policy Design · Minimum Viable Documentation · MVP-like Scoping · Pilotable Solution · Simple Intervention Package · Minimum Viable Process
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Essential Feature Set operates as a non-executable information artifact that externalizes static or prospective structure because it 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.
Independent corroboration: The frozen evidence defines Essential Feature Set as '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', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Requirements engineering cohered explicit minimum capability sets traceable to stakeholder needs and separated from desirable backlog items.
Related originating lineages:
- Computer Science & Software Engineering — Software product requirements supply durable scope baselines and requirement traceability.
- Innovation & Entrepreneurship — Minimum viable product practice supplied a parallel focus on the smallest feature set that delivers the core job.
Review resolution: The current reviewers agree that engineering_design is primary. For the reported differences (reported_ambiguity, alternate_origin_disagreement, origin_mode_disagreement), the evidence supports convergent, multi_domain, and computer_science, innovation_entrepreneurship; these choices preserve materially formative origins without conflating later domain reach.
Attribution caveat: Essential requirements and MVP scope overlap but have different validation standards.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The set is an artifact; the Must/Should/Could Filter is the act that populates it. Keeping the two apart is what lets a team improve its sorting rule without rewriting the roster, and vice versa — and it is why the same essential feature set can survive several rounds of re-triage as the requirement sharpens.
[n1] The Kano model (Noriaki Kano) separates must-be qualities — whose absence makes a product unacceptable — from performance and delighter qualities that add appeal but are not required. Confusing a delighter for a must-be is exactly how nonessential features sneak onto an "essential" list. ↩