For over a decade, I have 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 elite teams 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 essentially served as continuous experiments on the future.

Lately, it seems the corporate innovation lab has lost some of its luster in the traditional enterprise. I believe that is generally an oversight. With the right leadership and a protected environment, these teams can be transformative. However, as I look at the landscape in 2026, I realize something many have missed. While corporate innovation groups seem to be disappearing, the mindset is more essential than ever. Because of AI, an experimental “labs” approach is now the baseline requirement for survival for product development. Companies that miss this will miss out on commercializing AI.

We are all in the lab now.

The Jagged Frontier of Probabilistic Products

The need for this mindset is driven by a concept known as the Jagged Frontier. Originally coined by researchers from Harvard, MIT, and Wharton, it describes the unpredictable landscape of AI capabilities. For certain complex tasks, AI is superhuman; for others, it fails in ways that are difficult to anticipate.

In a traditional “corporate factory,” the frontier of tech capability is a smooth, predictable line. You know exactly what a Senior Engineer or a Junior Designer can contribute and how long a task will take building deterministic technology. This predictability allowed for the classic, largely predictable “Assembly Line” of software: Specs to Build to QA. We became experts at building deterministic products because we knew exactly what the output should look like.

LLMs have changed that. We are now building probabilistic products, which makes the old linear process much harder to manage. An AI agent might architect a complex backend in seconds but then fail to center a button on a UI or hallucinate a security vulnerability. Because you do not know where these “dips” in capability are until you hit them, you can’t rely on a linear factory process. You have to use a lab process of constant, rapid fire exploration. This is not just building a CRUD app on a schedule; it is a journey of continual learning.

Navigating the Exploration of Market and Technology

In this new reality, the speed of exploration is a survival metric rather than a luxury.

Historically, customer development was built on a foundation of scarcity. Writing code was expensive and slow, so you obsessively interviewed customers to gather every possible scrap of info before committing a single line to production. You had to be right the first time because being wrong was a capital offense.

But in 2026, code is cheap and fast. You can build a prototype in a few hours to show someone basic functionality. The bottleneck is no longer the “build cost”; it’s the “context cost.”

Because every layer of the AI stack is changing simultaneously, customers often don’t know what they need until they touch it. If you spend three months interviewing them, you’ll hear about problems that won’t even exist in four months due to market shifts.

In addition, you don’t know what exactly what will work and won’t work, technically. What models should you use? What scaffolding should you use? It’s another layer of exploration and discovery.

To survive this, we have to move from a “Measure Twice, Cut Once” philosophy to an OODA loop + rapid experimentation model. * In the Corporate “Factory”: You plan for the average. You know what works, so planning a repeatable process is straightforward. And, you know what customers want, you just talked to them.

• In the new “Lab”: You build multiple “micro-bets,” then use high-frequency feedback to re-evaluate them quickly. Your main job is managing the jaggedness of the technology against the volatility of the market. You don’t just build a roadmap; you manage a portfolio of experiments. Some executives might not like this, but you’re making educated bets.

The lab is the correct organizational structure flexible enough to contour to a frontier that is unpredictable.

De-Risking through Discovery

The core of labs thinking is de-risking. Like a startup, a lab spends its time with emerging tech and unknown markets. Early in any project, you must decide if you are de-risking for the market (do people want this?) or de-risking the tech (can we actually build and scale this?).

With probabilistic products/ LLM-based products, you often do not know if a feature will work until you try it. This requires iterating between the use cases you think people want and what you can actually execute with current LLMs. This impacts product commercialization in at least two major ways:

1. Beachhead Market Selection: In a deterministic world, you just pick the best market because you knew you could make it work. In an AI world, you may need to experiment with multiple use cases simultaneously to see where the AI actually performs best before committing to a market.

2. Feature Planning: Your favorite feature might not be technically viable yet. You need to be willing to pivot to a lower priority feature that actually works. You only find these answers through exploration.

Taste and Exploration as the Compass

Because the frontier is jagged and the market is moving - but software development is faster, you can no longer rely solely on process to guarantee quality. This is where intuition and taste become critical. Can you make good bets?

In the lab, the team is not just checking boxes against a spec. They are navigating the frontier and using their judgment to decide when the output is “magic” and when it is “trash.” You can’t legislate taste in a handbook; you can only cultivate it in an experimental environment. Companies that try to operate like a rigid factory in 2026 will be overrun by competitors who operate as organic learning machines.

