For over a decade, I made my career inside corporate innovation labs. If you have ever worked in one, you know the specific energy of that environment. When they are run correctly, leadership provides the political cover for a small, elite team to obsess over what comes next. We operated on informed hunches, high velocity, and a healthy disregard for the status quo. We tracked global shifts, interviewed customers to understand their deepest pain points, experimented with tech that barely worked until it worked, and built prototypes that served as continuous experiments on the future.
Lately, the corporate innovation lab has lost some of its luster in the traditional enterprise. Labs got cut, folded into product organizations, or quietly starved. Some of that was deserved. Too many labs produced demos that never crossed the gap into the business, and the business learned to ignore them.
But as I look at the landscape in 2026, I think most companies have drawn exactly the wrong conclusion. They killed the lab at the moment the lab’s way of working became the only way to build. Because of AI, an experimental “labs” approach is now the baseline requirement for product development. Companies that miss this will miss out on commercializing AI.
So I want to make two arguments that sound contradictory and are not.
First: we are all in the lab now. Every team building on AI has to work the way a lab works.
Second: that is precisely why you need a real, dedicated, protected lab again. I will reconcile those below, but first, why the old way broke.
The Jagged Frontier of Probabilistic Products
The need for this mindset comes from a concept called the Jagged Frontier. Coined by researchers at Harvard, MIT, and Wharton, it describes the uneven landscape of AI capability. For some complex tasks, AI is superhuman. For others, it fails in ways that are hard to anticipate, and the boundary between the two does not follow any line you would draw in advance.
In the traditional corporate factory, the frontier of technical capability is smooth and predictable. You know what a senior engineer or a junior designer can contribute and how long a task will take. That predictability made the classic assembly line of software possible: spec, then build, then QA. We got very good at building deterministic products because we knew exactly what the output should look like before we started.
LLMs broke that. We are now building probabilistic products, and the linear process struggles with them. An AI agent might architect a complex backend in seconds and then fail to center a button, or confidently hallucinate a security vulnerability that does not exist. You do not know where the dips in capability are until you hit one. So you cannot plan your way across the frontier. You have to explore it, rapidly and continuously. This is not building a CRUD app on a schedule. It is a journey of continual learning.
Exploring the Market and the Technology at the Same Time
In this reality, speed of exploration is a survival metric, not a luxury.
Historically, customer development was built on scarcity. Writing code was expensive and slow, so you interviewed customers obsessively to gather every scrap of information before committing a line to production. You had to be right the first time because being wrong was a capital offense.
In 2026, code is cheap and fast. You can build a working prototype in an afternoon. The bottleneck is no longer build cost. It is context cost: knowing what to build, for whom, with which model and which scaffolding, this month.
Because every layer of the AI stack is changing at once, customers often do not know what they need until they touch it. Spend three months interviewing them and you will hear about problems that will not exist in four months. And the technology side is just as uncertain. Which models? Which agent framework? Which retrieval approach? That is a second layer of discovery, running in parallel with the first.
To survive this, you move from “measure twice, cut once” to an OODA loop with rapid experimentation.
In the factory: you plan for the average. You know what works, so a repeatable process is straightforward. You know what customers want because you just asked them.
In the lab: you place multiple micro-bets, then use high-frequency feedback to re-evaluate them. Your main job is managing the jaggedness of the technology against the volatility of the market. You do not just build a roadmap. You manage a portfolio of experiments.
Some executives will not like this. But you are not guessing. You are making educated bets, and you are finding out faster than anyone who waited for certainty.
De-Risking Through Discovery
The core of labs thinking is de-risking. Like a startup, a lab spends its time with emerging technology and unknown markets. Early in any project you have to decide what you are de-risking first: the market (do people want this?) or the technology (can we actually build and scale it?).
With LLM-based products, you often do not know if a feature will work until you try it. So you iterate between the use cases you think people want and what you can actually execute with current models. That changes commercialization in at least two ways.
Beachhead market selection. In a deterministic world you picked the best market, because you knew you could make the product work. In an AI world you may need to run several use cases at once to see where the AI actually performs before you commit to a market.
Feature planning. Your favorite feature might not be technically viable yet. You need to be willing to pivot to a lower-priority feature that works today. You only find these answers through exploration, never through a planning session.
Taste as the Compass
When the frontier is jagged, the market is moving, and building is cheap, process can no longer guarantee quality. What fills the gap is judgment. Can you make good bets?
In the lab, the team is not checking boxes against a spec. They are navigating the frontier and deciding, output by output, when something is magic and when it is trash. You can’t legislate taste in a handbook. You can only cultivate it in an environment where people try things, see the results, and argue about them. Companies that try to run as rigid factories in 2026 will be overrun by competitors that operate as learning organisms.
Orchestra vs. Jazz Band
An orchestra is a factory. There is a score, written in advance by someone who is not in the room, and the job of ninety musicians is to play it exactly. Every note, every entrance, every dynamic is spelled out. The conductor’s job is to make sure the plan happens. It is a magnificent way to produce a known result at scale, and it is how most enterprise software has been built. The score is the spec. You know what you are going to hear before anyone plays a note.
A jazz quartet has no score. It has a lead sheet, a melody and the chord changes on a single page, and a bandleader who calls the tune and counts it off. Everything else happens live. Each musician listens to what the others are doing and decides, right then, what to play next. Most of the time you are not soloing. You are comping, backing up whoever is, and sometimes the smartest thing you can do is stop playing for a bit. A wrong note is not a mistake yet. What you play after it decides that. The music does not come from the plan. It comes from the band reacting to itself, and the same tune sounds different every night because the players learned something since the last one.
A good labs team works like a jazz band.
The prototype is the lead sheet. It is the one page everybody plays from: the melody of the idea and enough structure to build on, but not a score telling every engineer and designer exactly what to do. Once it exists, the team plays on it, in front of each other, every day.
Listening is the job. The band moves like one organism because every player is reacting to every other player and to the room. A labs team runs on the same fuel: constant feedback from users and telemetry, heard by everyone and acted on right away. That is the hive mind. It is not mystical. It is a bunch of musicians who have learned to hear each other.
Comping beats presenting. There are no polished decks because there is no rehearsal to hide them in. Work is a steady stream of half-baked ideas and live correction. You spend most of your time making someone else’s idea sound better, and you have to be okay sounding wrong in public on the way to finding what is right.
Wrong notes are material. None of this works in a top-down, high-churn shop where the rule is “nail it the first time or you’re gone.” A band that is scared of a bad note plays nothing worth hearing. Teams that cannot risk looking dumb never take enough swings to find anything interesting. The bandleader does not conduct. They pick the tune, count it off, point at who solos next, and keep the room safe enough that people actually play.
The orchestra wins every time the piece is already written. The band wins when nobody has written it yet. On a jagged frontier, nobody has.
A Lab Is a Place. Labs Thinking Is a Method.
Here is the apparent contradiction. I just said every team is in the lab now. I am also about to tell you to go build a real one. Both are true, because a lab and labs thinking are two different things.
Labs thinking is a way of working: prototype before spec, lower fidelity early, micro-bets instead of a master plan, feedback every day, wrong notes treated as material. That is a method, and a method travels. Every product team building on AI needs it, because every product team building on AI is standing on the jagged frontier whether it wants to or not. The water rose. Everyone has to learn to swim.
A lab is a place. It is a protected group with a different mandate, a different time horizon, and a different tolerance for failure than the teams shipping this quarter’s roadmap. It does three things the rest of the company cannot.
It goes further out. Product teams explore the frontier close to shore, where the use case is mostly known and the question is which model and which scaffolding make it work. The lab explores where the use case itself is unknown, the hit rate is lowest, and the payoff is a year or more away. Those bets die in a quarterly planning cycle. They survive in a lab.
It concentrates the rare people and trains the rest. The instincts this piece describes, knowing when to lower the bar, when a wrong note is worth following, when a demo is magic versus trash, are scarce. A lab is where you put the people who have them, and it is where the next generation learns by playing next to them. Think of it as the company’s teaching hospital. It exports prototypes, but its more important export is people who know how to work this way, rotated back into product teams.
It absorbs the risk. A lab exists so that someone with authority can say, out loud, that this group is allowed to be wrong most of the time. That cover is political, not technical, and it is the thing product teams under delivery pressure can never fully grant themselves.
Now the reconciliation. The reason labs lost their luster was never that exploration stopped mattering. It was the handoff. The lab would play jazz, hand a lead sheet to an orchestra, and watch the orchestra demand a score. The prototype died in the gap between the two cultures. That is the valley of death every corporate lab veteran has watched a project fall into.
When the whole company works with labs thinking, the gap closes. The product team receiving the prototype already knows how to play from a lead sheet. The lab is no longer a foreign body that the organism rejects. It is the part of the organism that scouts furthest ahead, feeding back to teams that speak its language.
So the two arguments are not in tension. They depend on each other. A company with a lab and no labs thinking gets demos that never ship. A company with labs thinking and no lab gets incremental improvement and never finds the next thing, because nobody is allowed to look that far out. You need both: the method everywhere, and a place where the method is pushed to its limit.
The Survival Playbook
The transition from a rigid machine to a breathing organism is hard, and it is the only way to stay relevant. The playbook has two halves: what every team does, and what only the lab does.
For every team building on AI
Build fast for feedback. You can put three prototypes in front of customers faster than you used to be able to schedule the interviews. Do that instead.
Make experimentation part of the process. Move to AI-assisted workflows now. See what breaks and fix it. If you are keeping agile, plan spikes whose only deliverable is learning what works.
Match fidelity to the stage. The earlier the experiment, the lower the fidelity should be. Do not slow down or kill projects by over-designing them too soon. Accept a lower bar early and expect directionally positive results over time.
Write lead sheets, not scores. Build prototypes and question big specs. Favor building over process.
Accelerate compliance. If Legal or Finance takes six months to approve a tool, the tech will have changed three times before you start. Make the approval loop as fast as the build loop.
Make it safe to be wrong in public. Celebrate the attempt that looked wrong at first. An employee punished for being creative will never be creative for that management team again. A leadership team that wants everything right the first time has already lost.
For the lab
Re-launch it, protected, with the right leader. Not a committee, not a rotating assignment. One leader who has run a lab or a startup, with an explicit mandate to look further out than the roadmap and an explicit license to fail most of the time.
Hire actual labs and startup people. There are people who have spent years developing these de-risking and taste instincts. There are not many, but you can find them. They are building on weekends, and they might welcome an escape from a software factory to come work for you.
Give it a longer clock. The lab’s bets should be the ones that don’t always fit in a quarter (although, these days they often do).
Teach other teams. I’ve found it useful to sometimes take a break from focused labs work to advise software factory teams to think more like a labs.
Measure it on what it feeds the company. Prototypes that became products, people who learned the method, dead ends found - that saved a product team six months. Not demo count.
In the age of AI and AI-enabled rapid development, experimentation is a mandate for every team building something new that runs on AI. The lab is no longer just a department. It is the whole company.
But somebody still has to run the lab. The method belongs to everyone now. The place, with its longer horizon, its rare people, and its larger license to fail, belongs to the few who are sent furthest out to find what the rest of us will be building next year.
We are all in the lab now. Also, bring the real one back.