Phases 1–2 — the Mission & Requirements interview

The elicitation instrument for the front of the funnel: how you run the conversation that models the mission (Phase 1 — the system that exists, tool-neutral) and turns it into requirements (Phase 2 — the criteria). The goal is a requirements doc so well-scoped that a research brief can be written from it with no further questions. Everything structural — what a use case is, why a criterion sits on exactly one axis, the JSON shapes — lives elsewhere and is cited here; this file is only the interview.

Run it conversationally — don’t fire all of it at once. Lead with the recurring checklist below (it covers most of what matters in almost every selection), then dig into the engagement-specific layer. The checklist is meant to be read and edited by a human: treat it as a starting default, not gospel — confirm each item, strike the ones that don’t apply, add the ones unique to this engagement. If you’re maintaining the skill, this is the section to revise as you learn which questions keep earning their place.

Phrase every requirement as a use case the team already runs

A requirement is a use case the business runs today — often on paper, in Excel, or in someone’s head — never the tool that might do it. A tool name in a requirement (“a CRM”, “a knowledge base”) is the answer leaking into the question: it pre-commits the composition and quietly collapses use cases that sit at the same level. Model the system that exists first; tools come in Phase 4. The Fit criteria you write here should read as things the business does, with no product in them.

The interview’s job is to surface that use-case spine and capture each one as a transition — where the team copes today (Ist) and where it should land (Soll), since the deliverable is the delta, not the wish. Ask, for each use case: do you have any process for this today, or none? is it on paper / by hand, or already in a tool? and what would “better” actually be — stand it up at all, lift it into a system, sharpen it, or dock an assist on top? Watch for enablers while you do this — a supporting use case (e.g. a knowledge base that an ai-assist process needs to work) is itself a use case; name it the moment it surfaces so it earns its own requirements, don’t fold it into the process it serves. The use-case-spine semantics, the currentState/improvementLevel pairing, and the enables edge are defined in model.md — capture the answers here, let the model file own what they mean.

A. The recurring requirements checklist

These come up in nearly every selection. For each, decide: is it a hard filter (binary, eliminates on failure), a preference (scored, and at which weight), or not a requirement (name it explicitly — that’s valuable)?

1. Data protection / compliance. GDPR / DPA / SCCs, ISO 27001 or SOC 2, industry-specific regimes (HIPAA, etc.). Usually a hard filter for EU orgs. → Then ask the sharper question: is data residency actually required, or is compliance enough? Naming residency a non-requirement removes a whole false- disqualifier axis.
2. Language. UI and support language(s) the team needs. Often a hard filter (it eliminated two CRMs at EFI on a Dutch/French-only lock).
3. Hosting model. SaaS / cloud vs. self-hosted / on-prem. Tied to whether the team has any infrastructure capacity. Usually a hard filter one way or the other.
4. Approachability for the actual lead users. Who will use this daily, and how technical are they? If the lead users are non-technical, this is a critical (×5) preference, not a footnote — comfort is a decisive criterion, not a tiebreaker.
5. Vendor stability / health. Acquisition risk, funding, leadership turmoil, product-sunset risk. Typically standard (×3); promote to critical if continuity is existential.
6. Support. Channels, SLA, and — critically — which tier support is gated behind (a tool whose live support starts at $499/mo may functionally have no support for a small org).
7. Mobile. Native iOS/Android, feature parity, store ratings. Standard unless field/on-the-go use is central.
8. Pricing posture. Not just sticker price — the shape: per-seat vs. flat, tier paywalls hiding required features, geographic price exclusions, nonprofit/ startup discounts, one-time onboarding/implementation fees. Decide whether pricing is a scored preference or a separate sensitivity — usually keep it as a separate sensitivity rather than baking it into the preference score (the TCO method is pricing-tco.md; cost never contaminates the Fit score — model.md).
9. Integrations & extensibility. Required connectors (Google Workspace, M365, Stripe, the CRM, etc.), middleware support (Make/Zapier/n8n), API depth, rate limits, webhooks. Whether a tool can be reached by your automation layer is often a hard filter in disguise.
10. Graceful degradation / AI as optional assist. Must every use case stay fully doable when the fragile part — usually the AI/automation — is unavailable? If so it’s typically a Gate (it eliminates anything whose core is the AI), and AI is then modelled as an optional assist layered on the use cases where it earns its place, never as a baseline requirement. Don’t write “AI” as one umbrella requirement, and don’t fan it into a parallel per-use-case list — name the concrete assist on the few use cases it actually improves. The umbrella’s only real residue is technical: an open interface the assist can dock onto (folds into integrations, item 9). Mind single-placement — degradation is one axis (usually Gate), not also a Fit score (model.md). But “optional” here means fail-safe, not low-value — that assist is often the whole point of the engagement, so weight and present it as the value it is, not a footnote.

