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).