The Campfire and the Hive Mind

In a high-performing lab, you do not build from a spec; you build around a campfire. You start with a living prototype and the team gathers around to sculpt it together. This organic approach relies on two shifts that can be uncomfortable for traditional corporate cultures:

• The Death of Ego: There is no hiding behind polished presentations. Work is a continuous stream of messy ideas and real time correction. You have to be comfortable looking “wrong” on the way to finding what is right.

• The Hive Mind: These teams are driven by collective intelligence reacting to telemetry and high frequency feedback loops. When aligned, the team moves with the fluidity of a flock of birds rather than a rigid hierarchy.

The Survival Playbook

The transition from a rigid machine to a breathing organism is challenging, but it is the only way to stay relevant. To embrace the lab mindset, consider these steps:

• Build Fast for Feedback: You can jump right into multiple prototypes and test them with customers faster than you could have asked them what they wanted in the past.

• Experimentation: Move toward AI assisted workflows immediately. See what breaks and fix it in the lab. Plan on rapid experimentation as part of your development process. If you’re keeping the agile process, plan on spikes for discovering what works.

• Accelerate Compliance: If Legal or Finance takes six months to approve a tool or product, the tech will have changed three times before you start.

• Match Fidelity to Process: The earlier you are in the experiment, the lower the fidelity should be. Don’t slow down or kill projects by over designing them too soon. Allow lower bars earlier, but expect and delivery directionally positive results over time.

• Build Prototypes, Question Big Specs: Knock down the silos and get your teams building together around a shared vision. Favor building over process.

• Hire actual labs and startup people: There are people who have been developing these de-risking/ experimental and taste instincts for a while. Hire people who can help guide and run these things - the natural experimenters that worked in labs and startups in the past.

• Re-launch that dedicated, protected lab with the right leadership that understands the above.

In the age of AI and AI-enabled rapid development, experimentation is a mandate for every department that is developing something new that runs on AI. The lab is no longer just a department. It’s the whole company.

In 2016, during my tenure as head of product at an AI startup, I used the term “Probabilistic Product“ in some personal discussions and public speaking engagements. When discussing AI/ML product planning I noticed that we were thinking differently about how to approach product than before. With the more recent developments in GenAI, it’s more relevant than ever.

For years, we built deterministic products—input A and B, then expect C behavior and output. That’s what I was used to. But I sensed a shift. A new era of product and product management was dawning, one driven by probabilities rather than certainties. I believe that as AI continues to evolve, probabilistic products will become central to taking AI and applying it to use cases. But what exactly is a “Probabilistic Product”?

What is a Probabilistic Product?

In the traditional software world, we’ve mostly built products that are deterministic - predictable systems where inputs and outputs are well-defined and predictable. For decades we’ve mostly collected data, stored data, managed data (CRUD) in databases, made calculations on numbers, formatted text, ran algorithms, and created very predictable output. Almost all of the B2B and B2C software you use follows this pattern. When an output deviates from expectation, we know to investigate. Something must have gone wrong. This predictability made our lives easier. The real challenges have mostly been the humans that used our products. A user could get confused and enter some data that was unexpected. Or a user could be nefarious and intentionally interact with the system in ways we hadn’t predicted. Now, unpredictability isn’t limited to humans; AI introduces its own additional form of uncertainty.

I would define probabilistic products as:

The true allure of probabilistic products lies in their ability to generate diverse outputs within a workflow or ultimate outcomes that are not predictable. Probabilistic products can have emergent behaviors. It’s more human-like. As a simple example, AI chatbots offer companionship through unpredictable interactions, making them feel more like humans, who are also unpredictable.

Chat products that allow wide-open discussions between humans and an GenAI LLM are an example. It also will be part of all sorts of analysis use cases where the LLM is analyzing across documents and data.

This is a significant development—products with rudimentary thinking abilities. However, managing these products is complex. Like managing people, it’s a messy endeavor. Probabilistic products account for a range of inputs and potential outcomes, guiding decision-making through probabilities.

These products also can be made to learn and adapt. Unlike traditional systems, probabilistic models offer a range of outcomes with associated probabilities, enabling systems to handle ambiguity and incomplete data.

