Creative Problem Solver

TRIZ was developed by Genrich Altshuller after analyzing over
200,000 patents. His discovery: inventive solutions follow
patterns, and these patterns can be learned and applied.

CORE INSIGHT:
  Most problems have already been solved in another domain.
  TRIZ provides systematic methods to find and apply those
  solutions to your problem.

THE THREE LEVELS OF TRIZ APPLICATION:
  Level 1: 40 Inventive Principles (most accessible)
  Level 2: Contradiction Matrix (structured application)
  Level 3: ARIZ Algorithm (advanced, systematic)

PRINCIPLE 1: SEGMENTATION
  Divide an object or system into independent parts.
  Example: Modular furniture, microservices architecture,
  sectioned pill organizers.
  Apply when: A monolithic solution is too rigid.

PRINCIPLE 2: TAKING OUT / EXTRACTION
  Remove the problematic part or the only necessary part.
  Example: Remote work (extract the employee from the office).
  Apply when: Something is beneficial but its location isn't.

PRINCIPLE 5: MERGING / CONSOLIDATION
  Combine identical or related objects or operations.
  Example: Swiss Army knife, all-in-one printer, unified platforms.
  Apply when: Multiple separate tools could be one.

PRINCIPLE 10: PRELIMINARY ACTION
  Perform the action in advance (fully or partially).
  Example: Pre-cut vegetables, pre-configured templates, pre-built
  development environments.
  Apply when: Preparation time is the bottleneck.

PRINCIPLE 13: INVERSION / THE OTHER WAY ROUND
  Do the opposite of what's conventionally done.
  Example: Instead of the customer going to the store, the store
  goes to the customer (delivery). Instead of pushing content,
  let users pull it.
  Apply when: The conventional approach has fundamental limitations.

PRINCIPLE 15: DYNAMIZATION
  Make a rigid system flexible or adaptable.
  Example: Adjustable-height desks, dynamic pricing, adaptive learning.
  Apply when: One-size-fits-all doesn't fit all.

PRINCIPLE 25: SELF-SERVICE
  Make the object or system serve itself or maintain itself.
  Example: Self-cleaning ovens, self-checkout, wikis.
  Apply when: Maintenance or operation is a bottleneck.

PRINCIPLE 35: PARAMETER CHANGE
  Change the physical state, concentration, flexibility, temperature,
  or other parameters of an object.
  Example: Freeze-dried food (change state for preservation).
  Apply when: Changing a fundamental parameter might bypass a limitation.

TRIZ identifies two types of contradictions:

TECHNICAL CONTRADICTION:
  Improving one parameter worsens another.
  "Making the product stronger makes it heavier."
  "Making the software more feature-rich makes it slower."

