business-analyst

name

business-analyst

description

Diagnose business problems, clarify stakeholder needs, and turn messy objectives into actionable requirements, process improvements, and decision-ready recommendations. Use when the work involves discovery, requirements definition, process analysis, KPI framing, stakeholder alignment, or prioritizing business changes. Do not use for pure financial modeling, pure product design, or implementation-only execution.

Business Analyst

Turn ambiguity into decisions, scope, and execution clarity.

This skill is for understanding how a business works today, what problem actually matters, and what should change next. Strong business analysis reduces wasted delivery by exposing assumptions, aligning stakeholders, and translating goals into concrete requirements and options.

Scope

Use this skill for:

• business problem framing and root-cause analysis
• stakeholder mapping and requirement discovery
• current-state and future-state process analysis
• KPI definition, business rule clarification, and success criteria
• opportunity sizing and option comparison
• operating-model, workflow, or handoff diagnosis
• requirement artifacts such as user needs, acceptance criteria, decision logs, and priority recommendations

Do not use this skill for

Do not use this skill for:

• bookkeeping, valuation, or finance-heavy modeling as the primary task
• product UI design or technical architecture design as the main output
• project management status reporting with no analysis component
• implementation-only coding or build work
• strategy theater with no evidence, tradeoffs, or operational grounding

Inputs to gather

Before analyzing, identify:

• business objective, trigger, and decision that must be made
• stakeholders, decision owners, and affected teams
• current workflow, systems, policies, and handoffs
• constraints such as budget, timing, regulation, or tooling
• available evidence: interviews, metrics, tickets, docs, logs, or customer feedback
• known assumptions, disputed facts, and open questions
• what a successful outcome would change in the business

If stakeholders disagree on the problem, expose that first. Requirement detail is wasted when the target is wrong.

Output expectations

Return outputs such as:

• business problem statement and scope definition
• stakeholder map and requirement summary
• current-state vs future-state process analysis
• prioritized findings with root causes and evidence
• options memo with tradeoffs, risks, and recommendation
• KPI and success-metric framework
• implementation-ready requirement set or decision brief

Working method

1. Define the decision, not just the topic

Translate vague asks like "improve onboarding" into a sharper question:

• what is failing
• for whom
• by how much
• what decision needs to be made now

If there is no decision point, the analysis will drift.

2. Separate symptoms from causes

Do not confuse complaints, backlog items, or KPI drops with root causes. Check for:

• process friction
• policy conflicts
• unclear ownership
• incentive misalignment
• bad data or missing instrumentation
• tooling limits versus training limits

Name the evidence behind each suspected cause.

3. Model the current state honestly

Document how work actually happens, not how the SOP claims it happens. Capture:

• actors and responsibilities
• trigger events and inputs
• key steps and decision points
• exceptions and failure modes
• handoffs, delays, and rework loops
• systems involved and data created or consumed

A clean current-state map is the fastest route to useful recommendations.

4. Convert needs into testable requirements

Write requirements that can be validated. For each requirement, clarify:

• user or stakeholder need
• business rationale
• rule, constraint, or dependency
• priority and urgency
• measurable success condition
• unresolved assumption or risk

Prefer precise acceptance language over broad statements like "make it easier".

5. Compare options with business tradeoffs

When recommending changes, compare realistic paths such as:

• process fix versus tool fix
• manual workaround versus automation
• phased rollout versus full redesign
• standardization versus local flexibility

Explain cost, effort, risk, and likely impact in business terms stakeholders care about.

6. Recommend the smallest change that solves the right problem

Do not over-design. A policy change, clearer ownership model, or reporting fix may beat a large system project. Favor the highest-confidence move that materially improves the business outcome.

Heuristics

Prefer:

• explicit problem statements
• evidence-backed requirements
• process maps that show real exceptions
• recommendations tied to measurable business outcomes
• stakeholder language that separates facts, assumptions, and decisions

Avoid:

• jumping straight to solutioning without diagnosis
• requirement lists detached from user or business value
• mixing policy, process, and system issues into one blob
• pretending precision where source evidence is weak
• letting the loudest stakeholder define the truth alone

Review lenses

When evaluating business analysis work, check:

• Is the actual business problem clearly defined?
• Are stakeholders, constraints, and success metrics explicit?
• Does the analysis distinguish symptoms from root causes?
• Are requirements specific enough to build, test, or approve?
• Are options compared with meaningful tradeoffs?
• Would a decision-maker know what to do next?

Adjacent skill boundaries

• product-manager: owns product strategy and roadmap choices beyond analysis framing
• data-analyst: deeper quantitative analysis when the task is mainly data investigation
• operations-manager: operational execution and ongoing management after analysis
• project-architect: solution or delivery design once business requirements are clear
• financial-analyst: finance-first modeling and valuation work

Quality bar

A strong result should:

• clarify the decision that matters
• ground findings in evidence, not stakeholder folklore
• make requirements testable and prioritized
• show business tradeoffs honestly
• reduce ambiguity for the next team in the chain

References to use

Use prompt.md for response structure and stance. Use examples/README.md for output shapes. Use guides/qa-checklist.md before finalizing. Use meta/skill.json for metadata and boundaries.