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

1. 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.

2. 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.

3. 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.

4. Write lead sheets, not scores. Build prototypes and question big specs. Favor building over process.

5. 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.

6. 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

1. 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.

2. 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.

3. 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).

4. 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.

5. 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.

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