Using TRIZ 40 Principles for Engineering Problem-Solving
The TRIZ 40 Principles are a set of generic solution strategies derived from analyzing millions of patents. At the University of Southampton, the approach to teaching and applying these principles tends to be more engineering-focused than the commercial training providers you'll find online. That distinction matters because most people coming to this method want to solve actual technical contradictions, not fill out worksheets. The core idea is straightforward. When you hit a technical contradiction — improving one parameter causes another to worsen — the 40 Principles give you a structured way to escape the tradeoff. The Southamption approach emphasizes building a contradiction matrix first, which maps your problem parameters against the principle recommendations. It is not a creative brainstorming session. It is a lookup procedure that forces you to frame the problem precisely before you start looking for answers. Here is how I actually use this in practice. Take the principle of segmentation, for example. You would never just pick it at random. You identify that you are trying to increase maneuverability in a mechanical system, and that increase is causing structural integrity to drop. Look up those two parameters in the matrix. Principle 1 (segmentation) appears as a recommendation. Then you apply it deliberately: divide the structure into independent sections, make parts detachable, increase degree of fragmentation. The principle does not hand you a solution. It hands you a direction.
One thing beginners consistently mess up is the parameter selection. The standard TRIZ contradiction matrix uses 39 engineering parameters. If you describe your problem in layman's terms instead of mapping it to one of those 39, the whole matrix lookup fails. I have watched people waste two hours on principles that were irrelevant simply because they called a strength problem a "durability issue" rather than selecting Parameter 14 (strength of stationary object) or Parameter 21 (power). Get the parameters right and the rest moves fast. Get them wrong and you are just reading a list of random ideas. There is a specific edge case that trips people up repeatedly. When both the improving and worsening parameters point to the same cell in the matrix, some of the recommended principles directly contradict each other. I encountered this on a thermal management project where improving heat dissipation (Parameter 3) was worsening weight (Parameter 2). The matrix threw back Principles 1, 28, 35, and 40 in the same cell. Principle 1 says segment. Principle 28 says mechanics substitution. They pull in opposite directions. What I ended up doing was taking the two most plausible candidates, applying them as separate design iterations, and measuring which direction actually moved the needle. That took about an afternoon of prototyping, but it was faster than cycling through all four principles sequentially. Another counter-intuitive point: Principle 35 (parameter changes) and Principle 26 (copying) are often dismissed as obvious or too simple to be useful. They are not. On a recent project involving sensor placement in a constrained housing, Principle 26 saved us from redesigning an entire signal conditioning circuit. We replaced a physical pressure sensor with an optical reflection-based copy system. The cost dropped and the reliability improved. The principle felt too simple to be the right answer until it was.
The main bottleneck with this method is time. A full contradiction analysis with proper parameter mapping, matrix lookup, and principle evaluation typically takes 45 minutes to 90 minutes for a single problem. If you are early in a design cycle and have five or six major contradictions to resolve, you are looking at a half day minimum. Some teams skip the matrix and go straight from problem statement to principle selection, which cuts the time down to roughly 15 minutes but increases the chance of missing the actual solution space. There is no way around that tradeoff. The methodology also breaks down in domains where the 39-parameter framework does not map cleanly. Software architecture problems, business process issues, and organizational conflicts often have no equivalent engineering parameter. I have tried forcing these into the TRIZ framework and the results were thin. For purely software problems, I usually pair TRIZ with other methods like root cause analysis or system dynamics modeling rather than relying on it alone. If you want to follow the Southampton approach specifically, the relevant materials are available through the University of Southampton's engineering department publications and their engineering design group resources. Look for course materials from their mechanical or aerospace engineering departments that cover inventive problem solving. The university does not publish a single definitive TRIZ handbook, so you will need to piece together lecture notes, research papers, and the standard TRIZ reference texts. The underlying principle framework is identical regardless of which institution teaches it. The difference is in the examples and the emphasis on engineering applications over general creativity techniques.
Get the Full Details
The free resources online are adequate for learning the basic matrix lookup procedure. Paid courses tend to add case studies and facilitation guidance, but the core 40 Principles and the contradiction matrix are well documented in open literature. You do not need a certification to apply these. You need to practice framing technical contradictions correctly, which is the part that takes real experience to develop.
