This is the first SOP in a 4-part series for creating fixed-price, milestone-based professional services project proposals. This SOP focuses on understanding the client's needs, extracting business outcomes from the Product Requirements Document (PRD), and prioritizing those outcomes based on strategic value and implementation feasibility.
SOP Sequence:
- Discovery & Outcome Prioritization ← You are here
- Milestone Scoping & Task Decomposition
- Estimation & Risk Analysis
- Pricing & Proposal Generation
This SOP analyzes the PRD and business context to identify the highest-priority business outcome that should drive the MVP/Phase 1 milestone definition in SOP 2.
- prd_document (required): The Product Requirements Document detailing the desired solution, features, and business outcomes.
- business_context (optional): Additional business context including market conditions, competitive landscape, user research, strategic goals, organizational constraints, and client organization details.
- timeline_constraints (optional): Hard deadlines, market windows, business events, or timing requirements that impact delivery.
- budget_range (optional): Client's budget expectations or constraints.
- success_metrics (optional): Existing KPIs, success criteria, or client's definition of success for project evaluation.
- risk_tolerance (optional, default: "moderate"): Organization's appetite for risk - "conservative", "moderate", or "aggressive".
- change_readiness (optional): Information about organizational change management capacity, user readiness for new solutions, and stakeholder engagement.
- technology_stack (optional): Preferred or required technology choices including:
- Frontend framework (e.g., React, Vue, Angular, Next.js)
- Backend framework/language (e.g., Node.js/Express, Python/Django, .NET, Java/Spring)
- Database (e.g., PostgreSQL, MySQL, MongoDB, DynamoDB)
- Mobile (e.g., React Native, Flutter, Swift/Kotlin native)
- Other key technologies (e.g., GraphQL vs REST, real-time requirements)
- hosting_environment (optional): Hosting and infrastructure preferences including:
- Cloud provider (e.g., AWS, Azure, GCP, DigitalOcean)
- Deployment model (e.g., PaaS like Heroku/Vercel, containerized with ECS/Kubernetes, serverless, VPS)
- CI/CD preferences (e.g., GitHub Actions, GitLab CI, Jenkins)
- Infrastructure requirements (e.g., high availability, multi-region, compliance needs)
- existing_systems (optional): Existing systems that must be integrated with, including:
- System names and purposes (e.g., "Salesforce CRM", "SAP ERP", "Legacy inventory database")
- Integration points and APIs available
- Data sync requirements
- Authentication/SSO requirements
- technical_constraints (optional): Technology constraints including:
- Must-use technologies (client/organizational standards)
- Must-avoid technologies (licensing, security, organizational policies)
- Team skill constraints (technologies team is proficient/not proficient in)
- Compliance requirements (HIPAA, SOC2, GDPR, etc.)
- working_directory (optional, default: "./proposal-outputs"): Directory path where all output artifacts will be saved.
Constraints for parameter acquisition:
- You MUST ask for all required parameters upfront in a single prompt rather than one at a time
- You MUST support multiple input methods for documents including:
- Direct input: Text provided directly in the conversation
- File path: Path to a local document file
- URL: Link to a document
- Other methods: You SHOULD be open to other ways the user might want to provide documents
- You MUST use appropriate tools to access content based on the input method
- You MUST prompt the user for technical context if not provided:
- "What technology stack are you planning to use or do you have preferences? (Frontend, Backend, Database, Mobile)"
- "What hosting environment are you targeting? (Cloud provider, deployment model)"
- "Are there existing systems this needs to integrate with?"
- "Are there any technical constraints? (Must-use/avoid technologies, compliance requirements)"
- If user says "not sure" or "you recommend", document that technology choices will be made during Phase 1 design
- You MUST confirm successful acquisition of all parameters before proceeding
- You MUST create the working directory if it doesn't exist
- You MUST save the input PRD document to "{working_directory}/prd-source.md" for reference in subsequent SOPs
- You MUST save technical context to "{working_directory}/technical-context.md" for reference in subsequent SOPs (even if minimal/TBD)
Extract and categorize all elements from the PRD into a structured format.
Constraints:
- You MUST identify and extract the following elements from the PRD:
- Problem statement and user pain points
- Proposed solution and key features
- Target users and personas
- Business goals and desired outcomes
- Success metrics and KPIs
- Technical requirements and constraints
- Dependencies and assumptions
- You MUST distinguish between explicitly stated business outcomes and implied outcomes
- You MUST identify and flag any gaps or ambiguities in the PRD
- You MUST flag any missing critical information that would affect prioritization because incomplete understanding leads to poor scoping decisions
- You MUST create a structured breakdown with the following sections:
- Problem & Pain Points
- Proposed Solution Overview
- Feature Catalog (complete list of all features mentioned)
- Target Users & Personas
- Business Goals & Outcomes
- Success Metrics
- Technical Requirements
- Dependencies & Assumptions
- Gaps & Ambiguities Identified
- You MUST include explicit reasoning for interpretations and inferences:
- For each implied outcome: Explain what PRD evidence led to this inference
- For each gap identified: Explain why this information is critical
- For each ambiguity: Explain the possible interpretations and which one was chosen (if any)
- For feature categorization: Explain the logic used to organize features
- You MUST save the structured breakdown to "{working_directory}/prd-breakdown-draft.md" (with "-draft" suffix)
- You MUST include a Review Summary at the top of the artifact (see Review Summary Template below)
- After human approval, You MUST rename the file from "prd-breakdown-draft.md" to "prd-breakdown.md"
Review Summary Requirements for prd-breakdown.md:
- Key Findings: Feature count, primary problem, target users, stated vs. implied outcomes
- Red Flags: Missing requirements, ambiguous features, conflicting information, gaps in success metrics
- Critical Decisions: How implied outcomes were inferred, how ambiguities were interpreted
- Critical Assumptions: Assumptions made about missing information
- Approval Checklist: Verify feature catalog is complete, verify outcomes are correctly extracted, verify gaps are identified, verify no major misinterpretations
Human Review Gate: After generating prd-breakdown-draft.md, you MUST:
- Present the Review Summary to the user
- Ask the user to review the draft artifact
- Wait for explicit approval before proceeding
- If feedback is provided, update the draft artifact and re-present for approval
- Once approved, rename "prd-breakdown-draft.md" to "prd-breakdown.md"
- Only proceed to Step 2 after the artifact is approved and renamed
Capture technology stack preferences, hosting environment, existing systems, and technical constraints to inform solution design and estimation.
Constraints:
- You MUST create a technical context document even if information is minimal or TBD
- You MUST document the following (mark as "TBD - Will be determined in Phase 1 design" if not provided):
- Technology Stack Preferences:
- Frontend framework and rationale (if specified)
- Backend framework/language and rationale (if specified)
- Database choice and rationale (if specified)
- Mobile technology (if applicable)
- API architecture (REST, GraphQL, etc.)
- Hosting & Infrastructure:
- Cloud provider or hosting platform
- Deployment model (PaaS, containerized, serverless, etc.)
- CI/CD approach
- Scalability and availability requirements
- Existing Systems & Integrations:
- List of systems to integrate with
- Integration requirements (API types, data sync, auth)
- Integration complexity assessment
- Technical Constraints:
- Must-use technologies (organizational standards, client requirements)
- Must-avoid technologies (licensing, security, policies)
- Compliance requirements (HIPAA, SOC2, GDPR, PCI-DSS, etc.)
- Security requirements
- Technology Stack Preferences:
- You MUST assess how technical choices affect the project:
- Team Familiarity: Is team experienced with chosen technologies? (affects risk and estimation)
- Technology Maturity: Are technologies proven and stable? (affects risk)
- Integration Complexity: How complex are the integrations? (affects effort and risk)
- Learning Curve: Will team need to learn new technologies? (affects timeline and risk)
- You MUST include explicit reasoning for technical assessments:
- For team familiarity: Explain evidence of experience or lack thereof
- For technology maturity: Cite evidence (widely adopted, cutting-edge, beta, etc.)
- For integration complexity: Explain what makes integrations simple or complex
- For learning curve: Estimate learning time needed (if applicable)
- You MUST flag technical decisions that need to be made in Phase 1:
- List decisions that are TBD (e.g., "Database choice between PostgreSQL and MongoDB")
- Recommend including design/architecture work in Phase 1 if many decisions are TBD
- Estimate time needed for technical design work (typically 1-2 weeks of Phase 1)
- You MUST save technical context to "{working_directory}/technical-context-draft.md"
- You MUST include a Review Summary at the top of the artifact
- After human approval, You MUST rename from "technical-context-draft.md" to "technical-context.md"
Review Summary Requirements for technical-context.md:
- Key Findings: Technology decisions made vs. TBD, team familiarity level, integration complexity, compliance requirements
- Red Flags: Many TBD decisions (increases Phase 1 design effort), unfamiliar technologies (increases risk), complex integrations, compliance requirements not addressed, must-use technologies team doesn't know
- Critical Decisions: Technology choices that significantly affect design and estimation
- Critical Assumptions: Technology assumptions that affect feasibility and effort
- Approval Checklist: Verify technology choices are appropriate, verify team can execute on chosen stack, verify integrations are feasible, verify compliance requirements are identified, verify TBD items are flagged for Phase 1
Human Review Gate: After generating technical-context-draft.md, you MUST:
- Present the Review Summary to the user
- Highlight what's decided vs. TBD
- Flag any technology risks or unfamiliarity
- Ask the user to validate technical context
- Wait for explicit approval before proceeding
- If feedback is provided, update the draft and re-present
- Once approved, rename to "technical-context.md"
- Only proceed to Step 3 after approved and renamed
Identify all potential business outcomes and map them to measurable success criteria.
Constraints:
- You MUST list all business outcomes mentioned or implied in the PRD
- You MUST categorize outcomes by type:
- Revenue outcomes: Increase sales, reduce churn, enable new revenue streams, improve pricing power
- Efficiency outcomes: Reduce operational costs, improve productivity, automate processes, reduce manual effort
- User experience outcomes: Increase satisfaction, improve engagement, reduce friction, enhance retention
- Risk mitigation outcomes: Improve security, ensure compliance, reduce technical debt, business continuity
- Market positioning outcomes: Competitive advantage, market expansion, brand strengthening, thought leadership
- Strategic outcomes: Capability building, organizational transformation, data-driven decision making
- You MUST define measurable success criteria for each outcome including:
- Quantitative metrics where possible (e.g., "Reduce support tickets by 30%")
- Qualitative indicators for outcomes that are harder to quantify
- Baseline measurements if provided in the PRD
- Target measurements that would indicate success
- You MUST identify the primary stakeholders who care about each outcome (e.g., CEO, CFO, Sales VP, Customer Success, End Users)
- You MUST estimate the potential impact magnitude for each outcome:
- High Impact: Significant effect on revenue, costs, or strategic goals (>$500k annual value or >20% improvement)
- Medium Impact: Noticeable improvement to operations or user experience ($100k-$500k annual value or 10-20% improvement)
- Low Impact: Incremental benefit or nice-to-have (<$100k annual value or <10% improvement)
- Note: Adjust these thresholds based on client size and context
- You MUST assess measurability for each outcome:
- Highly Measurable: Clear quantitative metrics, easy to track
- Moderately Measurable: Mix of quantitative and qualitative indicators
- Difficult to Measure: Primarily qualitative, subjective assessment required
- You MUST include both quantitative and qualitative success metrics
- You MUST identify any outcomes that lack clear success criteria and flag them for clarification
- You MUST include explicit reasoning for categorization and assessment decisions:
- For each outcome categorization: Explain why it was placed in that category (e.g., "Categorized as Revenue outcome because it directly enables new sales through...")
- For each impact magnitude assessment: Explain the calculation or logic (e.g., "Estimated High Impact ($600k annual) based on 30% ticket reduction × 2 FTE @ $150k/year...")
- For each stakeholder identification: Explain why they care about this outcome
- For each measurability assessment: Explain what makes it easy/hard to measure
- You MUST save the business outcomes analysis to "{working_directory}/business-outcomes-draft.md" (with "-draft" suffix)
- You MUST include a Review Summary at the top of the artifact
- After human approval, You MUST rename the file from "business-outcomes-draft.md" to "business-outcomes.md"
Review Summary Requirements for business-outcomes.md:
- Key Findings: Total outcome count by category, primary outcome types, stakeholder distribution
- Red Flags: Outcomes without measurable criteria, conflicting outcomes, unrealistic success targets, outcomes that can't be validated
- Critical Decisions: How outcomes were categorized, how impact magnitude was assessed
- Critical Assumptions: Baseline metrics assumptions, impact value calculations
- Approval Checklist: Verify all outcomes are captured, verify success criteria are realistic and measurable, verify stakeholder mapping is correct, verify no outcomes are impossible to validate
Human Review Gate: After generating business-outcomes-draft.md, you MUST:
- Present the Review Summary to the user
- Ask the user to review the draft artifact
- Wait for explicit approval before proceeding
- If feedback is provided, update the draft artifact and re-present for approval
- Once approved, rename "business-outcomes-draft.md" to "business-outcomes.md"
- Only proceed to Step 4 after the artifact is approved and renamed
Evaluate the broader business context to understand which outcomes align with strategic priorities.
Constraints:
- You MUST analyze the following context factors for each business outcome:
- Strategic alignment: How each outcome supports organizational strategy, mission, and long-term goals
- Market timing: Windows of opportunity, competitive pressures, first-mover advantages, market trends
- User urgency: Critical pain points vs. nice-to-haves, severity of current problems, user demand intensity
- Resource availability: Team capacity, capability constraints, budget limitations, technology constraints
- Technical feasibility: Technology maturity, integration complexity, known technical challenges
- Risk factors: Technical risks, market risks, organizational risks, dependency risks
- You MUST identify any external factors that create urgency including:
- Regulatory deadlines or compliance requirements
- Competitive threats or market disruption
- Market windows or seasonal timing
- Funding milestones or investor expectations
- Contract renewals or customer commitments
- You MUST assess organizational readiness for change in each outcome area:
- Stakeholder buy-in and support
- Change management capacity
- Process maturity and readiness
- Cultural alignment
- Resource availability for adoption
- You MUST identify potential blockers or dependencies for each outcome:
- Technical dependencies (infrastructure, integrations, third-party services)
- Organizational dependencies (other initiatives, decision makers, resource allocation)
- External dependencies (vendors, partners, regulatory approval)
- Sequential dependencies (prerequisites that must be completed first)
- You MUST assess the client's risk tolerance and how it affects outcome feasibility:
- Conservative clients: Favor proven approaches, incremental change, low technical risk
- Moderate clients: Balance innovation with pragmatism, accept managed risk
- Aggressive clients: Willing to take bigger bets, embrace novel approaches, higher risk tolerance
- You SHOULD identify potential synergies between outcomes (where pursuing one outcome enables or accelerates another)
- You MUST include explicit reasoning for all assessments:
- For each strategic alignment rating: Explain how the outcome supports specific strategic goals
- For each urgency assessment: Explain what creates the urgency (market pressure, deadline, pain severity, etc.)
- For each feasibility concern: Explain the specific constraints or risks that affect feasibility
- For each blocker identified: Explain why it's a blocker and what would be needed to remove it
- For risk tolerance interpretation: Explain what evidence led to the assessment
- You MUST document context analysis in "{working_directory}/business-context-analysis-draft.md" (with "-draft" suffix)
- You MUST include a Review Summary at the top of the artifact
- After human approval, You MUST rename the file from "business-context-analysis-draft.md" to "business-context-analysis.md"
- You MUST NOT ignore organizational or cultural constraints because these often determine actual feasibility more than technical factors
Review Summary Requirements for business-context-analysis.md:
- Key Findings: Primary strategic drivers, most urgent outcomes, major constraints identified, risk tolerance assessment
- Red Flags: Outcomes with major blockers, unrealistic timelines given constraints, resource availability concerns, organizational readiness gaps, cultural resistance risks
- Critical Decisions: How strategic alignment was assessed, risk tolerance interpretation
- Critical Assumptions: Market timing assumptions, stakeholder support assumptions, resource availability assumptions
- Approval Checklist: Verify strategic priorities are correctly understood, verify constraints are accurately captured, verify urgency factors are valid, verify organizational readiness assessment is realistic
Human Review Gate: After generating business-context-analysis-draft.md, you MUST:
- Present the Review Summary to the user
- Ask the user to review the draft artifact
- Wait for explicit approval before proceeding
- If feedback is provided, update the draft artifact and re-present for approval
- Once approved, rename "business-context-analysis-draft.md" to "business-context-analysis.md"
- Only proceed to Step 5 after the artifact is approved and renamed
Rank business outcomes using a multi-dimensional prioritization framework to identify the top outcome that should drive MVP/Phase 1.
Constraints:
- You MUST evaluate each business outcome across these six dimensions (1-5 scale, 5 = best):
- Strategic Value (1-5): Alignment with business strategy and long-term goals
- 5: Mission-critical, core to business strategy
- 4: Strongly aligned with strategic priorities
- 3: Supports strategy, not central
- 2: Tangential to strategy
- 1: Minimal strategic connection
- User Impact (1-5): Magnitude of improvement to user experience or pain point resolution
- 5: Solves critical pain point affecting all users
- 4: Major improvement to frequent user activities
- 3: Moderate improvement to some user workflows
- 2: Minor convenience for subset of users
- 1: Negligible user-facing impact
- Revenue Potential (1-5): Direct or indirect revenue impact
- 5: >$1M annual revenue impact or enables major deals
- 4: $500k-$1M annual revenue impact
- 3: $100k-$500k annual revenue impact
- 2: $50k-$100k annual revenue impact
- 1: <$50k annual revenue impact
- Note: Adjust thresholds based on client size
- Time to Value (1-5): How quickly benefits can be realized (5 = fastest)
- 5: Value realized within 4-8 weeks
- 4: Value realized within 8-12 weeks
- 3: Value realized within 12-16 weeks
- 2: Value realized within 16-24 weeks
- 1: Value realized after 6+ months
- Implementation Risk (1-5): Technical and organizational risk (5 = lowest risk)
- 5: Proven approach, minimal dependencies, low complexity
- 4: Mostly familiar territory, manageable risks
- 3: Some novel aspects, moderate complexity
- 2: Significant unknowns, high complexity
- 1: Highly uncertain, experimental, many dependencies
- Resource Efficiency (1-5): Return on investment of development effort (5 = best ROI)
- 5: Massive value for minimal effort
- 4: Strong ROI, efficient value delivery
- 3: Reasonable ROI, effort matches value
- 2: Marginal ROI, high effort for moderate value
- 1: Poor ROI, disproportionate effort
- Strategic Value (1-5): Alignment with business strategy and long-term goals
- You MUST calculate a weighted priority score for each outcome based on the organization's risk tolerance:
- Conservative weighting:
- Time to Value: 25%
- Implementation Risk: 25%
- Strategic Value: 20%
- Revenue Potential: 15%
- User Impact: 10%
- Resource Efficiency: 5%
- Moderate weighting (balanced):
- Strategic Value: 20%
- Revenue Potential: 20%
- User Impact: 20%
- Time to Value: 15%
- Implementation Risk: 15%
- Resource Efficiency: 10%
- Aggressive weighting:
- Strategic Value: 30%
- Revenue Potential: 30%
- User Impact: 15%
- Resource Efficiency: 10%
- Time to Value: 10%
- Implementation Risk: 5%
- Conservative weighting:
- You MUST calculate the weighted score for each outcome: Sum(Dimension Score × Weight)
- You MUST rank all outcomes by their weighted priority score (highest to lowest)
- You MUST identify the top 3 highest-priority outcomes
- You MUST clearly document the rationale for the top-ranked outcome including:
- Why it scored highest across the dimensions
- What makes it the best choice for Phase 1/MVP focus
- How it compares to the other top contenders
- Any close calls or tie-breaking decisions made
- You MUST flag any outcomes that scored very close to each other (within 0.3 points) as "close calls" requiring human judgment
- You MUST create a visual representation of the prioritization using a markdown table:
| Outcome | Strategic Value | User Impact | Revenue Potential | Time to Value | Implementation Risk | Resource Efficiency | Weighted Score | Rank | |---------|----------------|-------------|-------------------|---------------|---------------------|---------------------|----------------|------| | ... | X/5 | X/5 | X/5 | X/5 | X/5 | X/5 | X.XX | 1 | - You SHOULD create a value/effort matrix visualization in markdown table format showing outcomes plotted by value (Strategic Value + Revenue Potential + User Impact) vs. effort (inverse of Resource Efficiency and Implementation Risk)
- You MUST include detailed reasoning for ALL scoring decisions:
- For EACH outcome's EACH dimension score: Provide 1-2 sentence explanation of why that specific score was assigned
- For example: "Strategic Value: 5/5 - This outcome directly addresses the company's #1 strategic priority of reducing customer churn, mentioned explicitly in the business context as 'mission-critical'"
- For revenue potential: Show the calculation or estimation logic (e.g., "$400k annual = 50% stock-out reduction × $800k current annual stock-out costs")
- For time to value: Explain the timeline estimate and key assumptions
- For implementation risk: Identify the specific risks that drove the score
- For resource efficiency: Compare effort to value delivered
- You MUST explain the weighting choice:
- Why conservative/moderate/aggressive was selected based on client profile
- How the weighting reflects their priorities and constraints
- You MUST explain any tie-breaking decisions:
- What factors were considered to break ties between close-scoring outcomes
- Why one outcome was prioritized over another when scores were similar
- You MUST save the prioritization analysis to "{working_directory}/outcome-prioritization-draft.md" (with "-draft" suffix)
- You MUST include a Review Summary at the top of the artifact
- After human approval, You MUST rename the file from "outcome-prioritization-draft.md" to "outcome-prioritization.md"
Review Summary Requirements for outcome-prioritization.md:
- Key Findings: Top 3 outcomes with scores, winning outcome and why, close calls that need judgment, weighting approach used
- Red Flags: Controversial rankings, outcomes that scored well on some dimensions but poorly on others, very close scores requiring tiebreaker, outcomes where scoring seems counterintuitive
- Critical Decisions: Weighting rationale, how ties were broken, dimension score justifications for top outcomes
- Critical Assumptions: Revenue impact calculations, risk assessments, time-to-value estimates
- Approval Checklist: Verify top outcome makes intuitive sense, verify scoring reflects business priorities, verify no obviously better outcome was ranked lower, verify weighting is appropriate for client's risk tolerance, verify close calls are identified
Human Review Gate: After generating outcome-prioritization-draft.md, you MUST:
- Present the Review Summary to the user
- Highlight the top-ranked outcome and the rationale
- Call out any close calls or controversial rankings
- Ask the user to review and confirm agreement with the prioritization
- Wait for explicit approval before proceeding
- If the user disagrees with the ranking, discuss the reasoning and adjust scoring/weighting as needed, then update the draft and re-present for approval
- Once approved, rename "outcome-prioritization-draft.md" to "outcome-prioritization.md"
- Only proceed to Step 6 (generate SOP 2 execution prompt) after the artifact is approved and renamed
Create the complete execution prompt for the next SOP in the sequence, including all necessary parameters and file paths.
Constraints:
- You MUST generate a prompt that includes:
- Clear instruction to execute SOP 2 (Milestone Scoping & Task Decomposition)
- All file paths to artifacts generated in this SOP
- The original prd_document path
- Any optional parameters that should carry forward (timeline_constraints, budget_range, etc.)
- The working_directory path
- You MUST format the prompt as a ready-to-use execution command
- You MUST include a brief summary of what was accomplished in SOP 1 to provide context
- You MUST list the top-priority outcome that will drive Phase 1/MVP definition
- You SHOULD include any important caveats, assumptions, or notes that the next SOP should be aware of
Prompt Template:
✅ SOP 1 (Discovery & Outcome Prioritization) completed successfully.
## Summary of SOP 1 Outputs:
- **Top Priority Outcome**: [Outcome name and brief description]
- **Priority Score**: [X.XX/5.00]
- **Key Rationale**: [1-2 sentence summary of why this outcome was prioritized]
- **Technical Context**: [Decided vs. TBD summary - e.g., "Stack: React/Node/Postgres on AWS (decided), Mobile: TBD in Phase 1"]
- **Artifacts Generated**:
- prd-breakdown.md
- technical-context.md
- business-outcomes.md
- business-context-analysis.md
- outcome-prioritization.md
## Next Step:
Execute **SOP 2: Milestone Scoping & Task Decomposition** to define the MVP/Phase 1 scope and structure the remaining milestone phases.
---
## SOP 2 Execution Prompt:
Execute the Milestone Scoping & Task Decomposition SOP (proposalgen-sop-2-milestone-scoping.sop.md) with the following parameters:
**Required Parameters:**
- prd_document: "[path/to/prd-source.md]"
- prd_breakdown: "[path/to/prd-breakdown.md]"
- technical_context: "[path/to/technical-context.md]"
- business_outcomes: "[path/to/business-outcomes.md]"
- business_context_analysis: "[path/to/business-context-analysis.md]"
- outcome_prioritization: "[path/to/outcome-prioritization.md]"
- top_priority_outcome: "[Name of the #1 ranked outcome]"
**Optional Parameters:**
[Include any optional parameters that were provided in SOP 1]
- timeline_constraints: "[value if provided]"
- budget_range: "[value if provided]"
- resource_constraints: "[value if provided]"
- risk_tolerance: "[value, default: moderate]"
- working_directory: "[path/to/proposal-outputs]"
**Important Context for SOP 2:**
[Include any important notes, caveats, or assumptions that SOP 2 should be aware of]
- [Note 1]
- [Note 2]
Output:
- You MUST present this prompt to the user
- You MUST clearly indicate that SOP 1 is complete and they should execute the prompt above when ready to proceed
- You SHOULD remind the user that they can modify any of the parameters before executing SOP 2 if needed
Every artifact generated in this SOP MUST include a Review Summary section at the very top, using this exact template:
# [Artifact Name]
## 📋 REVIEW SUMMARY
**Status**: Ready for Review
**Generated**: [ISO 8601 timestamp]
**Confidence Level**: [X/100] - [High (80-100) / Medium (60-79) / Low (40-59) / Very Low (<40)]
### 🎯 Key Findings
- [3-5 bullet points with the most important conclusions]
- [Key numbers, decisions, or outcomes]
- [What changed from inputs to outputs]
### ⚠️ RED FLAGS & SCRUTINY AREAS
**High Priority Issues:**
- [Things that are risky, uncertain, or could derail the project]
- [Assumptions that might be wrong]
- [Gaps in information or analysis]
**Moderate Concerns:**
- [Areas that need validation but aren't show-stoppers]
- [Ambiguities that should be clarified]
### 🔑 Critical Decisions & Assumptions
**Decisions Made:**
- [Key choices that affect downstream work]
- [Trade-offs and rationale]
**Critical Assumptions:**
- [Assumptions this analysis depends on]
- [What happens if these assumptions are wrong]
### 📊 Quantitative Summary
- [Key metrics, counts, totals relevant to this artifact]
- [Percentages, scores, confidence intervals]
### ✅ Approval Checklist
Before approving, verify:
- [ ] [Specific thing #1 to check - tailored to this artifact]
- [ ] [Specific thing #2 to check - tailored to this artifact]
- [ ] [Specific thing #3 to check - tailored to this artifact]
- [ ] No major elements overlooked
- [ ] Assumptions are reasonable and documented
**Action**: If approved, proceed to next step. If issues found, document feedback and request revisions.
---
## DETAILED ANALYSIS
[Full artifact content follows...]prd_document: "path/to/inventory-management-system-prd.md"
business_context: "Mid-sized manufacturing company, 200 employees. Currently using spreadsheets for inventory. Growth causing stock-outs and excess inventory. Manual processes consuming 2 FTEs. Risk-averse organization with limited IT staff. Need to prove value before full commitment."
timeline_constraints: "CEO wants to see progress before Q4 budget cycle (6 months out). Year-end inventory requires system operational by December."
budget_range: "$180k-$250k, prefer phased investment to spread cost"
success_metrics: "Reduce stock-outs by 50%, reduce excess inventory by 30%, reduce manual effort by 1.5 FTE, achieve inventory accuracy >95%"
risk_tolerance: "conservative"
change_readiness: "Operations team frustrated with current spreadsheet chaos and eager for improvement. Finance team concerned about cost. IT team has limited bandwidth for support."
working_directory: "./inventory-mgmt-proposal"
# Business Outcome Prioritization Analysis
## 📋 REVIEW SUMMARY
**Status**: Ready for Review
**Generated**: 2025-01-15T14:32:00Z
**Confidence Level**: 78/100 - Medium-High
### 🎯 Key Findings
- 7 distinct business outcomes identified from PRD and business context
- **Top Priority Outcome**: "Achieve accurate real-time inventory visibility to reduce stock-outs" (Score: 4.35/5.00)
- Conservative weighting applied based on risk-averse organizational profile
- Close call between top outcome (4.35) and #2 "Reduce manual effort and labor costs" (4.10) - only 0.25 point difference
- All outcomes have measurable success criteria; inventory accuracy is most quantifiable
### ⚠️ RED FLAGS & SCRUTINY AREAS
**High Priority Issues:**
- **Close scoring**: Top 2 outcomes scored within 0.25 points - prioritization could go either way depending on stakeholder input
- **Timeline tension**: Top outcome (inventory visibility) estimated at 10-12 weeks vs. labor reduction (8-10 weeks), but labor reduction scored lower on strategic value
- **Resource constraints**: IT bandwidth concerns may affect implementation risk scoring for integration-heavy outcomes
**Moderate Concerns:**
- Revenue potential scoring is somewhat speculative - based on rough $400k annual stock-out cost estimate from PRD
- Implementation risk for ERP integration (part of top outcome) may be underestimated if ERP API is poorly documented
- User impact scoring assumes operations team's enthusiasm translates to adoption - change management could be harder than expected
### 🔑 Critical Decisions & Assumptions
**Decisions Made:**
- Applied Conservative weighting (Time to Value: 25%, Implementation Risk: 25%) based on risk-averse culture and "need to prove value" requirement
- Prioritized inventory visibility over labor reduction despite labor reduction being faster to value, because inventory visibility has stronger strategic alignment and revenue impact
- Scored "automated reordering" lower due to high technical complexity and dependency on having accurate inventory data first
**Critical Assumptions:**
- Stock-out reduction directly correlates with inventory accuracy (assumed 95% accuracy → 50% stock-out reduction)
- $400k annual cost of stock-outs (from PRD) is accurate
- Operations team's eagerness for change means high user adoption likelihood
- ERP integration is feasible within moderate risk profile (scored 3/5 on Implementation Risk)
- 10-12 week timeline for inventory visibility is achievable given team constraints
### 📊 Quantitative Summary
- **Total Outcomes Evaluated**: 7
- **Outcome Categories**: 3 Revenue, 2 Efficiency, 1 User Experience, 1 Risk Mitigation
- **Top Score**: 4.35/5.00 (Inventory Visibility & Stock-out Reduction)
- **Lowest Score**: 2.45/5.00 (Advanced Analytics & Forecasting)
- **Close Calls (within 0.3 points)**: Outcomes #1 and #2 (0.25 point difference)
- **Weighting Applied**: Conservative (Risk-averse organization)
### ✅ Approval Checklist
Before approving, verify:
- [ ] Top outcome (Inventory Visibility) aligns with CEO's expectation to "see progress before Q4" and makes business sense
- [ ] Conservative weighting is appropriate given risk-averse culture (vs. moderate or aggressive)
- [ ] Close call between #1 and #2 has been reviewed - confirm #1 is the right choice or if #2 (labor reduction) should be prioritized instead
- [ ] Revenue potential estimates ($400k stock-out costs) are realistic
- [ ] Implementation risk scores (especially for ERP integration) reflect reality
- [ ] Timeline estimates (10-12 weeks for top outcome) are feasible
- [ ] No major elements overlooked
- [ ] Assumptions are reasonable and documented
**Action**: If approved, proceed to SOP 2. If #2 outcome (labor reduction) should be prioritized instead, provide feedback to adjust ranking.
---
## DETAILED ANALYSIS
### Prioritization Framework
**Risk Tolerance**: Conservative
**Weighting Applied**:
- Time to Value: 25%
- Implementation Risk: 25%
- Strategic Value: 20%
- Revenue Potential: 15%
- User Impact: 10%
- Resource Efficiency: 5%
### Outcome Rankings
| Rank | Outcome | Strategic Value | User Impact | Revenue Potential | Time to Value | Implementation Risk | Resource Efficiency | Weighted Score |
|------|---------|----------------|-------------|-------------------|---------------|---------------------|---------------------|----------------|
| 1 | Inventory Visibility & Stock-out Reduction | 5/5 | 4/5 | 5/5 | 3/5 | 3/5 | 4/5 | **4.35** |
| 2 | Reduce Manual Effort & Labor Costs | 4/5 | 5/5 | 3/5 | 4/5 | 4/5 | 4/5 | **4.10** |
| 3 | Reduce Excess Inventory & Carrying Costs | 4/5 | 3/5 | 4/5 | 3/5 | 3/5 | 3/5 | **3.50** |
### Detailed Outcome Analysis with Reasoning
#### Outcome #1: Inventory Visibility & Stock-out Reduction (Score: 4.35)
**Strategic Value: 5/5**
*Reasoning*: This outcome directly addresses the company's stated top strategic priority of improving inventory accuracy and reducing lost sales from stock-outs. The business context explicitly mentions "growth causing stock-outs" and CEO's requirement to "see progress before Q4 budget cycle." This is mission-critical to the business.
**User Impact: 4/5**
*Reasoning*: Affects all operations team members (primary users) who currently struggle with spreadsheet-based tracking. Addresses the severe pain point mentioned in context: "frustrated with current spreadsheet chaos." Not 5/5 because it primarily benefits internal operations team, not end customers directly.
**Revenue Potential: 5/5**
*Reasoning*: Success metrics state "Reduce stock-outs by 50%." Estimated $400k annual revenue impact based on: Current stock-out costs not explicitly stated in PRD, but 50% reduction in stock-outs for a 200-employee manufacturing company experiencing "growth causing stock-outs" conservatively estimated at $800k annual impact = $400k savings. Enables revenue that's currently being lost.
**Time to Value: 3/5**
*Reasoning*: Estimated at 10-12 weeks to achieve inventory visibility for initial SKU set. This is moderate speed - not fastest (would be 4-8 weeks for 5/5) but reasonable given the need for integration and user adoption. Timeline constrained by need to integrate with existing systems and train operations team.
**Implementation Risk: 3/5**
*Reasoning*: Moderate risk due to: (1) Need to integrate with existing ERP system (mentioned as dependency), (2) Data migration from spreadsheets to structured database, (3) User adoption required across operations team. However, inventory tracking is a well-understood problem domain with proven solutions, preventing this from being high-risk (1-2/5). IT team has "limited bandwidth" which adds to risk.
**Resource Efficiency: 4/5**
*Reasoning*: Strong ROI - estimated $400k annual benefit vs. estimated 10-12 weeks effort (roughly $80-100k investment based on typical 3-person team). Ratio of 4:1 or better annual return. Not 5/5 because ERP integration adds effort without direct user-facing value.
**Overall**: Top-ranked because it combines mission-critical strategic value (5/5) with strong revenue impact (5/5) while maintaining acceptable risk (3/5) - critical for conservative risk tolerance weighting.
---
#### Outcome #2: Reduce Manual Effort & Labor Costs (Score: 4.10)
**Strategic Value: 4/5**
*Reasoning*: Business context states manual processes are "consuming 2 FTEs" and success criteria includes "reduce manual effort by 1.5 FTE." This is a clear strategic priority but secondary to the stock-out problem based on context emphasis. Scored 4/5 instead of 5/5 because it's an efficiency play rather than the revenue-critical issue.
**User Impact: 5/5**
*Reasoning*: Directly reduces daily frustration for operations team doing manual data entry. Success metric of "1.5 FTE reduction" means massive impact on user daily experience. Operations team is "eager for improvement" per change readiness assessment. Maximum score because it eliminates repetitive manual work.
**Revenue Potential: 3/5**
*Reasoning*: $225k annual savings calculation: 1.5 FTE × $150k fully-loaded cost = $225k. This is moderate revenue impact - significant but less than the $400k from stock-out reduction. Indirect revenue impact through operational efficiency vs. direct revenue impact.
**Time to Value: 4/5**
*Reasoning*: Estimated 8-10 weeks - faster than inventory visibility outcome because labor reduction can be achieved through basic automation without complex ERP integration. Can show manual effort reduction quickly once basic data entry automation is in place.
**Implementation Risk: 4/5**
*Reasoning*: Lower risk than inventory visibility because: (1) Doesn't require ERP integration initially, (2) Proven automation patterns, (3) High user eagerness reduces adoption risk. Scored 4/5 instead of 5/5 because change management still needed for process changes.
**Resource Efficiency: 4/5**
*Reasoning*: Good ROI - $225k annual benefit vs. 8-10 weeks effort (~$60-80k investment) = 3:1 ratio. Slightly lower than Outcome #1 in absolute dollars but faster time to achieve.
**Overall**: Close second place (only 0.25 points behind #1). Loses to Outcome #1 primarily because Conservative weighting emphasizes Strategic Value (20%) and Implementation Risk (25%), where Outcome #1 has advantages. Under Aggressive weighting, these two would be much closer or potentially reversed.
[... analysis continues for other outcomes ...]If the PRD focuses primarily on features without explicit business outcomes:
- Infer business outcomes from the problem statement and user pain points
- Ask clarifying questions about the business goals and success metrics using interview-style prompts
- Document assumptions about intended outcomes and clearly mark them as "inferred" vs. "stated"
- Flag these inferred outcomes in the Red Flags section of the Review Summary
- Proceed with best-judgment outcome identification clearly marked as assumptions requiring validation
- Recommend that the client provide additional context or validate the inferred outcomes
If insufficient business context is provided:
- Request specific information about strategic priorities, market conditions, and constraints before proceeding
- If user cannot provide context, make reasonable assumptions based on:
- Industry norms and standard business drivers
- Company size and maturity level
- Problem severity indicated in the PRD
- Document all assumptions prominently in the Review Summary Red Flags section
- Use conservative estimates for impact and risk (when in doubt, score lower)
- Build in flexibility for scope adjustment as more context emerges
- Apply "Medium" confidence level and note that additional context could change prioritization
If several outcomes score within 0.3 points of each other:
- Flag this as a "close call" in the Review Summary
- Present all closely-scored outcomes to the user with detailed comparison
- Look for tiebreaker factors:
- Outcomes that enable or accelerate other outcomes (choose the enabler)
- External forcing functions (deadlines, market windows, competitive threats)
- Which outcome provides the strongest validation of core assumptions
- Which outcome has lowest implementation risk if other factors are equal
- Document the close decision and note that runner-up outcomes should be addressed in Phase 2
- Recommend user input to make the final prioritization decision
- Do NOT arbitrarily pick one - surface the decision to the human reviewer
If the PRD lacks specific, measurable success criteria:
- Create reasonable proxy metrics based on the problem statement
- Use industry benchmarks or standard metrics for similar outcomes
- Mark these as "proposed" or "assumed" metrics requiring validation
- Include specific questions in the Review Summary for the user to clarify
- Flag in Red Flags section that success validation may be difficult
- Recommend that the client define clear success metrics before proceeding to implementation
- Consider whether lack of metrics should lower the priority score for that outcome
If risk tolerance is not specified or ambiguous:
- Default to "moderate" risk tolerance weighting
- Present outcomes using all three weighting approaches (conservative, moderate, aggressive) to show how rankings change
- Ask specific questions to clarify:
- "Is the organization willing to take bigger bets for potentially higher returns?"
- "Is proving value quickly more important than maximizing strategic impact?"
- "How much appetite is there for novel/unproven approaches?"
- Document the uncertainty in the Review Summary
- Note that the prioritization may change based on confirmed risk tolerance
If the top-priority outcome appears infeasible given stated constraints:
- DO NOT artificially adjust scores to make outcomes fit constraints
- Clearly document the conflict in the Review Summary Red Flags
- Present the prioritization as-is based on business value
- Flag that SOP 2 will need to address scope trade-offs or SOP 3 may reveal timeline/budget issues
- Provide options for the user:
- Prioritize a different outcome that fits constraints
- Adjust constraints (extend timeline, increase budget)
- Plan for a more limited Phase 1 scope that fits constraints
- Let the user decide how to resolve the conflict before proceeding
If the user reviews the prioritization and disagrees:
- Ask clarifying questions to understand their reasoning
- Identify which dimension scores they disagree with and why
- Adjust scores based on their input (they have better business context)
- Consider whether different weighting would better reflect priorities
- Regenerate the prioritization with adjusted scores/weights
- Document the changes made and the rationale in the artifact
- Re-present for approval
- Remember: The user is the expert on their business priorities - defer to their judgment