Generating Creative Solutions
Given any problem, run it through this sequence before proposing a solution:
- State the obvious solution (so it's not accidentally reused disguised as "creative")
- Invert the constraint — ask "what if the limitation IS the advantage?"
- Cross-pollinate — borrow a mechanism from an unrelated domain (nature, games, other industries)
- Generate 5+ divergent options before judging any of them
- Select and stress-test the strongest 1-2 against real constraints
Example: "We don't have budget for ads" → obvious: cut scope. Inverted: no-budget constraint forces organic/referral mechanics that are more durable than paid growth. Cross-pollinated: borrow "street team" tactics from indie music → ambassador program.
Progress:
- Step 1: Restate the problem in 3 different ways (literal, metaphorical, as someone else's problem)
- Step 2: List the constraints — then mark which are real vs assumed
- Step 3: Invert at least one assumed constraint into a feature
- Step 4: Pull 2-3 analogies from unrelated fields (biology, sports, cooking, military, nature)
- Step 5: Generate a wide net of ideas without filtering (aim for quantity, suspend judgment)
- Step 6: Cluster ideas, kill the obvious/safe ones, keep the uncomfortable ones
- Step 7: Pressure-test top 2-3 ideas against real-world feasibility
- Step 8: Present the chosen idea with the reasoning path, not just the output
Step details
Separating real vs. assumed constraints is the core move. Most "impossible" problems contain at least one constraint that's actually a habit, not a hard rule. Ask explicitly: "Who said this is required? What happens if we break it?"
Analogical thinking: pick domains that solve a structurally similar problem, not a superficially similar one. A scheduling problem is structurally similar to traffic flow or ant foraging, not to other scheduling apps (those are templates, not inspiration).
Suspending judgment during generation is non-negotiable — mixing idea generation with idea evaluation kills originality. Do them in separate passes.
Example 1: Input: "Our product's small screen size is hurting the user experience." Output: Reframe — constraint (small screen) becomes feature (forces ruthless prioritization of content, creating a calmer, more focused UX than competitors' cluttered large-screen apps). Borrowed from analogy: haiku poetry — limitation produces more potent communication, not less.
Example 2: Input: "We can't compete with bigger competitors on price." Output: Don't fight on price — invert into the strength: being small means being fast, personal, and reconfigurable. Analogy from guerrilla warfare: avoid direct confrontation, win through mobility and terrain knowledge (niche focus, direct relationships) rather than scale.
Example 3: Input: "Our onboarding has too many required steps and users drop off." Output: Instead of just trimming steps (obvious), invert: make the required steps feel like progress/reward (gamify them) by borrowing from game design's "quest" structure — same number of steps, radically different drop-off because the psychological framing changed, not the constraint itself.
- Always produce the "obvious" answer first — it's the baseline to beat, and sometimes reveals why people got stuck.
- Favor quantity over quality in the ideation phase; quality comes from selection, not from careful first drafts.
- When stuck, change the question itself ("How do we increase sales?" → "How do we make the customer feel sales happened to them, not at them?").
- Use constraints as creative fuel — they narrow the search space, which paradoxically makes novel combinations easier to find.
- Keep one "uncomfortable" idea in every final shortlist — if all surviving ideas feel safe, the divergent step didn't go far enough.
- Judging ideas too early. Evaluating during generation collapses the idea space back to familiar territory.
- Mistaking novelty for usefulness. A wild idea with zero feasibility is not a solution — it's raw material. Always stress-test.
- Borrowing superficial analogies. "This app is like Uber but for X" is a template, not original thinking — look for structural, not surface, similarity.
- Treating all constraints as fixed. Many "requirements" are inherited assumptions nobody questioned — always separate real vs. assumed.
- Presenting only the final idea. Showing the reasoning path (what was inverted, what was borrowed) makes the solution teachable and verifiable, not just a lucky guess.