Problem-solving with TRIZ

It was a couple of months ago, so I can't remember who told me about TRIZ:

TRIZ (/trɪz/; Russian: теория решения изобретательских задач, romanized: teoriya resheniya izobretatelskikh zadach, lit. 'theory of inventive problem solving') is a methodology which combines an organized, systematic method of problem-solving with analysis and forecasting techniques derived from the study of patterns of invention in global patent literature. The development and improvement of products and technologies in accordance with TRIZ are guided by the laws of technical systems evolution. In English, TRIZ is typically rendered as the theory of inventive problem solving.

Whoever it was, they said that they'd boiled down the 40 principles to a smaller number. The conversation moved on, so I went back with my Little Robot Friend (LRF) to have a go (also available as a two-page PDF):

What TRIZ actually is, underneath the 40

Strip the mechanism and TRIZ collapses into three claims:

Every hard technical problem hides a contradiction. Improving one thing worsens another, and that conflict is the problem. Contradictions dissolve when you separate the requirements: in space, in time, between scales, or between conditions. The two things no longer have to happen in the same place at the same moment.

The ideal state is the function delivered with no system at all. Every design move toward that ideal counts as progress.

The 40 inventive principles are a tactical library for executing (2). They compress cleanly into seven families.

The 40 principles in 7

1. Separate and segment (1, 2, 3, 17, 24). Break the object, function, or dimension into parts so conflicting requirements live in different parts.
2. Combine and unify (5, 6, 7). Merge objects, functions, or nested structures so one thing does several jobs.
3. Asymmetry and local quality (4, 33 inverted). Match each part to its local job instead of making everything uniform.
4. Shift in time (9, 10, 11, 20, 21, 26). Pre-act, post-act, act continuously, or compress into a brief moment. Decide when, not just what.
5. Invert and turn harm into use (8, 13, 22, 34). Do the opposite, counterbalance, or convert the waste of the problem into the resource that solves it.
6. Change the substrate (28, 29, 30, 31, 32, 35, 36, 37, 38, 39, 40). Swap the material, phase, or field carrying the function. Mechanical becomes pneumatic, solid becomes porous, rigid becomes film.
7. Let the system do the work (15, 16, 18, 19, 23, 25, 27). Add dynamism, feedback, periodicity, self-service, or accept partial/cheap/disposable parts so the system regulates itself.

What survives the boil

Cut further and TRIZ is really two ideas: find the contradiction, then resolve it by separation. Everything else is vocabulary for the second step. The rare skill is spotting contradictions at all, since most people quietly flatten them into trade-offs and stop.

What does that mean in terms of my work? Again, I asked my LRF:

TRIZ was built for engineering but the core move travels well to what you actually do. The most portable idea is that contradictions are the site of the work, not the thing to trade off. Almost every strategic conversation in mission-driven organisations runs aground on a supposed trade-off that is a contradiction in disguise. A few specific applications to your terrain.

TechFreedom as TRIZ in practice. The five-dimension framework is already diagnosing contradictions. A client wants the convenience of hosted Google Workspace and wants jurisdictional sovereignty. They want low cost now and no lock-in cost later. You ask them to name these tensions, which is valuable, but the framework stops there. The TRIZ separation principles offer a disciplined next step: the answer is rarely "pick one" and almost always "separate them." Separate in space by segmenting workloads by sensitivity. Separate in time by migrating critical workloads first. Separate in condition by using different tools for different risk categories. Separate in scale by pooling infrastructure at the sector level via cooperatives. You could make this an explicit second layer of the TechFreedom methodology, so the output is not just a risk heatmap but a short menu of separation moves for each high-risk dimension. Very few sovereignty practitioners are offering a route from diagnosis to resolution, so the intellectual territory is also defensible.

In facilitation. The contradiction statement is the single best workshop tool TRIZ gives you. Force the group to write "in order to improve X we would harm Y" before any solutions are tabled. Most strategy workshops skip this step entirely and end up in uncommitted compromise. The Ideal Final Result is a better prompt than "what does success look like," because it strips out the assumption that the current system must exist: "what would it look like if the function happened with no system at all?" And Nine Windows (past, present, future crossed with sub-system, system, super-system) is a near-perfect Sightlines candidate. A small interactive widget that lets someone place their problem in the centre cell and then guides them through the surrounding eight would be a genuinely useful systems thinking tool.

In your own product work. Commonplace, Stream, and CalAnywhere all have a structural contradiction at their centre, and naming them explicitly at the top of each PRD would sharpen the designs. Commonplace wants protocol-neutrality and coherent UX. Stream wants velocity reading and comprehensive coverage. In each case the productive move is separation rather than compromise. Commonplace separates in scale: different protocols at the infrastructure layer, unified at the user layer. Stream separates in time: different reading modes for different contexts. Bridges separates in responsibility: technical complexity at instance level, simple experience at user level. The PRDs will hold together better when the contradiction is stated up front and the resolution is named as a specific separation.

For the think-and-do tank. The core tension, think versus do, is itself a classic separation-in-time problem. Research-heavy quarters alternating with implementation quarters. Slow-cycle publications alongside fast-cycle tool releases. Morning reflection, afternoon building. The methodology offering could be built around this structure explicitly, which would also give clients a transferable pattern.

A writing angle. "TRIZ for mission-driven organisations" would be a strong Open Thinkering series. The sector is full of flattened contradictions (scale vs values, mission vs sustainability, openness vs safety, free-at-the-point-of-use vs financial resilience) and almost nobody is using this vocabulary on them.

So there we go, much to think about. As my recent coaching suggested, I need to start thinking more systemically about my own practice.

---

Image CC BY-SA 4.0, Oxford Creativity