B. The engagement-specific layer

After the checklist, get the things only this engagement has:

• Stakeholders. Who decides? Who uses it daily? Who’s the sceptic whose buy-in you need? Map them by name.
• The stress-test scenario. Pin down the one concrete, near-future, high-stakes situation the solution must handle (EFI: an 18-city tour). Every candidate gets walked through this exact scenario in the deep dive. If the user can’t name one, that’s a discovery gap worth closing before you proceed.
• Stated priorities, verbatim. Capture the customer’s own words about what matters most. Carry these quotes through every later brief and into the final recommendation — they’re the anti-drift anchor.
• Volume / scale → the Scenario. Records, contacts, events, seats, throughput, seasonality and peak — whatever dimension stresses the tools and drives cost. For a solution-design engagement this is the seed of the shared Scenario, so capture it as ranges (low/expected/high), the same disciplined way you’ll ask the pricing questionnaire later — the uncertainty is the optimistic↔pessimistic spread. Name the day-rate for effort here too; it’s what prices the build buckets (pricing-tco.md).
• Existing tools / switching constraints. What’s in place, what’s painful, what must be preserved or migrated.
• Categories. Does this split into multiple tool categories (like EFI’s three) or is it one? This determines how many matrices the explorer holds.

C. Sorting into tiers

Once requirements are gathered, sort every one into a tier and assign each an ID. The four-tier weight table and the full mission.json / criteria.json field shapes live in contract.md — sort here, record there:

• Hard filter — binary pass/fail, no weight. Failure eliminates. Keep these few and genuinely binary.
• Critical preference (×5) — the 2–4 per category that actually drive the decision.
• Standard preference (×3) — important, not a swing factor.
• Nice-to-have (×1) — useful, not decisive.

Checks before you finish — over-filtering is the most common Phase-2 error and the usual reason a later iteration has to broaden:

• Is any “hard filter” really a preference? Hard filters are unforgiving; reserve them for things that are truly disqualifying.
• Did you assume a filter the user never stated? It’s easy to promote something to a hard (or strong) filter that was never actually a constraint for this user — and a wrong filter silently eliminates good options. If you can’t point to the user confirming it, it isn’t one yet.
• Is a hard filter actually several filters in a trenchcoat? A filter that bundles distinct capabilities (“must serve as their whole web presence” really meant discovery and a trust/about surface and booking) lets a tool pass by clearing only one of them — and the gap surfaces later, in use, as an expensive surprise. Decompose compound filters into the real capabilities and filter on each.
• Will each preference actually differentiate? If you expect every candidate to score 4–5 on a criterion, it’s dead weight — sharpen the rubric (what separates a 3 from a 5?) or drop it.

Output: requirements.md (human-readable, with the verbatim quotes, the stress-test, the stakeholder map, and the tiered tables) and criteria.json (the machine form — schema in contract.md). Give every criterion a one-line description alongside its ID and name. Then present the full set as a confirmable bulleted list (ID · name · tier · description) and get explicit sign-off before any research goes out — confirming the criteria is the cheapest place to catch a wrong, assumed, or compound filter, and the STOP gate that ends Phase 2.