Is This Task a Good Fit for Claude?
The fit test: bounded input + bounded output + the hard part is judgment-and-language in between. Ask this before designing any workflow.
- Good fit: drafting a stakeholder update from status notes, triaging tickets by category/urgency, turning a transcript into action items, comparing proposals against stated criteria.
- Poor-fit signal 1 — Live data: the task depends on a system of record changing in real time (current inventory, invoice status). Claude answering from memory or a stale paste risks a confidently wrong answer.
- Poor-fit signal 2 — Deterministic calculation: payroll, tax withholding, financial reconciliation. Language models can make arithmetic slips at exactly the volume and stakes where an error is expensive and hard to catch.
- Poor-fit signal 3 — Regulated professional judgment: a licensed clinician's diagnosis, a binding legal opinion, a compliance sign-off with legal liability. A credentialed human has to hold that accountability, not Claude.
- A poor-fit signal doesn't mean 'no role for Claude.' Scope Claude to an assisting sub-step instead — drafting a reconciliation summary a human checks, flagging overdue invoices as a first pass, summarizing case law for an attorney who forms the opinion.
Exam trap: 'prompt Claude better' or 'give it more context' is never the fix for a structural fit problem — the fit issue is upstream of prompting.
Augment vs. Redesign
Once a task passes the fit test, decide: bolt Claude onto the process as-is, or rebuild the process around it.
| Augment | Redesign | |
|---|---|---|
| What changes | One step gets a Claude-assisted version; everything else (owners, handoffs, approvals) stays the same | Roles and the sequence of handoffs change — a genuinely different workflow |
| Example | Claude drafts a social caption; the same human editor still reviews and posts it | Claude drafts a full week's caption slate from a shared brief; the human's job shifts to reviewing and approving a batch |
| Speed / risk | Fast to pilot, low risk, easy to roll back | Bigger up-front design work, real change management, more risk at volume |
| Payoff ceiling | Limited to the one step touched | Can unlock throughput/consistency a single-step fix never would |
| Choose when | Fast low-risk pilot; process is otherwise efficient; not yet confident Claude handles the task well | The bottleneck is structural (manual handoffs, a step that only exists because a human had to do it slowly); appetite for change management exists |
Find the bottleneck first. It's often a handoff or approval wait, not the most visible/tedious step. Augmenting a step that isn't the bottleneck won't speed up the overall process. Sensible sequence: augment first to build evidence, then consider redesigning once several real runs confirm Claude handles the task well.
Scoping Research and Turning Findings Into a Plan
- Shallow (avoid): 'What's the competitive landscape for X?' — too broad, Claude has to guess which angle you care about, answer grazes everything shallowly.
- Scoped (use): break the underlying interest into 3-4 explicit sub-questions tied to a specific decision, each independently answerable (e.g. which competitors have feature X, how do they price it, what do reviews say, has anyone dropped it recently).
- Plan is a separate, later step. Don't ask for findings and a final recommendation in the same prompt — that skips the checkpoint where a human reviews findings before they become the basis for a plan.
- A good planning follow-up names constraints: budget, timeline, who has final say, what would change the recommendation — and still leaves the go/no-go call to a human.
Exam trap: research mode improving sourcing/breadth is not the same as skipping human review of the findings before they're used.
Solution Design Checklist (Prototype → Iterate)
The unit you design is workflow-level — typically a Project (custom instructions + reference documents), not a single prompt.
- Prototype: set up first-pass instructions + 2-3 core reference documents (style guide, template, past good example); run against one real, representative instance — not a toy example.
- Iterate across 3-5 real runs, spanning the task's actual cadence (e.g. 3-5 real weeks, not the same week copied). A single successful run never proves the solution is ready.
- Diagnose failures the domain-1 way, at Project level: is it a missing role/constraint, missing example, or missing structure — fixed by revising instructions or adding a reference document, not by patching one message.
- Rollout gate: never roll out to a team after one clean test on convenient data — real variation only shows up across multiple genuine runs.
Integration Handoff Checklist
A process that already has owners and steps gains a new handoff, not just a new capability, when Claude joins it.
| Output lands in... | What it needs |
|---|---|
| A human reviewer | A form that's fast to check — what changed / what's uncertain flagged, not a polished wall of text that invites rubber-stamping |
| Another tool/system | A specific, consistent format it can reliably consume every run, not one that varies |
| A shared document | Fits the existing structure/voice other people use — not a stylistically different, obviously-AI insert |
- Reassign accountability explicitly: who reviews the draft, who is accountable if it's wrong, at what point review happens. This ownership doesn't disappear just because Claude drafted the step.
- Connectors fix the handoff INTO Claude (live data from a drive/calendar/tracker, less copy-paste) — they do NOT fix the handoff OUT. A human still needs to own reviewing the output before it's final.
- Exam trap: a plan that's all about output quality with no named reviewer or destination is an incomplete integration.
Communicating Value Without Over-Promising
Three-part structure, every claim checkable: (1) what Claude reliably does well in this specific use case, (2) what still needs human review and why, (3) what evidence backs it — several real runs, not one demo.
| Trap | Looks like | Why it fails |
|---|---|---|
| Over-promising | "Claude now fully automates our reports — no one needs to review them." | Sets an expectation that breaks at the first plausible-sounding error; damages trust in the whole solution, not just that output |
| Under-selling | "AI makes mistakes, so we're not sure how much to rely on it." | Generic caveats with no specific claim; can sink a genuinely strong use case because stakeholders have nothing concrete to evaluate |
| Single-demo evidence | "We tested it once and it looked great, so it's ready to replace the process." | One clean demo doesn't represent real variation (see solution-design iteration above) |
| Correct pattern | "Across the last 5 reports, Claude cut drafting time roughly in half; our lead analyst reviews every draft and caught 1 factual error in 5." | Specific value + named reviewer + evidence from multiple real runs — survives a hard follow-up question |