Discovery-to-decision: step 3 (solution candidates)

Why it works

Step 3 of the chain. Takes the top theme from step 2 and generates 2-3 distinct solution candidates - not variations of one solution, but genuinely different approaches. The output is structured per candidate: what we'd build, how it addresses the theme, rough engineering effort, and what we'd need to validate before committing. Step 4 turns the strongest candidate into a decision memo. The 'distinct approaches' constraint matters - PMs and AI both default to 'one obvious solution + minor variations.' Forcing genuinely different approaches surfaces the tradeoffs you'd otherwise discover too late. Tested cleanest on Claude Opus 4.7.

Example output

Top theme being addressed: Setup friction (14 mentions, 100% of new users affected).

Solution candidate A: Defer all permissions until first feature use.
What we'd build: Show a clean dashboard immediately on launch. Permission prompts trigger only when the user clicks a feature that needs them.
How it addresses the theme: Removes 4 of 4 setup-time permission screens. New users see value before they see friction.
Engineering effort: ~1 week. Mostly UI restructuring; permission requests already exist as separate flows.
What to validate: Does deferred permission asking hurt eventual permission grant rate? (Hypothesis: no - users who've seen the value will say yes; users who quit before hitting the feature wouldn't have said yes anyway.)

Solution candidate B: Replace 4 permission screens with 1 'we need 4 permissions, here's why' screen.
What we'd build: Single screen that lists all 4 permissions with one-line rationales, then one tap fires all 4 system prompts in sequence.
How it addresses the theme: Reduces user-perceived screen count from 4 to 1. Still front-loads all permissions.
Engineering effort: ~3 days.
What to validate: Does batching the system prompts hurt grant rate vs. asking individually? (Hypothesis: marginally; system permission prompts have their own UX we don't control.)

Solution candidate C: Skip permissions entirely; use a degraded mode that works without them.
What we'd build: Core copy/paste features work with zero permissions. Power features (clipboard history, sync) only prompt when their UI is invoked.
How it addresses the theme: Maximally permissionless onboarding. New users get to value with literally zero friction.
Engineering effort: ~3 weeks. Larger because some current architecture assumes permissions at startup.
What to validate: Is the degraded-mode value enough to justify retention? (Hypothesis: yes for casual users, no for power users - but casual users are who we're losing, so this is the right tradeoff.)

--- End of step 3. Pick the strongest candidate and paste it into 'Discovery-to-decision: step 4 (decision memo)'. ---

Common mistakes

Don't accept candidates that are minor variations of one approach. If A and B both 'reduce the permission count,' they're the same solution; force the model to generate a structurally different option C. Also: do not skip the 'what to validate' line per candidate. Each candidate carries unstated assumptions; surfacing them now means you decide what to test before you commit, not after.