Build Business Objectives Model

Common Contract (Load First)

When this skill is activated, first load skill-common and apply the shared conventions it defines: canonical section order, frontmatter rules, anti-pattern guidance, and the Review In Mind loop in review-in-mind. This skill adds only domain-specific rules below.

Who

Product Owners, Business Analysts, and AI Agents. The agent uses this skill to anchor a project's scope in measurable value.

What

This skill implements the Business Objectives Model (BOM) from the Requirements Modeling Language (RML). It systematically extracts:

1. Business Problems: What is wrong today?
2. Business Objectives: What quantifiable metric proves we fixed the problem?
3. Product Concept: What is the high-level solution?
4. Guiding Principles: What rules govern the solution?

When

Invoke this skill at the absolute beginning of a project (Phase 0), before writing any user stories or feature lists. Trigger phrases include: "extract business objectives," "build a BOM," "what is the product concept," or "analyze this kickoff document."

Where

Applies to project charters, vision documents, and executive stakeholder transcripts.

Why

Stakeholders often jump straight to "We need an AI chatbot." If you don't ask why, you might build a chatbot when what they really needed was a better search bar. The BOM forces the extraction of the underlying Problem (e.g., "Customer service wait times are too high") before committing to the Product Concept.

Inputs

• Project charters, vision documents, or interview transcripts.

Output (Logical Evidence)

• A completed Business Objectives Model document.

Optimization Readiness

• Failure Signals: Features are mistaken for business problems, objectives lack measurable outcomes, product concepts are accepted without root-cause clarity, or guiding principles are invented rather than sourced.
• Evidence To Collect: Problem statements, objective mappings, missing-metric questions, product concepts, and reviewer feedback on whether the BOM stays tied to business intent.
• Safe Mutation Boundaries: Refine problem-extraction prompts, objective templates, and formatting guidance without changing the core requirement to connect problems, objectives, and product concept explicitly.
• Acceptance Criteria: Accept revisions only if every objective maps back to a business problem, missing metrics are flagged instead of fabricated, and the BOM separates problem, objective, concept, and principles clearly.
• Rejected Revision Handling: Record feature-list-only interpretations, invented metrics, and orphan objectives so they are not reused.
• Transfer Check: Verify the workflow still works for executive charters, stakeholder interviews, and vision documents with uneven detail.
• Stop Rule: If the source material contains only solution ideas or feature lists with no identifiable business problem, stop and ask before drafting the BOM.

Constraints (Logical Boundaries)

• Do not invent metrics. If an objective is not quantifiable in the source text, flag it as a question (e.g., "[Insert metric here - requires stakeholder input]").
• Ensure there is a 1:1 or 1:N mapping from Problems to Objectives. An objective without a problem is invalid.

One More Thing

If the input text is just a list of features (e.g., "Build a login page, build a cart"), stop and ask the user what the overarching business problem is before proceeding.

How (Structural Workflow)

Phase 1: Problem Extraction

1. Read the input text and extract the core Business Problems. These are negative statements about the current state (e.g., "Costs are too high," "Revenue is dropping," "Manual entry takes too long").

Phase 2: Objective Definition

2. For each Business Problem, extract or infer the corresponding Business Objective.
3. Ensure every Business Objective is quantifiable (e.g., "Reduce manual entry time by 50% by Q3"). If the text lacks a metric, mark it for follow-up.

Phase 3: Product Concept and Principles

4. Extract the Product Concept. This is the high-level summary of the solution being proposed.
5. Extract Guiding Principles. These are constraints or rules (e.g., "Must be mobile-first," "Do not disrupt the legacy database").

Phase 4: Formatting

6. Output the extracted data using the BOM Template structure.

Resources

• BOM Template

Review In Mind (ReviewInMindGenie)

Execute the common review loop in review-in-mind before delivering.

Review lens for this skill:

• Is every business problem paired with a quantifiable objective and measurable success metric?
• Does the product concept trace to the objective, and do guiding principles govern scope?
• Would a feature not traceable to a BOM objective be excluded?

Validation

1. Verify that every Business Problem is addressed by at least one Business Objective.
2. Ensure every Business Objective includes a measurable success metric.