Identify Assumptions

Identify Assumptions — Structured Risk Analysis

Purpose

Surface risky assumptions that could undermine a feature if left unvalidated. Outputs in a structured, actionable format that integrates directly into requirements documents and meeting summaries.

Domain-agnostic. Works for any feature, any industry, any platform.

Step 1: Gather context

Read all available inputs:

• Feature description, PRD, or requirements document
• Scenario matrix (if available from a prior pipeline stage)
• User flows (if available)
• Meeting transcripts or summaries (if available)
• Any constraints, variables, or rules already identified

If running as part of the requirements-pipeline, these inputs are passed from Stage 4 (Scenario Matrix).

Step 2: Multi-perspective analysis

Think through the feature from three perspectives, specifically looking for what could go wrong:

Product Manager perspective

• Does this solve a real problem? Is the problem validated?
• Will the target users actually use this? Is there adoption risk?
• Does this align with business strategy? Could priorities shift?
• Are the success metrics realistic? Can we actually measure them?
• Are there regulatory, legal, or compliance assumptions?

Designer perspective

• Will users understand how to use this without training?
• Are there accessibility barriers?
• Does the flow handle all states (empty, error, loading, edge cases)?
• Are there assumptions about user behavior that haven't been validated?
• Is the cognitive load reasonable for the target user?

Engineer perspective

• Can this be built with existing infrastructure, or does it require new systems?
• Are there performance assumptions (response time, data volume, concurrency)?
• Are there integration dependencies that could delay or block delivery?
• Are there assumptions about data availability, format, or quality?
• Are there assumptions about third-party system behavior or SLAs?

Step 3: Categorize by risk area

Group assumptions into four risk areas:

Step 4: Structure each assumption

Every assumption MUST use this format:

### ASSUMPTION: [Clear, falsifiable statement]
- **SOURCE:** [Where this assumption originated — e.g., "March 11 transcript, Decision 3", "FigJam flow, Screen 2", "PRD v0.1, Section 4", "Engineer brainstorm", or "Implicit — not stated in any input"]
- **STATUS:** [Not confirmed / Partially confirmed / Confirmed / Contradicted]
- **RISK AREA:** [Value / Usability / Viability / Feasibility]
- **EVIDENCE:** [What supports this assumption — cite source document and section, or "None — untested"]
- **VALIDATE WITH:** [Specific person, role, or team] | **BY WHEN:** [Date, milestone, or "Before [stage]"]
- **RISK IF WRONG:** [Concrete consequence — what changes in the design, what gets blocked, what breaks]
- **SUGGESTED TEST:** [How to validate — question to ask, data to check, experiment to run]

Rules for good assumptions:

• Falsifiable. "Users will like this" is not falsifiable. "Officers will complete the attestation in under 10 seconds" is.
• Specific. "The system works" is not specific. "WFM API returns penalty pay records within 3 seconds" is.
• One assumption per block. Don't combine multiple assumptions into one.
• Traceable. Every assumption must have a SOURCE. If it came from a meeting, cite the meeting date and decision number. If it came from a design, cite the screen or flow. If it was surfaced during analysis (not in any input), say "Implicit" — this flags it for extra validation.

Step 5: Prioritize assumptions

After identifying all assumptions, sort them by risk level:

Present assumptions grouped by priority, then by risk area within each priority group.

Step 6: Cross-reference with scenario matrix (if available)

If a scenario matrix exists from a prior pipeline stage:

Step 7: Present for review

Present the full assumptions list to the user:

## Assumptions Analysis: [Feature Name]

**Total assumptions identified:** [N]
**By priority:** [X] HIGH, [Y] MEDIUM, [Z] LOW
**By risk area:** [N] Value, [N] Usability, [N] Viability, [N] Feasibility

---

### HIGH — Must validate before design

[Assumption blocks in structured format]

### MEDIUM — Should validate before development

[Assumption blocks]

### LOW — Track and validate opportunistically

[Assumption blocks]

Save the output as: [Feature]-Assumptions.md

Step 8: Integration with requirements document

When assumptions are incorporated into a requirements document:

1. Assumptions table — Add each assumption as a numbered row in the document's assumptions section, preserving the SOURCE / STATUS / VALIDATE WITH / BY WHEN fields. The SOURCE column links the assumption back to its origin (transcript, design, stakeholder, or "Implicit").
2. Inline references — Where an assumption affects a specific requirement or flow, add (See Assumption [N]) inline.
3. Dependencies — HIGH-priority unvalidated assumptions should also appear in the Dependencies & Blockers section with an owner and impact statement.
4. Source traceability — Every requirement, decision, and assumption in the final document should be traceable to its origin input. Use the format (Source: [input name, section/decision]) — e.g., (Source: March 11 transcript, Decision 3) or (Source: FigJam flow, Screen 2). Assumptions surfaced during analysis that were not in any input should be tagged (Source: Implicit — surfaced during assumption analysis).

Critical Rules

1. Never fabricate evidence. If an assumption has no supporting evidence, say "None — untested." Don't invent sources.
2. Be constructive. The goal is to strengthen the feature, not kill it. Every assumption should have a suggested test.
3. Falsifiable statements only. If you can't imagine evidence that would disprove the assumption, it's not specific enough.
4. Domain-agnostic. Don't assume a specific industry, tech stack, or regulatory environment unless the inputs specify one.
5. Consistent format. Every assumption uses the exact template from Step 4. No exceptions. This ensures downstream skills (document-audit, requirements generation) can parse and cross-reference them.