Dean Peters TRIZ PRISM
What Is It
Use known solutions to find new solutions to difficult problems.
Why Use It
Uncover novel solutions to existing problems. Cross-pollinate ideas from diverse domains. Enhance understanding of the problem by using analogies and metaphors. Bring diverse perspectives to bear.
When to Use It
When confronting a unique, surprising, confusing, or rare problem that does not provide a clear path to the solution. When standard solutions to the problem are not effective or well established.
How to Do It
- Define the problem in specific terms. Frame it as precisely and uniquely as possible. Use the word specific as often as possible in the problem statement, to designate various dimensions of the problem that are unique to your situation. For example, the problem might be: “This specific satellite image file is too large to send to a specific special operations soldier in a specific location in a specific country using the specific IT link with a specific amount of bandwidth available in support of a specific mission.”
- Restate the problem in general terms. Piece by piece, replace specific references with general descriptions. For our example, we might start by saying “This generic thing is too large to send to a specific special operations soldier in a specific location in a specific country using the specific IT link with a specific amount of bandwidth available in support of a specific mission.” We could further generalize the problem by saying “This generic thing is too large to send to anyone over the specific IT link…” Continue replacing specific references with generalized alternatives, iterating the problem statement until it no longer has any specific references. You may end up with a problem statement that sounds something like “We have a mismatch between file size and bandwidth,” or even “This thing is too big to fit through that small aperture.”
- Identify general solutions to the general problem. We have transformed the question from “How do I solve this specific challenge?” to “How does anyone solve this category of problem or this type of challenge?” The transformed question is usually much easier to answer. When we temporarily introduce a little intellectual distance from the problem, solutions often become more visible. In our example, we may now ask “How does anyone fit a large object through a small aperture?” or even “How does anyone send anything to anyone?” You can pass large objects through small spaces in several ways: Break the large object into smaller pieces Make the small hole larger Find a new access point In the process of breaking a large object into small pieces, we may discover that some pieces are more important than others or are needed sooner, or not at all.
- Reintroduce specific details from our situation, restating the general solution as a specific solution. In our example, we might note that big things can often be cut into smaller pieces, then reassembled on the other side. The specific solution might then involve creating a mechanism for the specific special operations soldier to request a specific image chip to be delivered through their specific IT link in support of their specific mission timeline, rather than requesting the entire image in the first place.
Key Concepts
Abstraction Ladder — The deliberate movement from a hyper-specific problem to a generalized one and back again. Climbing up reveals analogous solved problems; climbing down translates generic answers into your concrete context.
Specific-to-General Transformation — Systematically replacing each unique detail in a problem statement with a generic descriptor until you reach a universal pattern like 'mismatch between size and capacity.' This is the hardest and most valuable step.
Solution Analogy — Identifying how any field solves your generalized problem type, then importing that mechanism. Borrowing 'break large objects into pieces' from logistics or biology cross-pollinates ideas your domain wouldn't surface alone.
Intellectual Distance — The cognitive detachment gained by abstracting away from your specific problem. Distance reduces fixation and emotional attachment to a single solution, making alternatives visible.
Problem Reframing — Restating the challenge from 'how do I solve this?' to 'how does anyone solve this category?' This shift typically makes the question dramatically easier to answer and exposes hidden assumptions in the original framing.
PM Applications
- Unblock a technical constraint documented in a PRD by generalizing the limitation, then sourcing patterns from adjacent industries before committing engineering effort.
- Run a structured ideation session during a discovery sprint when JTBD interviews surface a problem with no obvious solution in your competitive set.
- Reframe a contentious roadmap debate where stakeholders are anchored to one feature approach, using abstraction to reveal alternative paths to the same outcome.
- Generate options for an OKR key result that has stalled, translating the blocked metric into a general problem class and borrowing proven mechanisms.
- Facilitate a cross-team workshop to solve an integration or scaling problem by mapping it to how unrelated domains handle the same generic constraint.
- Prepare an executive briefing that presents a novel solution by walking leadership through the analogy chain that justifies an unconventional approach.
Benefits
- Helps get teams unstuck and uncover creative options for solving hard problems.
Common Pitfalls
- Failing to generalize fully in step 2 — leaving specific references embedded keeps the team anchored to familiar solutions and produces no new options.
- Over-generalizing to the point of triviality, like 'we need to move data,' so the abstract problem loses the texture needed to find a useful analogy.
- Skipping the reintroduction of specifics in step 4, leaving the team with a clever metaphor but no actionable, testable product solution.
- Treating the generated analogy as the final answer instead of a hypothesis, then shipping it without prototyping or validating against real user constraints.
- Running this on a well-understood problem with established patterns, wasting 60+ minutes when a known best practice or competitor benchmark would suffice.
- Letting the loudest voice drive the generalization, defeating the purpose of bringing diverse perspectives to cross-pollinate solutions from multiple domains.
Combine With
Problem Framing first to define the problem Prototyping after to test out your proposed solution
Assets
- PDF: Download
- Markdown Template: template.md
Metadata
| Field | Value |
|---|---|
| ITK Phase | GENERATE |
| Difficulty | Beginner |
| Group Size | 4+ people |
| Time Required | 60+ minutes |
| Source | itk.mitre.org |