Do you make to break?
Have you ever had a ‘proof of concept’ that proved that the concept wouldn’t work?
I have seen it a couple of times on projects. One time, it didn’t just show that the idea needed some tweaks, but that the idea was fundamentally flawed.
Most prototypes or proof-of-concept are intended to build confidence in the design and reduce uncertainty. This often leads to a green light mentality, where the outcome is a foregone conclusion intended to trigger full-scale production
But how often do you genuinely run a test to find the points of failure? How often do you stress the idea until something gives way?
The Default Setting
Most projects run tests to prove that they are on the right track. A pilot is frequently designed to show that a concept is sound and to reduce the cognitive dissonance of a decision that has already been made.
Projects need momentum, and we all love good news. We want to believe our effort isn’t wasted.
However, when we run tests to prove we are right, rather than to understand where we are wrong, we miss the opportunity to learn.
“One of the great challenges in this world is knowing enough about a subject to think you're right, but not enough about the subject to know you're wrong.”
― Neil deGrasse Tyson
Before an airline introduced a new customer boarding process, they invited staff to try and break it. Not in a mean way, but to showcase some of the ‘less compliant’ behaviours they dealt with daily. The instruction was simple: show us how this won’t work.
Edward deBono calls this a ‘black hat’ session – a dedicated space to find fault
If we don’t find problems in testing, if we ignore the noisy voice, they don't disappear; they lie in wait. They break the operation after go-live, when the cost to fix them is exponentially higher.
In other words, if we’re only building tests with the intended outcome to pass, it means we chose the conditions most favourable to the idea, and not conditions focused on learning.
What 'Make to Break' Actually Means
The most valuable thing you can learn about an idea is not whether it works, but where it stops working.
Every design has a breaking point. Every strategy has an assumption that, if wrong, collapses the whole argument. Every operating model has a condition under which it fails.
Testing to break something is fundamentally different from testing to validate it.
The questions, the conditions, and the team’s attitude must all shift. You are no longer looking for a smooth run. You are looking for a failure to educate you.
Discomfort Is The Point
This type of testing is uncomfortable. It requires honesty and willingness to invest in an activity where the outcome might be the discovery that you were wrong.
In many project environments, this is a hard sell. Progress is typically measured in approvals and milestones, not the quality of insights gained.
A team that identifies three conditions under which a project fails has done something genuinely valuable. They have narrowed the solution space and protected the organisation from future disaster.
Yet, in the short term, they have complicated things. They have slowed down the timeline and introduced doubt into a room that craves certainty. Most project cultures resist this because the drive toward the next milestone is irresistible.
What Are You Solving For?
Before your next test, pilot, or proof of concept, be clear about your intent:
Are you testing to confirm or testing to learn?
Are you designing conditions for success, or conditions that reveal limits?
To ensure a test actually educates you, you need:
A genuine focus on learning over validation
A willingness to listen to those who make the most noise
The humility to admit you didn’t get it right and make changes
Maybe the most dangerous proof of concept is the one that proves exactly what you hoped it would.