The rise of intelligent agents & smart automation

The vast majority of future products will have probabilistic components.

Probabilistic systems are inherently unpredictable. They can be built to adapt, learn, and evolve based on inputs. This complexity can lead to awesome new products and also new uncertainty around design.

It’s almost like product managers now need to create systems to manage digital employees (the agents) along with mapping out the use case and behaviors of the system.

In the future, these bots will become intelligent agents and will be involved in millions of business workflows. They will make decisions, change their “mind” based on probabilities and outside inputs.

- Managing Future Digital Employees, 2016

The future world where agents are everywhere will be even more unpredictable. We will have a chain of decision-making agents making on-the-fly decisions and passing them on as inputs to other agents who are also making decisions.

Probabilistic product management & design

This uncertainty poses challenges for product managers and designers. Using old thinking for these new AI-driven products can lead to unpredictable products being stuck in perpetual analysis paralysis.

Below are some initial ideas for things to consider when designing for probabilistic products in general. It’s not a checklist, but more of list of thought-starters for product managers and designers. I am staying at a high level and at the product design consideration level - and not getting into the multiple ways we could technically implement each.

Things to consider…

New kind of computing?

Having GenAI capabilities in the middle of your software feels like a new type of computing
When experimenting with GenAI and put it in the middle of a workflow, I get the sense we have a new kind of computing. In the past I could have an very specific algorithm, but with prompting, we now have a human-like probabilistic agent doing some very specific work. It feels different and new. Design-wise, it’s like building out workflows for your product where you can insert a human-like intelligence in key places in the workflow to do work.

Embrace uncertainty

Accept that your system’s outputs won’t always be predictable
This means planning for a range of outputs and understanding that variability is intrinsic to intelligent systems. This may also mean planning to give users additional caveats in writing inside your product to manage expectations.

Embrace agility

Use agility to de-risk
I think that zero-to-one products that have a lot of uncertainty (tech and/or market risk) should have small, dedicated teams iterating quickly and independently to de-risk the business use case and the operational/technical challenges. An innovation labs team structure. This goes double for new Probabilistic/ GenAI/ ML products. The AI behavioral aspects make the de-risking the product behavior different and more complex.

Agent behavior and output guardrails

Real-time, self-monitor
With judicious design of inputs and output on-the-fly analysis, systems can monitor their own behavior in real time to stay within behavior, personality, and brand constraints. The output can have a layer of checks to make sure it’s within pre-set parameters. You can control the mix of deterministic/ non-deterministic for your outputs and design accordingly. There are times you will want the output to be wide open and there are times where you will want to make the system turn internal non-deterministic inferences into more deterministic outputs.

Data access policies

Some users can’t access all the information from all systems
This one goes for all products (not just probabalistic) but may get a little tricky if you’re building an AI chatbot in particular. As we’re designing more multi-modal chat-based interfaces everywhere, within an enterprise context we don’t allow customers or employees to access all the data all the time. So, we’ll need controls so that the agent knows who it is talking to and what information can be provided to that particular user.

User input guardrails

The user is not predictable
When designing an interface where the user can enter a wide array of inputs (say, any text they want) then monitoring this and checking for questions you can’t or won’t respond to can save you a lot of grief. Users are not predictable, so saving your AI from responding to something you won’t or can’t is useful, especially with enterprise products that are trying to maintain a level of quality and professionalism.

Activity and identity logs

Time-stamp what agent or model who did what and when
On the first day of work, a new human employee gets an ID badge. In order to collaborate, we first need to know who all the collaborators are. We want a reasonably dependable way of knowing who we are collaborating with. So, the first order of business when managing agent technology is to provide a means to verify the identity of a bot. Identifying “who” did what with which model version would be useful.

Audit & observability

Performance reviews for AI agents
A human employee gets feedback in realtime, quarterly, or annually. This ensures that we’re following processes and also performing well within the workplace. In a business to business environment an agent will have contact with many people and other bots. Agents will be collecting information and making decisions. So, how do you go back and see who authorized the agent to make a particular decision? Or, a more complex problem, what if the agent made a decision all on its own? How can we go back and review those decisions?

Learning from data sources

