Problem-First Intake Template¶
Intake template — instantiates Tool-Repertoire Bias Counterbalancing
Captures the need — outcome, stakeholders, constraints, evidence, uncertainty — in problem-first language and fixes how success will be judged, all before any tool, method, or category is named.
A Problem-First Intake Template is a structured front door that refuses to let a request be written in solution language. Its single defining move is ordering: the person describing the situation must state the desired outcome, who is affected, the constraints, the evidence in hand, and what remains uncertain — and must state what would count as having solved it — before any field asks which method, product, specialty, ticket category, or dashboard metric applies. By fixing the need and its success test first, the template denies the local toolset its usual privilege of deciding what the problem is. Everything downstream then has an independent anchor to be justified against, rather than a description that was already shaped to fit whatever tool the intake-taker happened to reach for.
Example¶
A city's human-services office receives a walk-in: a mother of two is about to lose her apartment. The old intake form opened with "Which program are you applying for?" — and every caseworker who used it quietly steered the person toward the benefit line they knew best, so a housing crisis became a "SNAP case" or a "childcare voucher case" depending on who was at the desk.
The redesigned Problem-First Intake Template opens differently. The first block reads: desired outcome ("stable housing within 30 days without the children changing schools"), affected parties, hard constraints (no car, works nights), evidence already available (eviction notice dated, income stubs), and what we don't yet know (whether back-rent assistance or a rapid-rehousing slot fits). Only after all of that is filled does the form reveal the program checklist. The final block is the success test: "we will consider this resolved when the family has a signed lease or a documented alternative they accepted." When the caseworker finally reaches the program menu, the housing need is already on paper in the family's terms — and it is now obvious that the childcare voucher, however easy to issue, would not clear the stated success test.
How it works¶
The template's leverage is entirely in structure, not content:
- Sequenced fields. Need, stakeholders, constraints, evidence, and uncertainty come first; any tool/category/method field is gated behind them and often on a later screen so it cannot bleed backward into the description.
- A solution-language check. Free-text fields are lightly screened (by the taker, or a simple prompt) for premature method words — "training," "the ticketing system," "a policy fix" — which are bounced back to be restated as needs.
- An explicit success clause. A required sentence states what observable state would count as solving this need, phrased against the stakeholder, not against any tool's native output.
The artifact is deliberately shallow: it produces a clean problem statement and a success test, and then hands off. It does not choose or evaluate a tool.
Tuning parameters¶
- Field depth — from a three-line quick-capture to a full structured interview. Deeper intake catches more hidden constraints but adds friction and can annoy repeat cases that genuinely are routine.
- Solution-language strictness — how aggressively method words are bounced. Strict screening protects the frame but slows takers who think in tool terms; loose screening is faster but lets the tool creep back in.
- Success-clause specificity — a vague "resolve the housing issue" versus a checkable "signed lease or accepted alternative." Sharper clauses make later validity checks possible but demand more up front.
- Gating hardness — whether the tool/category menu is truly hidden until the need is complete, or merely below it. Harder gating is more effective and more irritating.
When it helps, and when it misleads¶
Its strength is prevention at the cheapest possible point: a need captured in the stakeholder's own terms simply costs less to protect than one that must be reconstructed after a tool has already reshaped it. It is the lightest mechanism in the archetype and the one most worth making universal.
Its failure mode is that a template captures only what its fields invite, so a tool-shaped form still produces tool-shaped needs, one level up. A "success" field can also quietly become a place to record the metric that is easiest to measure rather than the outcome that matters — the McNamara fallacy in miniature, where the quantifiable crowds out the real[1]. And strict intake can degrade into ritual: fields filled to satisfy the form, not to describe the world. The guarding discipline is to keep the success clause phrased against the affected party and to periodically read a sample of completed intakes asking "would the person described recognize their own problem here?"
How it implements the components¶
problem_first_restated_need— this is the template's core output: the need stated as outcome, stakeholders, constraints, evidence, and uncertainty, with method language screened out.outcome_validity_check— the required success clause fixes, at intake, the stakeholder-referenced test against which any later tool's result must be judged; it sets up the check that others will later perform.
It does not map the toolset (tool_repertoire_map, done by the Tool Repertoire Inventory) and it does not block anyone from reaching for a tool — that gate is tool_fit_gate, held by its nearest front-of-process twin, the Favored-Tool Pause Rule; intake writes down the need, the pause rule withholds the tool.
Related¶
- Instantiates: Tool-Repertoire Bias Counterbalancing — supplies the problem-first anchor the whole pattern is justified against.
- Sibling mechanisms: Favored-Tool Pause Rule · Tool Repertoire Inventory · Affordance Blind-Spot Walkthrough · Alternative-Tool Red Team · Representation Fit Scorecard · Borrow-or-Refer Protocol · Residual Case Log · Tool-Mismatch Postmortem
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: The mechanism is a sequenced intake surface that elicits need, stakeholders, constraints, evidence, uncertainty, and success before allowing solution language.
Nearest alternative: Representation, Specification & Plan — The completed intake is information, but the point-of-entry affordance shapes what contributors enter.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Problem framing before solution selection is canonical engineering and design-methodology practice.
Related originating lineages:
- Human-Computer Interaction — The human_computer_interaction tradition materially shaped Problem-First Intake Template through its own practice of interface disclosure, user guidance, interaction design, and cognitive load.
- Organizational & Management Science — Problem-First Intake Template is most plausibly rooted in the organizational_management tradition because its characteristic form depends on the coordination, governance, learning, and redesign of organized work. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of engineering design. NASA Systems Engineering Handbook: Problem Definition and System Boundaries documents the defining practice, history, or theory described in the selected origin rationale. Other domains are retained only where the blind reviews identify material co-development or translation; broad later application is recorded separately as domain_reach=universal, while origin_mode=cross_disciplinary_synthesis describes the relationship among formative lineages.
Attribution caveat: The blind-review boundary with organizational management is substantive: those traditions materially developed, translated, or operationalized part of the mechanism. The cited provenance places its defining lineage in engineering design.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
References¶
[1] Muller, J. Z. The Tyranny of Metrics. Princeton University Press (2018). Describes the McNamara fallacy as privileging what is quantifiable over outcomes that matter. registry ↩