A founder once came to me for advice and brought something unusual with him: a working machine that used robotics and computer vision to dispense medicine from bulk packages into personalized weekly dispensers. Technically, it was impressive. He had thought through difficult engineering problems, combined several technologies, and built something that actually worked rather than presenting me with another slide deck about what might someday be possible.
I remember being genuinely impressed by him. He was smart, technically capable, and obviously trained to deal with complicated problems. When I asked difficult questions, he could give equally sophisticated answers. He had also done his homework in the conventional sense. During the previous weeks and months, he had collected market reports, statistics, industry information, research, and other secondary sources that supported the opportunity he saw. His commercial route was still open, with possible B2B and B2C approaches involving pharmaceutical companies and healthcare providers, but he had clearly invested substantial time, money, and thought into the venture.
Then, almost as a side question, I asked him who he had actually spoken with.
The answer surprised me because, despite having a working machine in front of me, he had not yet spoken with the people in the real environment in which the machine would eventually have to succeed. He had not gone out to understand the situation with hospitals, physicians, or other people who knew the processes and constraints around medication handling from direct experience.
So I asked him what seemed to me like a much simpler question than most of the questions he had already answered.
“What prevents you from speaking with ten people who really know this environment and seeing whether your assumptions resonate with their reality?”
I added one condition because I did not want him to turn those conversations into sales meetings: “Do not take the solution with you.”
That sentence mattered. I was not suggesting that he put the machine on a table and ask ten people whether they liked it. I wanted him to leave his answer at home for a moment and investigate the world in which that answer was supposed to create value.
He looked puzzled and told me that the solution was not finished and that people might copy his idea.
I remember thinking that this was a fascinating response. He had already been willing to expose substantial amounts of his own time and money to the venture, but exposing his assumptions to people outside the venture felt much more dangerous.
You can learn a lot inside a black box without learning what matters most
To be clear, this founder had not been sitting around doing nothing. He had learned an enormous amount. He had learned about robotics, computer vision, medication dispensing, available technologies, market size, trends, and related developments. His machine had become better because of that learning.
The problem was not the absence of learning. The problem was where the learning was taking place.
Most of it was happening inside the black box of the venture.
Information entered through reports, statistics, technical knowledge, and secondary sources. Inside that box, the founder interpreted the information, connected it to his idea, solved additional engineering problems, and improved the solution. What was largely missing was an independent signal coming back from the system he eventually hoped to change.
This distinction has stayed with me because it is possible to learn enormously while barely changing your understanding of the assumption that matters most.
You can become a much better engineer.
You can understand the technology much more deeply.
You can build a more sophisticated product.
You can collect another hundred pages of market information.
You can become increasingly capable of explaining why your idea should work.
Meanwhile, the most important question may remain almost untouched: does the world in which this venture has to survive work the way we think it does?
The reluctance to take even simple steps outside our own thinking is not unusual. Bennett and Chatterji studied the early entrepreneurial activities of Americans in a nationally representative survey and found that fewer than half of people who had considered starting a business took even very low-cost steps such as searching for competitors or discussing the idea with someone. In discussing the findings, the researchers specifically pointed to the surprisingly large number of prospective entrepreneurs who never speak about their idea with somebody they do not already know. [1]
That finding interests me because the barrier is often not money, technology, or access to a laboratory. Sometimes the barrier is simply the uncomfortable act of allowing an independent person to react to something we currently believe.
Being excellent at solving problems is not the same as finding the right problem
The founder with the robot was particularly interesting to me because his weakness was connected to a genuine strength.
He was excellent at solving difficult engineering problems.
Engineering gives us powerful ways to deal with complexity. We can decompose systems, investigate causes, understand dependencies, model interactions, improve components, and gradually make something work. When a technical problem becomes complicated, greater technical understanding is often exactly what we need.
Entrepreneurial uncertainty is different because some of the important variables are not contained inside the technical system.
You cannot calculate your way to whether a hospital will change an established process. You cannot derive from first principles who has enough motivation and authority to push a change through an organization. You cannot prove through engineering excellence that the people involved will accept a new workflow, that the economic benefit will appear in the budget of the actor who must pay, or that the improvement you find compelling is important enough to displace everything else competing for attention.
Some answers exist outside the venture.
That means entrepreneurship requires a capability that can feel almost opposite to engineering competence. Instead of proving that you can solve the problem, you repeatedly have to expose your current understanding to situations in which you may discover that you have framed the problem incorrectly.
I think this is one reason solution-first ventures are so tempting. Building gives you progress you can see. Another component works, another feature is finished, another technical uncertainty disappears, and the prototype becomes more impressive.
Going outside is much less controllable.
The other person may not understand what you expected them to understand. The problem may not matter enough. Another stakeholder may turn out to control the decision. The current workaround may be good enough. The economic value may occur somewhere other than where the cost is created. Someone may reveal a constraint that your entire solution ignores.
You give reality permission to disturb your beautifully constructed answer.
That is a different kind of work.
Wicked problems can seduce us into wicked learning processes
During that conversation I noticed another pattern that I have since seen many times, including in myself.
The problem was complicated, so the founder responded with increasingly complicated thinking. There were many stakeholders, many technical considerations, many potential routes to market, and many things that could matter. His answers became correspondingly sophisticated.
I think of this as wicked problem meets wicked thinking.
There is nothing wrong with thinking deeply about a difficult system. The mistake comes when we assume that because the overall problem is complex, the next learning step must also be complex.
Often it does not.
The intellectual challenge is sometimes to take a complicated situation and find the smallest part of it that reality can answer next.
Speaking with ten relevant people would not have solved medication distribution. It would not have validated the business, and it would certainly not have guaranteed adoption. Subject experts can be wrong, customers can misunderstand their own future behavior, and what people say is not automatically what they later do.
Those conversations would have had a much smaller job.
They could have made some important assumptions less uncertain.
The founder could have asked people to walk him through the last time they dealt with the relevant medication process. He could have asked who was involved, what they were trying to accomplish, where the process became difficult, what happened when things went wrong, what they had already tried to improve, what prevented improvement, and which other priorities competed with this one.
He could have learned how the system actually behaved before asking the system to evaluate his answer to it.
This is consistent with what research on entrepreneurial experimentation has been finding. Camuffo and colleagues tested a more structured approach in which entrepreneurs state assumptions and deliberately test them rather than relying primarily on intuition. Their original randomized study found that entrepreneurs using this approach became more precise in deciding which ideas to pursue or change. A later replication across 759 firms in four randomized controlled trials found more idea termination and results consistent with entrepreneurs becoming more willing to consider that explanations other than their preferred one might be true. [2][3]
I like the practical implication much more than the terminology around it. A strong founder does not need to be permanently doubtful. A strong founder needs to know which assumption matters enough to deserve an encounter with something that can disagree.
Interested in working together?
The simplest experiment may require more courage than another month of work
There was another part of the founder’s answer that deserves attention. He was worried that people might copy his idea.
That fear is not absurd. Intellectual property can matter, and there are situations in which revealing technical details too early would be careless.
But that was next to the discovery work exactly why I had told him not to bring the solution.
He did not have to explain how the robot worked. He did not have to expose proprietary technology. He did not even have to tell people exactly what he planned to build.
He only had to investigate the situation.
This is where I think founders can sometimes confuse sharing the solution with exposing the assumptions behind the solution.
They are not the same.
You can ask a hospital employee to describe how a process works without showing them your machine. You can ask a physician about a recurring struggle without explaining how you intend to solve it. You can investigate who makes a decision, who experiences the problem, who pays for it, and what keeps the current process in place without giving anybody your intellectual property.
In fact, bringing the solution too early can make the learning worse.
Once the machine is on the table, the conversation naturally moves toward the machine. People react to its features, imagine how it might fit, identify improvements, ask technical questions, and try to be helpful. Now you are no longer only investigating how their world works. You have introduced your own interpretation into that world and asked them to respond to it.
There is a time for that conversation.
It is simply not always the first conversation.
Resonance requires something outside your own head
The word I used with the founder was resonance, and I still like it because resonance requires an exchange.
You cannot create meaningful resonance while keeping everything inside your own system.
Something has to leave.
Something independent has to respond.
Then you need to pay attention to what comes back, especially when it is not the response you hoped for.
Founders sometimes want certainty before they initiate that exchange. They want the product to look professional, the pitch to be complete, the questions to be polished, the intellectual property to feel safe, and the business model to be sufficiently developed before approaching outsiders.
The difficulty is that certainty is often what the exchange is supposed to help create.
If you wait until everything is sufficiently developed before exposing the assumptions, you are learning inside your black box while the cost of discovering that you were wrong keeps increasing.
The world will eventually enter the venture anyway.
The only real choice is when and at what cost.
He eventually met the real world with the finished machine
The founder did not follow my advice.
Instead of first going out without the solution and learning how the environment worked, he continued and eventually went from hospital to hospital presenting his machine.
That created learning too, but it arrived much later.
He began discovering how regulated and constrained the environment was, how much adoption depended on existing processes, responsibilities, people, and the wider system around the technology, and how different technical feasibility was from organizational adoption.
The machine still worked.
The adoption did not.
As far as I know, he did not get even a pilot.
I do not tell this story to claim that ten conversations would necessarily have saved his venture. Perhaps the conclusion would eventually have been the same. Perhaps another application, customer segment, or business model could have created a path. There are too many variables to turn one founder story into a general law.
The point is about the cost of learning.
He eventually received information from the real environment, but only after considerably more of the venture had been built around assumptions that could have encountered that environment much earlier.
Reality eventually enters every venture.
The question is how expensive you make the introduction.
I recognize the behavior because I have done it myself
It would be easy for me to turn this into a story about another founder who should have known better, but that would be dishonest.
When I was younger, somebody once asked me a similarly simple question: “Why don’t you speak with that person and find out?”
My brain immediately became creative.
Perhaps the person would not be available. Perhaps they would not want to speak with me. Perhaps they were too busy. Perhaps approaching them would be inappropriate. Perhaps they were not interested. I could produce an impressive number of explanations for the behavior of someone I had not even contacted.
At some point I realized how strange that was.
Instead of letting the person answer a relatively cheap question, I was letting my own mind simulate their answer.
That experience changed something in the way I work. Today I deliberately try to get into an exchange with people I do not know almost every day, often aiming for three new interactions. I do not do this because every person replies or because every conversation produces an insight. Many do not respond, and many exchanges remain brief.
I do it because i want to keep my brain fit and open, every now and then someone introduces an observation I could not have created from inside my own thinking.
Sometimes I learn something about the subject.
Quite often I learn something about myself.
The practice has become a way of reminding myself that I should not let my own mind answer questions that another human being can answer more directly.
AI did not create this tendency; it made it much easier to stay inside
This is where generative AI becomes relevant to the story.
I use it a lot myself, and I believe it is becoming an extraordinarily useful tool for innovation. Research already describes AI being used across new product development for searching and combining knowledge, ideation, foresight, concept development, evaluation, prototyping, simulation, decision support, commercialization, and post-launch learning. More recent work even describes GenAI as a synthetic teammate throughout parts of the development process. [4][5]
We can now create market summaries, personas, synthetic customers, interview simulations, possible future scenarios, competitor reactions, alternative business models, idea rankings, prototype variations, and expert-like critiques without leaving our desks. Research on synthetic respondents suggests that these tools can be useful for activities such as preparing and improving research, while also warning against casually treating generated respondents as substitutes for real human samples. [6]
I find many of these uses valuable.
The problem is not that the information is synthetic.
The problem begins when synthetic interaction becomes a comfortable replacement for the uncomfortable interaction we were already trying to avoid.
The founder with the medicine robot needed weeks and months to construct his world from secondary research. Today he could build an even more convincing version of that world in an afternoon. He could create hospital personas, simulate interviews with physicians, ask an AI panel to evaluate his robot, generate objections, create adoption scenarios, rank possible customers, and ask another AI to challenge all the previous output.
He could feel that he had interacted with an entire market while still never speaking to one person in it.
AI did not invent that temptation.
It amplified it.
What once looked like procrastination can now look remarkably similar to sophisticated innovation work.
The danger is not using AI; it is using it to avoid an answer you do not control
There is an important distinction here because I do not want the conclusion to become “real people good, AI bad.”
If I interview real people and use AI to help me identify patterns across those conversations, AI can improve my learning, as Chris Spiek recently demonstrated here.
If I ask AI to find contradictions in my notes, challenge my interpretation, suggest questions I forgot to ask, or identify stakeholders I have overlooked, it can make the next conversation much better.
If it helps me create a rough prototype in one afternoon instead of spending six weeks building it, I can reach real feedback sooner.
If it shows me five alternative explanations for what I have observed, I can design a better next experiment.
In all of these situations, AI helps shorten the distance between an assumption and something outside the venture that can respond to it.
The opposite happens when AI becomes the response.
If I ask a synthetic customer whether the problem is important and then treat the answer as evidence that the problem is important, I may have shortened the production of an answer while increasing the distance from the person whose behavior matters.
This is why I have become less interested in asking how much of innovation AI can automate and more interested in asking what AI does to the speed and quality of our contact with reality.
If it helps us reach that contact sooner, use it aggressively.
If it gives us another reason to postpone the contact, be careful.
Interested in working together?
A founder’s job is not to have the most sophisticated answer
Looking back at that conversation, I think I was reacting to a broader misunderstanding of entrepreneurial competence.
We often admire founders who appear to have answers for everything. They understand the technology, market, competitors, strategy, business model, and future. Investors ask hard questions, so founders learn to produce convincing answers. Employees need confidence, so founders communicate conviction. Customers want credibility, so uncertainty gets hidden behind a clear story.
Some confidence is necessary.
But the founder’s most valuable capability under uncertainty may not be the ability to produce an impressive answer to every difficult question.
It may be the ability to recognize which answer still depends on an assumption and then create the smallest useful way for that assumption to encounter the real world.
That means the founder’s job is partly to make the venture easy to correct.
The team should become good at asking what it needs to learn next, what evidence would actually change its mind, and what interaction could produce that evidence without consuming more resources than necessary.
This is why I think simple experiments are so easily misunderstood. Simple does not mean intellectually shallow.
Finding a small experiment that teaches you something important can require more thinking than building a sophisticated solution.
You have to understand the uncertainty well enough to reduce it to a question that reality can answer.
The customer does not begin with your solution
Before ending our conversation, I asked the founder one last question.
“What is the most critical and important thing about this business idea that you need to learn next?”
He thought for a moment and replied that he needed to know whether the solution would be adopted and used.
His answer made sense, particularly after everything he had already built, but I remember thinking that I would still start one step earlier.
The question was still framed around the solution.
I would first want to understand what these people were actually trying to get done and what progress they were trying to make in their specific circumstances. Jobs to Be Done provides one useful way of approaching exactly that question: instead of beginning with product attributes or customer profiles, it asks what people are trying to accomplish, what pushes them away from their current situation, what pulls them toward something different, and what functional, social, and emotional forces influence the decision. [7]
For this founder, that meant understanding the actual work around medication preparation before asking whether anybody would adopt a robot designed to change it. I would want to understand what people were trying to achieve today, which parts of the current process frustrated them, what they already did when those problems occurred, what prevented them from changing, who experienced the problem, who benefited from solving it, who had authority to change the process, and what risks or trade-offs made the current way of working persist.
None of those questions required him to show the machine.
At that stage, I would not have presented anything.
I would have tried to understand their world before asking them to react to mine.
The free section of INNOVATION& is offered freely, and you are welcome to keep reading it that way. If these articles help you make better decisions in your working life, please consider becoming a paid subscriber. Researching and writing them takes time, and paid subscriptions provide the income I need to continue. Your support also helps keep part of this work available to everyone.
Thanks for reading INNOVATION&! This post is public so feel free to share it.
Start paid learning and application section
The Assumption-to-Reality Ladder
The practical difficulty is that innovation teams rarely lack information. They usually have too much of it. Reports, internal opinions, AI analyses, customer quotes, prototypes, expert views, market forecasts, and business cases accumulate until it becomes difficult to remember which claims have actually encountered the world and which ones have simply been discussed repeatedly inside the project.
The Assumption-to-Reality Ladder is a simple way to prevent that confusion. It does not rank one research method as universally superior to another. Its purpose is to ask whether the evidence supporting the next commitment is strong enough for the particular uncertainty the team is trying to reduce.
Start with the next decision that will consume meaningful money, time, credibility, or organizational energy. Then identify the assumption that would make that commitment a bad decision if it turned out to be wrong.
The ladder moves through seven kinds of learning:
