business-requirements-review

Business Requirements Review

Shared Reference

Use ../../references/product-management-principles.md for general product management principles. Apply the discovery, metrics, prioritization, and common failure mode sections when reviewing business requirements.

Review Stance

Treat business requirements as the contract between strategy and product execution. Push on outcomes, economics, constraints, and stakeholder alignment before solution details.

Product Management Principles

• A business requirement should justify why product capacity should be spent now.
• The requirement must connect customer or market pain to a measurable business outcome.
• Solution preferences are useful context, but should not replace problem, segment, value, constraints, and success criteria.
• Good business requirements make the decision owner, impacted teams, and approval path visible.

Practical Operating Guidance

• Check whether the initiative has a named accountable owner and approvers.
• Look for budget, timing, legal, operational, technical, and GTM constraints before judging feasibility.
• Ask what decision the document should unlock: PRD creation, funding, roadmap placement, experiment approval, or cancellation.
• Flag any requirement that cannot be tied to revenue, cost, risk, retention, adoption, quality, strategic positioning, or learning.
• Treat "important stakeholder asked for it" as evidence to inspect, not as a sufficient business case.

Checklist

• Business objective: clear outcome, not only output.
• Customer or user impact: target segment and pain are explicit.
• Success metrics: measurable, attributable, and time-bounded.
• Scope: in-scope, out-of-scope, and non-goals are stated.
• Constraints: legal, operational, technical, budget, timing, and go-to-market constraints are visible.
• Stakeholders: owners, approvers, impacted teams, and unresolved decisions are named.
• Risks: adoption, revenue, cost, compliance, delivery, and support risks are addressed.

Common Failure Modes

• The document asks for a feature but does not state the business problem.
• Success metrics are vague, lagging only, or not attributable to the work.
• Scope boundaries are implied rather than explicit.
• Stakeholders are named, but decision rights are unclear.
• Constraints appear late, after product or engineering has already committed.

Output

Provide findings first, ordered by severity. Then list missing decisions, suggested requirement rewrites, and a readiness verdict: Ready for PRD, Needs clarification, or Not ready.