Skip to content
Back to Idea Validation

Solution Mapping

Map multiple candidate solutions against the ranked pains to find the best fit, not just the first idea.

Why

Your first idea is rarely your best solution. Solution mapping forces you to generate 3-5 different approaches to the same problem and evaluate them against your ranked pains. This prevents two failures: building the first idea that turns out to be the wrong approach, and over-investing in one solution when a simpler one would work. For the pain "maintainers waste weekends reviewing PRs", the solutions include an AI review bot, a community review pool, a checklist template, and a PR-size-linting rule — each solves the pain differently with different tradeoffs. Mapping them side by side reveals which has the best fit-to-pain ratio and the least implementation risk.

When

After pain point ranking, before committing to a solution. Takes half a day. Revisit if your chosen solution fails validation.

How

1. Generate 3-5 candidate solutions
   - Include your first idea, but also force alternatives
   - Techniques: "opposite approach" (bot vs. template), "remove a layer" (no AI, just rules), "borrow from adjacent domain"

2. For each solution, evaluate against the top 3 pains
   - Does it solve pain #1? How well? (fully / partially / no)
   - Does it also address #2 and #3? (bonus or irrelevant)
   - What pains does it NOT solve? (be honest)

3. Evaluate implementation tradeoffs
   - Effort: how long to build a testable version? (days / weeks / months)
   - Risk: what could make it fail? (tech risk, adoption risk, business risk)
   - Cost: ongoing cost to operate (compute, manual, infra)

4. Score each solution
   - Fit = how well it solves the top pains (1-5)
   - Efficiency = fit / effort (high fit, low effort = efficient)
   - Risk-adjusted = efficiency × (1 - risk probability)

5. Choose and document why
   - Pick the highest risk-adjusted score
   - Write 2 sentences on why this solution over the others
   - Note what would make you switch to the #2 solution (your fallback)

Example

Pain #1: "maintainers waste weekends reviewing PRs"

Candidate solutions:
  A. AI review bot (pre-vets PRs, comments issues)
     Fit: 5 (directly reduces review time), Effort: 8 weeks, Risk: medium (AI quality)
  B. Community review pool (other maintainers review your PRs)
     Fit: 3 (helps but coordination overhead), Effort: 12 weeks, Risk: high (chicken-and-egg)
  C. PR checklist + size linting (forces PRs to be small and self-documenting)
     Fit: 3 (reduces review time per PR, not count), Effort: 1 week, Risk: low
  D. Async review scheduler (batches reviews into 2h weekday blocks)
     Fit: 2 (moves the pain, does not reduce it), Effort: 2 weeks, Risk: low

Scores (fit / effort, risk-adjusted):
  A: 5/8 = 0.63 × 0.7 = 0.44  ← chosen
  B: 3/12 = 0.25 × 0.4 = 0.10
  C: 3/1 = 3.0 × 0.9 = 2.70  ← actually highest!
  D: 2/2 = 1.0 × 0.9 = 0.90

Surprise: solution C (checklist + linting) scores highest — simplest, lowest risk, decent fit.
Decision: start with C (ship in 1 week, validate it helps), then build A (AI bot) if C is insufficient.
Fallback: if C does not reduce weekend reviewing by > 30%, build A.

Common Problems

  • ⚠Only evaluating your first idea — without forced alternatives, you never discover that a simpler solution scores higher.
  • ⚠Ignoring effort in the score — a solution with fit 5 and effort 6 months is worse than fit 3 and effort 1 week; always divide by effort.
  • ⚠Underestimating risk for the exciting solution — AI bots have tech risk (quality) and adoption risk (will maintainers trust it); score honestly.
  • ⚠Choosing the highest-fit solution without checking efficiency — a 5-fit/6-month solution delays learning; a 3-fit/1-week solution lets you iterate.

Best Practices

  • ✓Force at least 3 alternatives, including one "boring" solution (template, rule, checklist) — these often score highest on efficiency.
  • ✓Score fit / effort (efficiency), not just fit — a fast-to-build partial solution lets you learn and iterate, which often beats a slow perfect one.
  • ✓Document the fallback: "if solution A does not reduce the pain by X%, switch to solution B" — this pre-commits to a pivot instead of sunk-cost escalation.
  • ✓Start with the most efficient solution even if fit is partial — you can always build the higher-fit one later, and you will have learned what matters by then.