Insight
When learning becomes
cheaper than approval.
The bottleneck is moving from building ideas to adopting what works. Our innovation processes need to move with it.
Imagine six people spending two hours deciding whether an idea deserves a prototype.
At an assumed fully loaded cost of €75 per person per hour, that meeting costs €900. One person spending a day building a bounded experiment, with another €200 allocated to tooling, costs €800.
These are illustrative numbers. The experiment may take longer. Some ideas cannot be tested in a day. A prototype is not a production system. But the comparison raises a question that deserves more attention:
What happens when deciding whether to learn costs more than learning?
For any experiment that crosses that threshold, the approval process needs an economic justification of its own.
We have become good at evaluating descriptions
When development requires a team, a budget and months of work, early selection makes sense. You cannot build every idea, so you ask people to explain the problem, estimate the return and compete for resources.
The difficulty is that a description asks everyone to imagine the same thing. They rarely do.
Someone sees a useful shortcut. Someone else sees another system to maintain. A third person cannot picture how it would fit the work. The meeting becomes a negotiation between different imagined products.
A working experiment changes that conversation. People can try it, identify what is missing and discover whether it helps. Sometimes they find an opportunity the original description did not contain.
That is the strategic issue. If an idea has to be understood before it can be explored, we risk selecting for familiarity. During a substantial change in what technology makes possible, that may be an expensive filter.
This is a risk to examine, not proof that every unfamiliar idea is valuable. Experiments need to be able to disappoint us, too.
Move the decision closer to evidence
Modern Stage-Gate approaches already include experiments, learning and levels of process suited to risk. The target here is a specific organizational habit: demanding an elaborate justification for a small experiment before anyone has evidence from using it. [1]
Coding agents make it worth revisiting that habit for more kinds of software work. Where a useful test becomes cheap, contained and reversible, permission can be granted in advance.
Give people an approved environment. Define the data they may use and the actions they may take. Set a small time and spending allowance. Let them test a real problem with the people who experience it.
Then ask better questions. Did anyone use it again? What changed in the work? What failed? Is there a person willing to own the next step?
Guardrails before experimentation. Evidence before commitment.
The guardrails are concrete
The starting boundaries are the company's approved technology stack and its data security rules.
Those boundaries have to be usable. People need to know which environment they can start in, which data is permitted and where an experiment must stop. An approved tool does not imply permission to connect every dataset or take every action.
Within that scope, the organization can make experimentation routine. Outside it, additional review has a specific purpose: a new data permission, a new system, a larger spend, an external obligation or an operational dependency.
Technical size is a poor proxy. An ambitious prototype using synthetic data may be contained. A tiny change to payroll may be consequential.
The dividing line is the difference between exploring an opportunity and committing the organization to it.
The bottleneck moves to adoption
If more people can build, more prototypes will exist. That alone is not a success measure.
The harder questions may come afterwards. Who changes the workflow? Who maintains the application? Which existing tool does it replace? Who checks whether the benefit survives real use? What gets retired?
Cheap building can expose an adoption constraint that was previously hidden behind a development backlog. It can also create a growing collection of abandoned experiments if nobody owns the transition.
This is where leadership attention becomes especially valuable. Help useful experiments become reliable, owned parts of the organization. Stop the ones that do not earn that commitment.
Budget the freedom to discover. Govern the commitment to adopt.
Give people room to act like founders
There is a useful analogy with staged investment: start with a limited commitment, learn and decide whether further investment is justified. Early investors still select opportunities. The analogy does not mean funding every idea or dispensing with diligence. [2]
Inside a company, the first step could become smaller still. If an experiment fits within an agreed allowance, it may not need an individual investment decision at all.
People closest to the work can explore improvements before they have a polished pitch. Leadership continues to set direction, coordinate shared needs and make consequential commitments. Evidence from those experiments can also change the direction.
I think of this as founder-like exploration inside enterprise guardrails: initiative and discovery, supported by an organization that makes the boundaries clear.
Where David fits
This is the organizational possibility behind David, our environment provisioning platform at frontira.
David brings the setup of software environments into a repeatable process. The ambition is to let an organization make approved environments readily available, so each new experiment does not begin with a separate infrastructure project. The current product describes provisioning, stack choices and environment lifecycle capabilities; the exact configuration and controls depend on the deployment. [3]
The proposition is larger than faster setup: give more people the freedom to discover, then concentrate organizational effort on adopting what proves useful.
That is a hypothesis worth testing in practice. Choose a small group, a permitted environment and a handful of real problems. Record the time spent seeking permission, building, gathering feedback and reaching an adoption decision. Count useful evidence and repeated use, not just prototypes created.
The question I would start with is simple:
Think of the last small internal software idea your organization discussed. What took longer: getting permission to try it, building a useful test, or getting people to adopt it?
If you lead a team, I would like to hear the example, including where this argument breaks down. Reply where you found this article, or write to me.
Notes
- Stage-Gate International: Using Stage-Gate to Enable Digital Transformation Success. The framework explicitly discusses early experiments and matching rigor to risk. This article challenges an approval habit, not all stage gated processes.
- Y Combinator: A Guide to Seed Fundraising. Context for the limited seed stage analogy; it does not establish the superiority of a corporate innovation model.
- David by frontira. Product context, distinct from the proposed organizational operating model.
The cost example uses assumptions, not measured client results or a quoted subscription price. It includes the builder's time and a full €200 tooling allocation; it excludes subsequent production, integration and support costs.
