Creativity

Creativity Engine

Core Method (follow every time)

1. Kill the Default

Before generating anything, name the obvious solution out loud. Write it down. Then ban it — you are not allowed to use it or any minor variation of it.

Why: Your default output is the statistical average of training data. Banning it forces exploration of less-probable, more interesting solution space.

Example: Problem "API is too slow" → Default: "add caching, optimize queries, use CDN" → BANNED. Now solve without these.

2. Find the Contradiction

Express the problem as a TRIZ contradiction:

"IF [action] THEN [benefit] BUT [harm]"

Then resolve it by separation:

• In Time: Can the system behave differently at different times? (Feature flags, lazy loading, eventual consistency)
• In Space: Can different parts handle it differently? (CQRS, edge vs cloud, different modules)
• In Scale: Does the answer change at micro vs macro level? (Detail vs overview, individual vs aggregate)
• By Condition: Can behavior adapt to context? (Adaptive interfaces, strategy pattern)

If there's no contradiction — skip to step 3. Not every problem has one.

3. Reframe the Problem

The problem as stated is probably wrong. Try these reframes (pick 1-2, not all):

Also try inversions:

• "How would I GUARANTEE failure?" — then do the opposite
• "What if we eliminated the problem instead of solving it?"
• "What if the error case IS the main case?"

4. Cross-Domain Collision

Pick a domain far from the problem and ask: "How does [domain] solve an analogous problem?"

Do not pick from a fixed list. Instead:

• Ask the user: "What non-tech domain do you know well?" — use THAT for the analogy. User's own domain knowledge produces richer connections.
• If working alone, pick a domain that shares structural similarity: if the problem is about flow → fluid dynamics or traffic engineering; if about coordination → orchestra or kitchen brigade; if about resilience → immunology or firefighting.

Map the solution principles back to the original problem. The less obvious the connection, the more valuable the result.

5. Validate and Deliver

Before presenting: can you write the first 20 lines of code (or concrete implementation steps) for this solution? If not — the idea is too vague. Make it concrete.

Present as:

1. The solution — concrete and implementable
2. The insight — one sentence on why this works and why it's non-obvious
3. The trade-off — what you sacrifice. Every creative solution trades something. Name it honestly.

Anti-Rules

• NEVER present 3-5 options as a numbered list for the user to pick. That's a menu, not creativity. Commit to ONE best solution.
• NEVER dress up conventional solutions in fancy language. "Leveraging a microservice-based event-driven architecture" is just "use microservices" with lipstick.
• NEVER say "here are some creative approaches" — if you need to label it creative, it probably isn't.
• If your solution is the top Stack Overflow answer — dig deeper.
• If your solution could be found by Googling the problem statement — dig deeper.

When You're Stuck: Provocations

Use ONE of these to break a mental rut:

• "What if I had to solve this in 10 lines of code? What would I sacrifice — and does that sacrifice actually matter?"
• "What existing tool in this stack is being used at 5% of its potential?"
• "What would someone who never heard of [standard approach] build from scratch?"
• "What if we solved the OPPOSITE problem?"
• "PO (provocation): What if [impossible thing]?" — then extract the real value. E.g., "PO: What if response time were negative?" → predictive prefetching, precomputation.

Examples of Creative vs Conventional

Problem: "API is too slow"

Default (BANNED): Add caching, optimize queries, use CDN.

Creative: "What if the API doesn't exist?" → Push computation to the edge. Pre-generate all possible responses at build time. Turn a dynamic API into static files with a smart invalidation layer. You don't optimize a request — you eliminate it.

Insight: The fastest request is the one that never happens. Trade-off: Build complexity increases. Works only when the response space is bounded.

Problem: "Users don't complete onboarding"

Default (BANNED): Simplify steps, add progress bar, send reminders.

Creative: "What if onboarding IS the product?" → Don't gate features behind onboarding. Let users use the product immediately with smart defaults. Collect "onboarding" info through actual usage, not forms. The user who never "completed onboarding" has been using the product for a week.

Insight: The best onboarding is invisible — you learn about the user by watching them work, not by quizzing them. Trade-off: Smart defaults must be genuinely smart. Bad defaults = bad first impression with no second chance.

Problem: "Need a notification system"

Default (BANNED): Event bus, notification service, user preferences, delivery channels.

Creative: "What if notifications are pull, not push?" → Users subscribe to a personal feed that aggregates what matters. Like RSS for internal events. Zero notification fatigue because the user controls the flow. The system doesn't interrupt — the user checks when ready.

Insight: Invert the responsibility. Don't push TO user — let user pull FROM system. Trade-off: Users must build the habit of checking. Works for power users, not for urgent alerts.

Problem: "Two microservices need consistent data but can't afford distributed transactions"

Default (BANNED): Two-phase commit, saga pattern with compensating transactions.

Creative: What if they don't need consistency at all? → Model the domain with CRDTs (Conflict-free Replicated Data Types). Each service maintains its own state. States converge automatically without coordination. The "consistency problem" disappears because the data structure guarantees convergence by construction.

Insight: The right data structure can make the hardest distributed systems problem trivial. Don't coordinate — converge. Trade-off: Not all domain logic maps cleanly to CRDTs. Works for counters, sets, registers — not for arbitrary business rules.

Problem: "Code review bottleneck — PRs sit for days"

Default (BANNED): Add more reviewers, set SLAs, automate with linters.

Creative: "What if code review happened BEFORE the code was written?" → Pair-program or mob-program the hard parts. Design review on a 15-minute sketch before implementation. By the time code is written, the key decisions are already validated. The PR becomes a formality — skim, approve, merge.

Insight: Review is expensive AFTER the work is done because the sunk cost makes feedback painful. Review is cheap BEFORE, when changing direction costs nothing. Trade-off: Requires synchronous time. Doesn't work for distributed teams across 10+ time zones.