AI employees can get smarter
Similar to managing a human, part of managing an agent is to help it learn and develop new skills. You want a good employee to always be acquiring new knowledge and skills. Like an employee, an agent will become more valuable to its employer by continually improving.

Learning from user feedback loops

Every interaction is a chance to learn
Your systems can learn something from all (or almost all) interactions with humans and other systems. Feedback loops are needed for your software to self-correct and learn and to give you information about how to adjust your product and plan for the future.

Human-in-the-loop

Sometimes a human brain is needed to augment the system
“Human-in-the-loop” refers to the situation when you can have a human complete some tasks to improve a user experience or to figure out something that is too difficult for the system. Designing this as part of your system will be useful for doing work or validating parts of a process that the system can’t do well yet. And the actions that the human takes can feed back into the system to train it to do the task better for itself in the future. Many companies building AI products use a human-in-the-loop to jump in and do some sort of work as part of their back-end workflows.

Use all the context you can get

Context adds intelligence (or at least the appearance of intelligence)
We’re collecting more contextual data than ever, and this context information will be needed for better AI-driven systems across a wide spectrum of industries. For many systems that interact with humans, context will be king. The abilities of intelligent agents will be expanded or constrained based on how much contextual data (location, related data, personalized information, etc.)

Detect failure (create complex/emergent failure detection)

Emergent systems require real-time performance evaluation
As we develop systems that operate dynamically, we’ll also need to rethink Q&A. There is more work to be done here, but we will need models for real-time error detection so that we can fail gracefully or have the system jump into another path of action. One way this could be done would be similar to how humans do it — by getting feedback from an independent observer. I’m talking about an application that constantly observes the production system and looks for abnormal or inaccurate behavior. Once it detects this type of behavior, it would give feedback to the main/production system so it can adjust its actions. This functions like a real-time performance evaluation, except it would be entirely digital. I imagine that this application could look similar to virus or spam detection software, where applications can look for a fuzzy determination of “normal” versus “abnormal” behavior.

Create smart failover reactions

Expect the unexpected
Humans are unpredictable, and combining unpredictable humans with unpredictable machines exacerbates the issue. Plan for smart failover experiences that can ask for clarity or clearly communicate confusion to the user. Plan ahead so that the user won’t get confused by the dynamic nature of the system.

Collect and maintain trainable, quality data

Use interactive systems to collect good data interactively
When designing inputs to the system via any interface, think about how you can check for the quality and trainability of the data you are collecting. If you are designing an intelligent agent, you can ask the user clarifying questions in real-time. If not, you can still build techniques to ensure data quality upon input. There may also be old datasets that could be used to get started with a new customer. Quality will be a factor here, as well. Old data sets may not be well maintained and may need to be cleaned up.

Create an data/AI flywheel

Data from users can make the system more valuable, which can help you obtain more users and data, which can, in turn, make the system even more valuable
With AI-driven products, information can be collected from all the users on the system (and other systems) to make the system smarter, which in turn makes the system more valuable and attracts more users. When you attract more users, data can be collected from them that can feed into the software, and so on. This creates a flywheel of data collection and an increasingly intelligent system that builds upon itself. This is a way to create unique value over time, and it makes it difficult for competitors to catch up as the cycle creates its own momentum.

Create value for the user ASAP

Give value while collecting data
Balance the collection of data from the user with something that’s beneficial for the user. The ideal scenario is to provide value while you are learning. Also, if possible, find value in old data that can be loaded into the system through integrations with other systems. It’s good to plan for all the great things you can do with data collected in the future, but you have to offer some immediate value so that people stick around.

The cold-start problem

Starting from zero is tough
If your AI product doesn’t start with useful data for the user, you’re in a tough spot. If you need to train using user data to make the product usable, then you’ll need to consider how you can get some proxy data to start with so that the experience is good from the start. Or, integrate to other products the user uses in order to get that data.

When creating chatbots, trust and knowledge must be built via interactions

If you are building an intelligent agent, the onboarding never ends
When it comes to intelligent agents, the initial proactive experiences the users have with the agent, combined with subsequent interactions, will drive how the user can and will use the agent long-term. So smart onboarding (introduction to the agent) and ongoing education of the user is key. Humans develop familiarity with others through repeated interactions over time. This is how humans will also interact with intelligent agents. If the user and agent haven’t communicated in a while, then the human may even forget about the agent altogether. Also, it’s important to think about how the user will discover what the agent can do. The agent may need to send reminders of new skills it has acquired or even simply provide a visual menu of what it can do. The important thing is to think about how all the capabilities will be presented to the user so that the user understands what the agent can do and remembers the agent. The proactive nature of these communications will drive the usage and user expectations needed to get to the other things on this list.

