Business Analyst
Turn a messy stakeholder conversation into a clean requirements doc, a mapped process, and a business case with options — all from the Claude Desktop chat, no terminal required.
Full worked systems, not one-off prompts — each walks the whole workflow end to end. Pick one and follow it.
Map every stakeholder before you write a single requirement
Turn a messy list of names into a stakeholder map — who cares, what they need, their influence and interest, and a RACI per key decision — so nothing proceeds without a named, accountable owner.
Build the requirements doc every downstream playbook inherits
Turn scattered stakeholder interview notes into one requirements doc — background, in-scope/out-of-scope, functional and non-functional requirements each traced to a named stakeholder need, and open questions — that every gap analysis, business case, backlog, and sign-off inherits.
Turn interview notes into a clear as-is process map
Turn scattered interview notes, screenshots, and a walkthrough into a clear as-is process map — step by step, who does what, with pain points and breakdowns flagged inline.
Find the gaps between today and the target state
Compare the current state against the future state in your requirements doc, and get every gap named with its root cause — not just a list of differences nobody can act on.
Turn scattered concerns into a SWOT and a living risk register
Turn a pile of half-formed worries and notes about an initiative into a structured SWOT and a risk register with likelihood, impact, owner, and mitigation for each risk — built to be revisited, not written once and shelved.
Compare solution options and land on one
Score 2-4 candidate solutions against the same criteria — cost, effort, risk, time-to-value — and get a defensible recommendation, not a pros/cons list nobody can act on.
Build the business case
Turn a requirements doc into a defensible cost-benefit case: quantified where you can, honest about what's a guess, with the payback math and the risks that could break it laid out for a named decision-maker.
Break requirements into a traceable backlog
Turn the requirements doc's functional requirements into epics and user stories with clear acceptance criteria — every story traced back to the specific requirement and stakeholder need it satisfies, so nothing in the backlog exists without a reason.
Turn workshop chaos into decisions, same day
Turn a messy workshop transcript — multiple stakeholders talking past each other, half-decisions, tangents — into a clean synthesis: decisions made, owners assigned, open questions, and next steps, sent before people forget what they agreed to.
Take requirements from draft to full sign-off
Draft the requirements doc from stakeholder input, circulate it, track who has and hasn't responded, resolve conflicting feedback, and land a version every named stakeholder has actually signed off on before build starts.
Compress an initiative into a two-minute exec briefing
Pull requirements, options considered, business case, current status, and risks into a one-page update a VP or steering committee can absorb in under two minutes.
Business Analyst with Claude, in depth
The playbooks above are single jobs. These are the long reads behind them — how the work fits together across a quarter, what good looks like, and the judgement calls the prompts assume you have already made. Read in any order.
- BA Foundation: master the stakeholder map and requirements doc everything inherits Module 1 of the Business Analyst deep dives — go past the recipe to master the two documents every gap analysis, business case, backlog, and sign-off inherits: a stakeholder map with a real RACI, and a requirements doc where every line traces to a named need. Build them for your own initiative. Free to sample.
- Initiative-in-a-Box — the Business Analyst capstone The Business Analyst capstone — integrate all five modules into one complete Initiative-in-a-Box for a single real initiative, end to end, Checked against a master rubric that covers the artefacts and the judgement behind them.
- Sign-off: circulation, conflict, and the doc everyone actually agreed to Module 4 of the Business Analyst deep dives — run the full sign-off pipeline: circulate the requirements doc without losing momentum, surface and resolve a real stakeholder conflict instead of quietly picking a side, and land a version every named stakeholder has actually signed off on.
- The analysis: turn a signed-off requirement into a gap, a risk register, and a defensible recommendation Module 2 of the Business Analyst deep dives — turn the requirements doc you built in Module 1 into three production moves: a gap analysis with real root causes, a risk register that stays alive, and an options analysis that lands on a decidable recommendation. Build it for your own initiative and check it against a real rubric.
- The BA Foundation toolkit: the files your team installs The take-home pack for Module 1 — a ready BA CLAUDE.md, fill-in templates for stakeholder-map.md and requirements.md, and the saved prompts that build them. Turn the foundation you wrote into files your whole team inherits.
- The decision package: the business case, the traceable backlog, and the workshop that actually decides Module 3 of the Business Analyst deep dives — master the judgment that turns a requirements doc into a funded, buildable, cross-team-aligned initiative: a business case that survives a skeptical CFO, a backlog where every story traces to a requirement, and a workshop synthesis that turns four teams' worth of discussion into named decisions. Build all three for a real initiative and check it against a real rubric. Gated.
- The exec briefing: compress an initiative into two minutes leadership trusts Module 5 of the Business Analyst deep dives — master compressing a whole initiative's requirements, options, business case, and risk into a one-page briefing that survives a hard question, with every claim still traceable to a named source artifact.
The non-negotiables before any of this ships. Read the operating guide for the full data, brand, legal, and rollout playbook.
- Every requirement traces to a named stakeholder need. Not "the business wants X" — who asked, in their own words, and what problem it solves for them. An untraceable requirement is the one that gets silently dropped or silently changed later.
- Nothing moves to build without a named, signed-off owner. A business case, a requirements doc, or a scope change is a draft until a real person's name is on the approval — Claude can produce the document in minutes, but it cannot produce the sign-off.
- "Nobody agreed to this" is the failure mode to design against. Before you circulate any
requirements-doc.mdorbusiness-case.md, ask Claude to list every claim and requirement with its source stakeholder — a blank next to any line is a gap to close before it ships, not after. - Strip names and sensitive detail before it goes in the chat. Stakeholder conversations often carry HR complaints, salary context, or customer PII in passing — keep that in a workspace your company approved, share only what the document needs, and approve each read in the 'Ask permissions' prompt.
- Separate the stated ask from the underlying need. Have Claude draft both explicitly (
stated askvs.likely need) in every requirements doc — a feature request is rarely the real problem, and conflating the two is how you build the wrong thing well. - Claude drafts the document; you run the room. Use it to turn notes into a clean requirements doc, process map, or options table fast — but reading the stakeholder, negotiating scope, and chasing the actual sign-off stay with you.
Questions people ask
- Is this different from a Data Analyst role?
- Yes — they're neighbors, not the same job. A Data Analyst answers questions with numbers: queries, dashboards, `SQL`. A Business Analyst sits between stakeholders and delivery: gathering requirements, mapping process, weighing options, and building the business case that gets a decision signed off. You'll use Claude for writing and structuring, not for statistics.
- Is it safe to put stakeholder conversations and notes into Claude?
- Treat it like any shared drive: fine for meeting notes, requirements drafts, and process maps. Strip names, salaries, or anything an HR or legal team would flag before it goes in, keep sensitive material in a workspace your company approved, and approve each read in the 'Ask permissions' prompt.
- Does this replace the BA's judgment?
- No. Claude drafts the requirements doc, the options table, and the exec summary fast — you still run the room, decide what a stakeholder actually meant, and chase the sign-off. The traceability is only real once a named owner agrees to it.
- What's a realistic first task?
- Take messy notes from one stakeholder conversation and ask Claude to turn them into a short requirements doc — the ask, the underlying need, and open questions. It's the keystone every other BA document builds from, and it takes ten minutes to see the difference.