Stg Designing Solutions

---
name: stg-designing-solutions
description: Designs solution architecture, selects growth model, assembles positioning, maps features to problems, and defines MVP scope. Use when constructing Solution Design section during BUILD phase 2.
serves: strategist
domain: solution-design
affects: solution-design-section
depends-on: none
produces: Solution Design section in register format
---

# Solution Design

Design solution architecture: select growth model, assemble positioning, map features to problems, define MVP scope, design growth loops. Output is the Solution Design section of the register -- a derived design artifact constrained by all three hypotheses, not a hypothesis itself.

## Procedure

### Step 1: Load Hypothesis Context [S]

Read: problem, segment, unit economics hypotheses. Also read competitive analysis (gaps, alternatives) for positioning assembly.

Extract constraints each hypothesis places on the solution:
- **Problem** -> what must be solved (top problems by severity)
- **Segment** -> buyer type (user=buyer or committee), ACV range, time-to-value expectations
- **Unit Economics** -> cost constraints (gross margin target, COGS limits)

Extract positioning inputs:
- **Problem claim** -> the problem statement for the positioning template
- **Segment claim** -> the target for the positioning template
- **Competitive analysis** -> alternatives and gaps for the "unlike" clause
- **Aha moment** (assembled in Step 5) -> unique capability clause

Produce: hypothesis constraints table + positioning inputs.

**Gate:** `constraints_extracted: bool` -- at least one constraint from each hypothesis documented, positioning inputs identified.
- Pass: Step 2.
- Fail: If a hypothesis is missing, note the gap. Proceed with available constraints, flagging reduced confidence.

### Step 2: Select Growth Architecture [R]

Score buyer characteristics against decision matrix:

| Factor | PLG | Network | Traditional | Source |
|--------|-----|---------|-------------|--------|
| ACV | < $5K | < $5K | > $25K | Segment hypothesis |
| Buyer type | User = buyer | User = buyer | Committee | Segment hypothesis |
| Time-to-value | < 1 day | < 1 day | Weeks+ | Product nature |
| Collaboration | Optional | Inherent | Either | Product nature |
| Shareability | Medium | High | Low | Product nature |

For ACV between $5K-$25K: Hybrid. Document which factors pulled in which direction.

Selection is T1/T2 (derivable from segment characteristics).

Produce: growth architecture selection with rationale [T1/T2].

**Gate:** `architecture_selected: bool` -- selection justified by segment characteristics, not asserted.
- Pass: Step 3.
- Fail: If factors conflict (e.g., low ACV but committee buyer), flag the tension and select with documented reasoning.

### Step 3: Assemble Positioning [K-grounded]

**Grounded in:** Problem claim, Segment claim, competitive analysis gaps, growth architecture selection.

Assemble the positioning statement from hypothesis outputs -- this is composition, not hypothesis construction. Every clause traces to an existing hypothesis or research output:

- **Target:** from Segment hypothesis claim
- **Problem:** from Problem hypothesis claim
- **Category:** determine the category the product occupies in the buyer's mind. If category is ambiguous or contested, mark as [GOVERNOR_DECISION] for escalation.
- **Differentiator:** from competitive analysis gaps -- what the product does that alternatives do not
- **Unlike [alternative]:** from competitive analysis -- the primary alternative the target currently uses
- **Unique capability:** from aha moment (forward reference -- finalize after Step 5 defines aha moment, revise positioning if needed)

Produce: assembled positioning statement + category framing decision.

Note: the "unique capability" clause depends on the aha moment defined in Step 5. Write a draft here using competitive gaps. Revise after Step 5 if the aha moment provides a stronger unique capability clause.

**Gate:** `positioning_assembled: bool` -- positioning statement has all six clauses filled (unique capability may be draft), category framing documented.
- Pass: Step 4.
- Fail: Identify which clause cannot be filled. If target or problem clause is empty, the upstream hypothesis is missing -- halt and report.

### Step 4: Map Features to Problems [K-grounded]

**Grounded in:** problem hypothesis (top problems), segment characteristics (jobs addressed).

For each top problem, identify features that solve it. For each feature, classify:

| Job Dimension | What It Means | Example |
|--------------|---------------|---------|
| Functional | What they need accomplished | "Generate reports in 2 minutes" |
| Emotional | How they want to feel | "Feel confident in data accuracy" |
| Social | How they want to be perceived | "Be seen as data-driven leader" |

Flag if all features are functional-only: "Technical founders design for the functional job and ignore emotional and social jobs."

Prioritize each feature:
- **MVP** -- minimum for aha moment
- **POST_MVP** -- important but not for first value
- **FUTURE** -- nice to have or expansion

Produce: feature map with job dimensions and priorities [T2].

**Gate:** `features_mapped: bool` -- every feature traces to a stated problem, at least one non-functional job dimension addressed, priorities assigned.
- Pass: Step 4.
- Fail: Features that do not trace to any stated problem must be removed or the problem must be added to the hypothesis. Every feature must trace.

### Step 5: Define MVP Scope [K-grounded]

**Grounded in:** feature map, growth architecture.

MVP = minimum set that delivers the aha moment.

**Aha moment definition:** the specific experience where the user says "this solves my problem." Must be concrete and experiential:
- Good: "Generate a complete design system from 3 inputs in 90 seconds"
- Bad: "See value in the product", "experience efficiency"