PHYSICAL CONTRADICTION:
  A parameter must be in two opposite states simultaneously.
  "The packaging must be strong (for shipping) AND weak (for opening)."
  "The meeting must be long (for thorough discussion) AND short
   (to respect everyone's time)."

RESOLVING PHYSICAL CONTRADICTIONS:

  Separation in TIME:
    The product is strong during shipping, weak at opening
    (perforated packaging, pull tabs)

  Separation in SPACE:
    Strong on the outside, weak along the opening line
    (reinforced exterior, scored opening)

  Separation by CONDITION:
    Strong at one temperature, weak at another
    (heat-activated adhesive release)

  Separation by SCALE:
    Strong at macro level, flexible at micro level
    (chain mail: rigid overall, flexible link by link)

RANDOM ENTRY:
  Pick a random word from a dictionary. Force connections between
  that word and your problem.

  Problem: "How to reduce customer churn"
  Random word: "Lighthouse"
  Connections: Warning system (early churn signals), guiding beacon
  (onboarding), standing firm in storms (crisis support), visible
  from far away (brand visibility), rotating light (regular check-ins)

  Often produces: At least 1-2 genuinely novel ideas from forced
  connections that wouldn't arise from conventional thinking.

PROVOCATION (Po):
  Make a deliberately absurd statement, then extract useful ideas.

  "Po: We should PAY customers to leave."
  Extraction: What if we offered a "leaving bonus" to unhappy
  customers, guaranteeing that only genuinely satisfied customers
  stay? (Zappos actually offers new hires money to quit.)

  "Po: The product should have NO features."
  Extraction: What if we stripped to the absolute minimum? What is
  the one feature that matters most?

CHALLENGE:
  Question why something is done the current way.
  "Why do meetings have to be synchronous?"
  "Why does a resume have to be a document?"
  "Why does education take 4 years?"
  "Why do restaurants have menus?"

  The answer "because that's how it's always been done" is the
  starting point for innovation, not the end of the conversation.

STAGE 1: EMPATHIZE
  Deeply understand the people you're designing for.

  METHODS:
  - Contextual observation (watch people in their natural environment)
  - Empathy interviews (open-ended: "Tell me about the last time...")
  - Journey mapping (map the entire experience step by step)
  - "Day in the life" shadowing
  - Extreme user research (people who use the most/least)

  KEY: Set aside your assumptions. You are not the user.

STAGE 2: DEFINE
  Synthesize observations into a clear problem statement.

  FORMAT: Point of View (POV) statement
  "[User] needs [need] because [insight]"

  Example: "Busy parents need a way to prepare nutritious meals in
  under 15 minutes because they value health but have no time after
  work and before activities."

  GOOD PROBLEM STATEMENTS:
  - Focus on the user's need, not a specific solution
  - Are specific enough to be actionable
  - Are broad enough to allow creative solutions

STAGE 3: IDEATE
  Generate a wide range of possible solutions.

  RULES:
  - Defer judgment (no evaluation during ideation)
  - Encourage wild ideas (they spark practical ones)
  - Build on others' ideas ("Yes, and..." not "Yes, but...")
  - Go for quantity (100 ideas in 30 minutes is achievable)
  - Be visual (sketch, don't just write)
  - One conversation at a time
  - Stay focused on the problem statement

STAGE 4: PROTOTYPE
  Build quick, cheap representations of solutions to learn from.

  PROTOTYPE PRINCIPLES:
  - Speed over quality (hours, not weeks)
  - Low fidelity is fine (paper, cardboard, sketches, role-play)
  - Build to think, not to prove
  - Multiple prototypes test multiple ideas simultaneously
  - Build with a question in mind: "What are we testing?"

  PROTOTYPE TYPES:
  - Paper prototypes (UI/UX)
  - Storyboards (service/experience)
  - Role-play (interactions/services)
  - Physical mockups (products)
  - Wizard of Oz (fake the backend, test the frontend)

STAGE 5: TEST
  Get feedback on prototypes from real users.

  TEST PRINCIPLES:
  - Test with real users, not colleagues
  - Observe behavior, don't just ask opinions
  - Ask "why" when you see something unexpected
  - Separate the idea from your ego
  - Be prepared to go back to any previous stage
  - What surprised you? That's where the learning is

  KEY QUESTIONS:
  "What worked?"
  "What didn't?"
  "What questions does this raise?"
  "What would you change?"

A checklist for systematic idea generation:

S - SUBSTITUTE: What can be substituted?
    Substitute materials, people, processes, places, approaches
    "What if we used AI instead of humans for this step?"
    "What if we used video instead of text?"

C - COMBINE: What can be combined?
    Merge functions, features, products, ideas
    "What if we combined onboarding with the first purchase?"
    "What if the packaging WAS the product?"

A - ADAPT: What can be adapted from elsewhere?
    Borrow from other industries, nature, history
    "How does nature solve this?" (biomimicry)
    "What does the hospitality industry do that we could borrow?"

M - MODIFY / MAGNIFY / MINIMIZE: What can be changed?
    Make it bigger, smaller, faster, slower, more frequent
    "What if it was 10x larger? 10x smaller?"
    "What if it happened daily instead of annually?"

P - PUT TO OTHER USES: What else could this be used for?
    Repurpose existing solutions for new problems
    "What else could our customer data be useful for?"
    "What if this tool was used by a completely different audience?"

E - ELIMINATE: What can be removed?
    Strip away features, steps, components, rules
    "What if we removed the sign-up process entirely?"
    "What is the minimum viable version?"

R - REARRANGE / REVERSE: What if the order changed?
    Reverse sequences, flip perspectives, reorganize
    "What if the customer paid BEFORE seeing the product?"
    "What if the last step came first?"

Instead of "How do we solve this?", ask "How do we make this WORSE?"

PROCESS:
  1. State the problem clearly
  2. Reverse it: "How could we cause this problem?"
     or "How could we make this as bad as possible?"
  3. Generate ideas enthusiastically (this is fun and freeing)
  4. Reverse each "bad" idea into a good solution

EXAMPLE:
  Problem: "How do we reduce customer churn?"

  Reversed: "How do we MAXIMIZE customer churn?"
  - Make the product confusing and hard to use
  - Never respond to support tickets
  - Change pricing randomly without notice
  - Hide the cancel button (so they feel trapped and resentful)
  - Never onboard new users
  - Remove features people rely on without warning

  Reversed back to solutions:
  - Simplify the UI ruthlessly
  - Guarantee support response within 2 hours
  - Transparent, predictable pricing with advance notice of changes
  - Make cancellation easy (reduces resentment, increases willingness to return)
  - Build a structured onboarding program
  - Communicate before removing any feature and provide alternatives

  WHY IT WORKS: It's psychologically easier to think of ways to
  fail than to succeed. The reversal often reveals non-obvious solutions.

PROCESS:
  1. Deliberately generate the worst, most ridiculous solutions
  2. For each terrible idea, ask: "What makes this terrible?"
  3. Invert those qualities into design principles
  4. Generate ideas that embody those principles

EXAMPLE:
  Challenge: Design a better commute experience

  Worst ideas:
  - Make everyone walk backwards to work
  - Commute should take 8 hours
  - Everyone commutes at 3 AM
  - The commute should be blindfolded

  What makes them terrible -> Inverted principle:
  - Backwards/inefficient -> Optimize the direction/route dynamically
  - 8 hours -> Minimize time; make any time used productive
  - 3 AM -> Optimize timing for the individual, not the system
  - Blindfolded -> Make the journey visually engaging or productive

COUNTERINTUITIVE PRINCIPLE:
  Constraints enhance creativity rather than limiting it.
  "Write a story" is paralyzing.
  "Write a story in exactly 6 words" produces masterpieces.

USEFUL CONSTRAINTS TO IMPOSE:

TIME BOX:
  "We have 10 minutes to generate 20 ideas."
  Urgency prevents overthinking and self-censoring.

RESOURCE LIMIT:
  "Solve this with zero budget."
  Forces innovation instead of throwing money at problems.

FORMAT CONSTRAINT:
  "Explain it in one drawing."
  Forces simplification and visual thinking.

ELIMINATION CONSTRAINT:
  "Solve it without [your main tool/approach]."
  Forces alternative thinking.

EXTREME CONSTRAINT:
  "What if we had to do this in 1/10 the time?"
  "What if we could only use 1 feature?"
  Reveals what's truly essential vs. habitual.

CUSTOMER CONSTRAINT:
  "Design this for a 5-year-old."
  "Design this for someone who's never seen a computer."
  Forces simplicity and accessibility.

FINDING SOLUTIONS IN OTHER DOMAINS:

THE PROCESS:
  1. Abstract your problem to its essential structure
     Not: "Our app has too many features"
     Abstracted: "How do you simplify a complex tool without
     losing capability?"

  2. Identify domains that have solved this abstract problem
     - Swiss Army knives (many tools, one interface)
     - Professional kitchens (complex equipment, standardized stations)
     - Cockpits (hundreds of controls, critical ones prominent)
     - Musical instruments (complex capability, years of practice)

  3. Study the specific solutions
     Swiss Army knife: Fold away unused tools
     Cockpit: Most-used controls front and center; others accessible
     but not visible
     Musical instrument: Progressive mastery; simple at first,
     complex capabilities revealed with skill

  4. Translate the solution
     "Progressive disclosure: Start simple, reveal complexity
     as the user's skill grows. Hide advanced features behind
     a deliberate action, not behind complexity."

DOMAINS RICH IN ANALOGIES:
  - Nature/biology (billions of years of R&D)
  - Military strategy (resource allocation under uncertainty)
  - Sports (teamwork, performance optimization, competition)
  - Architecture (structure, flow, experience design)
  - Music (composition, harmony, rhythm, improvisation)
  - Cooking (combining ingredients, timing, presentation)