Business goal alignment

Business Goal Alignment

Use this skill when evaluating requirements, technical plans, or code changes to ensure engineering effort stays anchored to a real user or business outcome rather than speculative completeness.

Core Alignment Questions

Before approving or expanding any non-trivial work item, answer these six questions against the actual brief, accepted decisions, and codebase:

1. Target outcome: What concrete user capability, business metric, or operational guarantee does this change unlock?
2. Evidence: What requirement, bug report, production measurement, or compliance rule proves this need exists today?
3. Existing capability: Can the current system, data model, or workflow already satisfy this need with a small configuration or UI adjustment?
4. Smallest complete slice: What is the smallest end-to-end change that delivers the full user outcome without leaving a broken workflow?
5. Cost of deferral: What concrete failure, manual burden, or customer harm happens if we defer the extra scope for 30–90 days?
6. Expansion trigger: What observable event (e.g., "> 3 enterprise tenants request custom webhook transforms", "p95 latency exceeds 400 ms") would justify building the more complex version later?

Workflow

1. Read the existing brief and accepted decisions first:
   • Never ask the user or team to restate a goal that is already documented in the task description, specification, or decision log.
   • Never invent unstated business KPIs, revenue targets, deadlines, or budgets; anchor strictly to what the project and task actually state.
2. Trace every major technical component to a requirement:
   • Map each proposed table, service, queue, abstraction layer, or UI screen to either:
     • An explicit acceptance criterion in the current work item, or
     • A non-negotiable correctness baseline (authentication/authorization, tenant isolation, data integrity, security, or core error handling).
   • Flag any component that serves only "future flexibility" or "how big systems do it" without a concrete current caller.
3. Apply Theory of Constraints (Goldratt) to local optimizations:
   • Evaluate whether a proposed optimization or architectural polish improves the actual bottleneck of the user flow or system. Optimizing a step that takes 2% of total latency or effort while adding permanent maintenance complexity is net-negative.
4. Deliver a concise, actionable alignment verdict:
   • When the plan is proportional to the goal, state so briefly and let execution proceed without friction.
   • When an element is disproportionate, use the four-part review format:
     • Goal: What outcome we need to achieve.
     • Observation: Where the plan or diff diverges from or outgrows that outcome.
     • Proposal: A concrete, simpler, complete alternative that works in the existing codebase.
     • Trade-off: What is deferred, its limitations, and the exact trigger condition for revisiting it.