**Time-to-value target:**
- PLG: must be < 1 day from signup
- Network: must be < first interaction with other user
- Traditional: must be < first sales call follow-up

**Excluded features:** list each with why excluded and when to add.

**Mode overlay:**
- BOOTSTRAP -> smallest possible MVP for fastest revenue
- VENTURE -> MVP can be slightly larger if it enables growth loop

Produce: MVP scope with aha moment and time-to-value [T2 for scope, T3 for timing effectiveness].

**Gate:** `mvp_defined: bool` -- aha moment is specific and experiential, time-to-value target stated, excluded features have rationale.
- Pass: Step 6. After defining aha moment, revisit Step 3 positioning -- revise "unique capability" clause if aha moment provides a stronger formulation.
- Fail: If aha moment is vague, rewrite with specific experience, observable outcome, and timeframe. If MVP has >5 features, challenge: which single feature delivers the aha moment? Start there.

### Step 6: Design Growth Loops [K-grounded]

**Grounded in:** growth architecture, feature map, segment characteristics.

For selected architecture, define growth mechanisms:

| Architecture | Loop Pattern | Requires |
|-------------|-------------|----------|
| PLG | Product usage -> sharing -> new signups -> more usage | Shareable output, invite mechanism |
| Network | User joins -> invites others -> network value increases | Collaboration features, density threshold |
| Traditional | Sales close -> implementation success -> referral | Customer success process, case studies |

Each loop: mechanism, what it requires (features, scale), tier label.

Produce: growth loop definitions [T2].

**Gate:** `loops_designed: bool` -- at least 1 growth loop with mechanism, requirements, and tier label.
- Pass: Step 7.
- Fail: If no natural growth loop exists for the architecture, document: "Growth loop is weak -- customer acquisition will depend primarily on paid channels." This is a finding.

### Step 7: Write Solution Design Section [S]

Write complete Solution Design section in register format:

- **Growth Architecture:** {PLG | Network | Traditional | Hybrid} with rationale
- **Architecture Rationale:** ACV, buyer type, time-to-value, collaboration, selection reasoning
- **Positioning:** assembled statement with all six clauses, category framing, category rationale
- **Feature Map:** table with feature, solves problem, job dimension, priority, tier
- **MVP Scope:** included features, aha moment, time-to-value target, excluded features with rationale
- **Growth Loops:** loop name, mechanism, requirements, tier
- **Constraints from Hypotheses:** table with constraint from each hypothesis (Problem, Segment, Unit Economics) and what to re-evaluate if hypothesis changes
- **Adequacy Criteria:** specific, measurable criteria for solution adequacy (not kill conditions -- this is a design artifact, not a hypothesis)
- **Last Updated:** date

Produce: complete Solution Design section.

**Gate:** `section_written: bool` -- all fields populated, positioning statement complete, constraints reference all three hypotheses.
- Pass: Done.
- Fail: Fix missing fields. Ensure constraints table references all three hypotheses. Ensure positioning statement has all six clauses finalized (unique capability revised after aha moment).

## Quality Criteria

- Growth architecture selection justified by segment characteristics (not asserted)
- Positioning statement assembled from hypothesis outputs (not invented independently)
- Every positioning clause traces to a hypothesis claim or competitive analysis output
- Category framing decision documented (with governor escalation if ambiguous)
- Every MVP feature traces to a problem in the Problem hypothesis
- At least one feature addresses emotional or social job (not all functional)
- Aha moment is specific and experiential (not a vague benefit)
- Constraints from all three hypotheses documented
- Excluded features have rationale and "when to add" guidance
- Growth loops are mechanistically described (not just named)

## Failure Modes

| Mode | Signal | Recovery |
|------|--------|----------|
| Feature completeness before launch | MVP contains >5 features or includes "platform" / "ecosystem" language | Flag technical founder pattern. Ask: which single feature delivers the aha moment? Start there. Everything else is POST_MVP until customer evidence demands it |
| Aha moment is vague | "Users see value", "teams get results", "experience efficiency" | Rewrite as specific experience with observable outcome and timeframe. "Complete X task in Y minutes that previously took Z hours" |
| Growth architecture mismatch | PLG selected but ACV >$25K, or Traditional selected but ACV <$2K | Architecture-ACV misalignment. Either the pricing is wrong or the architecture is wrong. Flag for resolution in economics hypothesis |
| Positioning invented rather than assembled | Positioning statement contains claims not traceable to any hypothesis or competitive analysis | Every clause must trace to a source. Target = Segment claim. Problem = Problem claim. Alternative = competitive analysis. If a clause has no source, it is fabrication |
| Solution not constrained by hypotheses | Features that do not trace to any stated problem; growth loops that assume segment behaviors not in evidence | Every feature must trace to the Problem hypothesis. Every growth loop must be consistent with Segment characteristics. Remove untraced elements or add the tracing |

## Boundaries

**In scope:** Growth architecture selection, positioning assembly from hypothesis outputs, feature-to-problem mapping with JTBD dimensions, MVP scope definition with aha moment, growth loop design, hypothesis constraint documentation, adequacy criteria.

**Out of scope:** Pricing design (stg-designing-pricing), economics calculation (stg-calculating-economics), problem scoring (stg-scoring-problems), competitive analysis (stg-analyzing-competition).