Learn cheaply before you build expensively
Test assumptions early to move faster with greater confidence later.
A pattern I've seen in innovation and transformation work is that many organizations rush through early decisions about what problem to solve or what to build, even when those choices are still relatively easy and inexpensive to change.
Later, once those choices have hardened into roadmaps, project plans, and build commitments, changing direction can become much more expensive and painful.
That is why I like a simple principle: Learn cheaply before you build expensively.
The cheapest time to be wrong
Most innovation and transformation initiatives begin with more assumptions than facts:
We believe we understand the problem. We believe customers will value the solution. We believe employees will use it. We believe a new workflow will make work easier, the economics will make sense, or the technology will perform as expected.
Some of those assumptions will prove correct, and others won't.
The question is: how early will we find out which assumptions are wrong?
It is inexpensive to discover that an idea is off track while it still exists as a concept, sketch, or rough prototype. It becomes much more expensive after months of development, integration, process redesign, hiring, training, change management, and executive sponsorship.
Yet organizations often move quickly through these early learning stages because tangible execution feels like progress. Project plans get built, resources get assigned, and development begins.
But activity by itself does not tell us whether we're headed in the right direction.
You don't always need to build something to learn something
One of the most useful lessons I've taken from years of innovation work is how much a team can learn before building a finished solution.
Customer or employee conversations can challenge the team's understanding of the problem. A simple concept sketch can make an abstract idea tangible enough for people to react to it, or surface assumptions they didn't realize they were making. A prototype can help determine whether a potential experience is moving in the right direction long before production code is involved.
Importantly, prototypes do not need to look impressive to be valuable. In fact, early prototypes can sometimes be too polished.
I've been part of innovation efforts where some of the most useful feedback came from black-and-white sketches and very rough representations of a potential experience. Because they were obviously unfinished, people understood that nothing had been decided yet. They were more willing to question the idea, suggest alternatives, and help reshape it.
The same dynamic can apply in conversations with executives. Teams naturally want to walk into a leadership review with something polished and presentation-ready. But polish can unintentionally signal that the important decisions have already been made.
A rough concept can invite a different conversation. Instead of simply evaluating the answer, leaders can engage with the thinking behind it and help teams make strategic connections.
Prototypes are decision tools
Prototyping is often treated primarily as a product design activity. I think that definition is too narrow.
At its best, a prototype is also a decision-making tool. It gives a team something tangible around which to ask better questions: Are we solving the problem we thought we were solving? Does this actually make someone's experience better? Which assumptions are proving true? What are we learning that we didn't expect?
And ultimately: should we keep going, change direction, or stop?
That last question is especially important.
Once an initiative receives funding and organizational attention, stopping it can begin to feel like failure. Teams can become invested in proving through sheer will that the original idea was right.
But early innovation work should not be designed to prove an idea is right. It should help us determine whether the idea is right, and what would need to change if it isn't.
If inexpensive research or prototyping shows that an idea is unlikely to create enough value, stopping or redirecting the work can be a very good outcome. It means the organization learned something important before putting significantly more money, time, and attention behind the wrong thing.
Going slower at the beginning can help you move faster later
This is why I've always liked the idea of "go slow to go fast." Not because organizations should become more cautious or bureaucratic, but because a small amount of disciplined learning early can create much greater confidence later.
Once you have stronger evidence that you're addressing an important problem, that people value the direction, that the economics have potential, and that the idea can realistically be delivered, the organization can move forward with greater conviction.
Teams spend less time undoing earlier decisions. They reduce expensive rework. Executives have a clearer basis for investment decisions. And the people doing the work can focus more of their energy on execution instead of repeatedly questioning whether the underlying direction makes sense.
AI and other technologies are making it possible to design, build, and launch new things faster than ever.
That is a tremendous advantage, but it also makes disciplined early learning more important, not less. The easier it becomes to build something, the more important it is to make sure the thing being built is worth the investment.
Over the long run, the organizations that move fastest may not be the ones that start building first. They may be the ones that become exceptionally good at learning before they commit.
Contact
503-489-9886
© 2026 Create Advantedge. All Rights Reserved.
Important info
Info@CreateAdvantedge.com