The hybrid/ multimodal interface

In the long-term, I predict that intelligent agents will communicate better with humans than humans communicate among themselves
That’s because intelligent agents will have a wider variety of communication methods and input options than humans do. The best path for chat-based or other visual user experiences will usually not be to create a totally text-driven experience. An interface that contains both text elements and visual elements (buttons, images, etc.) is what we call a multimodal interface and will allow a wide array of input and output options that can be used in the right context to communicate most efficiently. Artful communication with the user is needed to ensure collection of good information that can make the interaction more useful to the user.

Note: I’ve called this a “hybid” interface in the past to mean that I’d like to support both multimodal inputs/outputs like images and sound - but also additional helpful elements like buttons and user prompts in the chat interface.

New interfaces needed

AI will be everywhere
A few years ago, I wasn’t sure if some people knew that a chatbot didn’t imply that AI was at work. The concepts of “chatbot” and “AI” seemed to somehow become interchangeable at times.

I’d just like to say that when approaching new AI/ML and GenAI projects, I think we should start fresh. Start with user and work backward. Don’t lock yourself into building a bunch of chat interfaces unless that’s what is really needed.

I like dashboards and non-chat interfaces. But, I won’t cover my thought process around choosing what to use here. Also, I’d like to see some innovation in UX. Maybe start with a blank slate and try some new things. I’m seeing too many people lock in on the answer before they’ve thought about it.

These “agent” ideas are not just for chatbot interfaces. When you’re building something like a GenAI ad optimizer (for example) to create a set of ads via GenAI, a lot of this still applies. You’ll still want to gather context, define success, maybe change dynamically shat success means, create random sets of ad outputs within parameters, collect success metrics, and repeat. And, the interface could go in a lot of directions. Don’t lock yourself in.

Non-probabilistic components

Sometimes you need determinism
Sometimes precision is needed, so you can create a product where only part of your product is probabilistic. Maybe for communication or for analysis you can have a layer of your product that uses GenAI. But, the GenAI accesses a database of facts that you don’t want to get creative with. And, that information is outside of the LLM’s inference and wouldn’t be changed before giving it to the user. This would include things that are math or metric based, financial data, text answers that need precision, and lots of other use cases that need a solid factbase. Sometimes the fuzzy nature of GenAI/LLMs aren’t needed everywhere. This is what is exciting about Retrieval-Augmented Generation (RAG).

In closing

My thoughts on this are taken from real-world building, but its also still a bit nascent. That is, I don’t know everything and am still figuring it all out. And, I’ve intentionally left out some things I want to explore before talking about them.

This new wave of GenAI will help scale system automation in businesses. Effective design requires new thinking. As we progress, the discussion will continue. I’m glad to chat with fellow builders on this design challenge. I think many of the above items will get built into future GenAI toolkit apps. As agents take over more work and also collaborate with each other, their design becomes more powerful and important. “Probabilistic products” will be the category of product design and product management that will need more focus so we can build them right.

Additional Notes:

I’ve written some associated posts related to probabilistic product management in the past:

Transitioning to the Intelligent Automation Age

The 10 Principles of Intelligent Agent Design

12 tips for designing and managing an AI-driven product

Managing Future Digital Employees

Additional note: What this post is not about

When I use the terms “Probabilistic Product” and “Probabilistic Product Design,” I do not mean several things that use the same terms.

I am referring to the newly emerging field of product managers building use cases and experiences on top of probabilistic computing capabilities.

I am not referring to a mathematical product. The concept of a “probabilistic product” has different meanings depending on the context, but it generally involves the multiplication or combination of probabilities or probability distributions.

I am not referring specifically to “Probabilistic product design” as a path for designing things. As in — an approach that incorporates probabilistic methods to handle uncertainty and variability in the design process.

I’m Will Murphy, the creator of the concept of the probabilistic product/ probabilistic product design. I live in Silicon Valley and build things for fun and profit.

Subscribe now