After reading through and organising lateral thinking, Six Thinking Hats, 635 Brainwriting, SCAMPER, Brainstorming, and design thinking, the biggest thing I got out of it was not a few more management or creativity tools. It was that I started to understand “thinking” itself as something that can be deliberately designed.
In the working environments I have been in, from the boss on down, the decision-making style I know best is direct and fast. When a problem shows up, a small number of decision makers quickly pick a direction. If something can be done, do it first, then use the actual results as feedback and keep correcting and iterating. The advantage of this approach is obvious: speed. In product, engineering, and software development environments especially, as long as the cost of a mistake is low, the decision is reversible, and market or user feedback comes back fast enough, acting directly beats spending a lot of time in discussion. Many questions only get answered by doing, and over-analysis can actually reduce efficiency.
That is also why my first question about Six Thinking Hats, 635 Brainwriting, and SCAMPER was whether they just make meetings more formal, or simply give participants more chances to speak. If in the end you still have to decide, execute, and let reality validate the result, why not just start doing it right away? Once I understood them better, I found that these methods are not dealing with the same class of problem at all.
The core of lateral thinking is deliberately leaving the existing line of thought. Instead of rushing to push the original logic further, you change the angle, recombine the conditions, reverse the assumption, or introduce a new stimulus, to open up possibilities that were not visible before. SCAMPER, reverse thinking, and what-if questions all share this character. Their value is not in analysing the existing answer in finer detail. It is in rewriting the problem and the space of possible solutions.
Six Thinking Hats is closer to a structured method for parallel thinking. It separates the thinking modes that normally get mixed together, so the team focuses on one cognitive task at a time. The White Hat handles facts and information, the Red Hat handles intuition and feelings, the Yellow Hat looks for value and the conditions under which something works, the Black Hat checks risks and problems, the Green Hat expands new possibilities, and the Blue Hat controls the thinking process itself. The point is not just to add perspectives. It is to stop different thinking modes from interfering with one another. When a new idea is shot down by risk analysis the moment it is raised, divergence usually ends too early.
635 Brainwriting solves yet another kind of problem. Through silent writing and passing ideas around for others to extend, it reduces the influence of dominant speakers, rank, and group pressure on the discussion. Everyone thinks independently first, then builds on and extends other people’s ideas. What it really improves is not “creativity” itself, but the mechanism by which a group produces ideas.
These methods made me start to think that rapid trial and error and thinking frameworks might not actually be in conflict.
Rapid trial and error is good at shortening “how long until we know the answer.” If a decision is cheap, easy to reverse, and feedback is fast, the most efficient approach is usually to just do it and learn from the result. But when the topic is a startup idea, a medium- to long-term strategy, a business model, a major investment, or the direction of an organisation, the problem itself may not even be clearly defined yet. Going into execution too early then carries a different risk: the team, with great efficiency, does a superb job on a problem that is unimportant or simply wrong.
So the more important value of these thinking methods is to help the team confirm, before acting, whether the problem is worth solving, whether other angles exist, and whether the current direction is merely the first answer that looked reasonable. This matters especially for startups. The problems of a mature product are usually closer to “how do we do this well.” In the early days of a startup, the question is more often “what should we do at all.” Who the customer is, what the real pain point is, who will pay, why existing solutions are not enough, and where the product should start: none of this is settled. Without proper problem exploration and lateral thinking first, a team easily falls in love with its first solution too early.
The value of these methods for teamwork is also not just a greater sense of participation. Different members hold different information and experience. Engineers know the technical constraints. Sales knows how customers really react. Operations knows which processes are simply unworkable on the ground. Finance understands cost and risk. If decisions stay concentrated in a few people over the long run, this local knowledge scattered across the front line tends to surface only after execution has already run into trouble. Six Thinking Hats, Brainwriting, and other structured discussion formats pull that dispersed information into the decision process earlier. Methods like the Black Hat have one more important effect: they make dissent legitimate. When everyone is asked to examine the risks together, raising a problem no longer amounts to “opposing the boss.” It is just part of completing the thinking process.
A good team does not have to end with everyone holding the same opinion. What is truly valuable is shared understanding, meaning everyone clearly knows what problem we are solving right now, what this decision is based on, what assumptions we are making, where the main risks are, how success is defined, and under what conditions we need to change direction. Even if some people still disagree at the end, as long as everyone shares an understanding of these key points, the team can execute effectively after the decision, rather than agreeing on the surface while each person actually understands the direction differently.
None of this means every problem should be run through a framework. If every small issue goes through Six Thinking Hats, SCAMPER, or a full Brainstorming process, the result is just another form of bureaucracy. What really matters is not “did we use a framework,” but whether we can judge which problems are worth the time to think through. For problems that are cheap, easy to reverse, and quick to give feedback, act directly. For decisions that are vague, expensive, hard to undo, or take a long time to show results, it is worth using a more complete thinking method first to widen the perspective, challenge assumptions, and confirm the direction.
So after this round of study, I do not see the direct thinking I am used to and the various thinking methods I have just encountered as two opposing options. I think a better way of working is to first use the right method to get the problem clear enough. When the existing frame needs breaking, use lateral thinking. When several people need to examine something from different angles, use Six Thinking Hats. When you need a large volume of ideas with less group interference, use 635 Brainwriting or another Brainstorming method. Once the key assumptions are confirmed, stop discussing and move quickly into experiment and execution. After real-world feedback comes back, return to the thinking stage, check whether the original assumptions held, and decide the next round’s direction.
The value of thinking methods, then, is not to replace fast action. It is to help us confirm, before we act, that we are solving the right problem. And the value of fast execution is to get those ideas in front of reality as soon as possible.
Comments & Feedback