TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier
I’ll be chatting with Birkan Icacan from Enterpret today (Thursday, April 9, 9:00 AM - 9:45 AM PDT) about “Why Product Teams Struggle Despite More Customer Feedback”. Should be fun! The topic actually (loosely) relates to today’s post. I have also been working lately on a new playbook. Beware…it is about words, so not everyone’s cup of tea.
Orgs spend a lot of time talking about dependencies, intake, predictability, “discovery,” capacity, and so on. But far less time talking about the harder questions around the demand mix teams are dealing with, and how they are actively involved in shaping that demand.
What I want to do in this post is cover some of the basics of demand mix, context, and how those two things actually determine how teams operate and what “good” looks like. Then, after walking through those principles, I’ll share some thoughts on how AI is starting to change the picture.
The key point is that without a discussion of demand mix and the activities involved with shaping and filtering demand—getting into the real specifics—it is very hard to have a real discussion about how you operate.
The Demand Funnel (A Helpful Simplification)
A dominant mental model of product development looks like this:
There is effectively a “funnel” that all sorts of stuff gets dumped into, filtered, assessed, and eventually that work produces change, which then feeds back into the funnel.
Both (1) the makeup of what is in the funnel and (2) how it is filtered, shaped, and influenced can vary dramatically across teams and companies.
At one end, you have support teams waking up each day to a fresh batch of inputs. The team is almost stateless, aside from the decisions that shaped what landed in their queue.
At the other end, you have product teams that largely source their own inputs through customer interaction, guided by high-level company goals, constrained by decisions made years ago about their mandate, and shaped by incentives tied to relatively stable metrics.
And then there is everything in between.
So you have:
The mix of stuff in the funnel. Where it came from, who is involved, and what “it” is, for example support tickets, internal requests, production fires, or strategic goals. The composition of the funnel matters, and the variations are massive, even within a single organization.
How that flow is shaped. How the team, and others, actively shape what moves through. One team might be prototyping, testing with customers, and constantly shaping or discarding ideas. Another might have almost no involvement until a late-stage feasibility check. And again, everything in between (even inside a single org).
Mix and Approach
Mix and approach are obviously related. You have to adapt your approach based on the mix (or try to change the mix).
For example, when a team is fed by a high volume of interrupts coming from across the organization, it tends to rely on structured intake, prioritization forums, economic trade-offs, and planning cadences to manage the chaos.
In contrast, when a team sources most of its own demand through discovery and strategy, the approach shifts toward shaping the funnel upstream through continuous learning, selective intake, and ongoing refinement.
In both cases, the practices can be sound, but they are responding to very different input conditions, and those conditions ultimately shape how the team operates.
No Team Is An Island
Of course, no team exists completely on an island.
In the leftmost example you might see teams tightly coupled through shared interrupts, constant cross-team dependencies, and work being reshaped as it flows between groups.
In the rightmost example you are more likely to see teams loosely coupled around shared priorities, where strategic alignment happens upstream and each team shapes and executes against its own coherent stream of work.
On the left, you’re lucky to get teams focused and coordinated, let alone figuring out if what you are doing is actually working. On the right, teams are able to stay aligned around clear priorities, operate with focus, and continuously learn from what they’re doing, making it much easier to see what is actually working and adjust accordingly.
Demand and Prioritization
Building on my piece on the four prioritization jobs, the mix of demand and the activities used to shape that demand will have a huge impact on how people prioritize and why they prioritize. Those four jobs, efficiency, leverage and effectiveness, alignment and autonomy, and support and commitment, show up very differently depending on what is feeding the funnel.
For example, in a high-interrupt environment like Org A, prioritization discussions are often dominated by efficiency and support. Teams are trying to reduce noise, survive the volume, and negotiate commitments they may not even be resourced to handle.
In contrast, in Org B, where demand is largely self-shaped, prioritization leans much more heavily into leverage and alignment. The conversation shifts toward which bets matter most, how they connect to strategy, and how teams can make confident local decisions without constant escalation.
Demand and Mandate Levels
This is also where my idea of mandate levels becomes very concrete.
In the diagram, all of these levels are active at once, from “build exactly this” at the top to generating long-term business outcomes at the bottom, with different parts of the organization operating at different altitudes and connected to one another.
What is a bit counterintuitive is how each side feels. The left side can appear deceptively simple. Work shows up pre-shaped, teams are given things to build, and the flow looks straightforward on the surface. The right side, in contrast, can feel messier. There are experiments, drivers, inputs, feedback loops, and more visible iteration across levels.
But underneath that perception, the shape of demand and the activities used to shape it are very different.
On the left, the apparent simplicity is driven by pushing complexity “downstream” and outward, into fragmented inputs, hidden dependencies, and pre-shaped work that obscures outcomes.
On the right, the messiness comes from engaging with that complexity directly, linking levels together, and actively shaping demand through discovery, experimentation, and alignment. So while one looks clean and the other looks busy, they are responding to fundamentally different mixes of demand, and that difference determines how teams can operate across the mandate levels.
Controlled Intake vs. Distributed Chaos
(Note, we’re shifting org examples here.)
Why is any of this important? When we talk about “discovery,” capacity, “shaping,” throughput, etc., it is critical to understand the context.
I know a highly effective product owner (their org is very much a Scrum shop). He runs what he calls an “efficient feature factory.” “I wish it was different, but that is what we do here.”
What does that mean?
The team does very extensive requirements discovery based on all the requests coming in
They put back-pressure on requests, deliver often, are “predictable,” and can generally forecast, within a confidence range, when things will be finished
They went from being perpetually overwhelmed, with everyone saying the team was untrustworthy, to having all of their internal stakeholders “love” the team
He figured out how to get stakeholders in a room periodically and essentially run a rigorous auction on their “capacity”
“Look, at least compared to my last job, this produces reasonably usable software. We ship often, we limit our WIP, we understand requirements, and people aren’t bad-mouthing the team.”
Now contrast this with a PM from a theoretically “empowered product company” whose leaders frequently show up on popular product podcasts:
Honestly, it is a shit show. Empowered here means we are basically empowered to negotiate with dozens of teams across massively competing priorities, everyone with their own agenda. No one wants to face how hard it is to get things done, and none of the VPs want to let their precious budget go to any other group.
We have teams flying high because they are doing something AI-related, and they go around the company basically commanding other people to help them. Meanwhile, the teams working on the actual guts and infrastructure of the org, the stuff that everyone relies on, are having to beg, beg for headcount.
Everyone is terrified about layoffs, but what we really need to do is start doing more top-down prioritization and make hard decisions. Maybe we need to re-org, but probably right now we need to be doing like 50% less, as unpalatable as that sounds. When anyone says that, the answer is, ‘but you’re empowered!’
Putting these examples together, the mix of demand and the way it is shaped fundamentally determine how teams operate, what practices make sense, and even what “good” looks like in a given context.
For the feature factory, “good” means control, predictability, and earning trust by reliably handling a high volume of incoming work. For the more “empowered” but fragmented environment, “good” is supposed to mean choosing the right bets and owning outcomes, but often devolves into fragmentation, negotiation, and heroics when the mix and shaping activities aren’t aligned.
Who is actually empowered?
Who gets rewarded in both environments?
The Story of Everyday Actions
Whether you are talking about “dual-track Agile,” “continuous discovery,” “requirements gathering,” straight-up research, or anything in between, it is a pretty useless discussion unless you understand the context: the demand mix, the mandate levels, the nature of the work, the risks involved, and how all of that actually shows up day to day.
The real story of demand is not explained by a theoretical SDLC. It is the story of everyday work. Everyday activities. Everyday tickets, docs, goals, and requests.
Where did this come from?
What shaped it before it got here?
What did you actually do with it?
How did you get from that goal or priority to this thing right here?
How much of your roadmap do you actually control?
How much is handed to you?
How are you self-sourcing opportunities?
There is never an excuse for too much WIP or overloading a team. Sometimes that is self-inflicted, but often it is a mix of self-inflicted and organizationally inflicted. In theory, you can say no. In practice, when work is coming at you from all sides, that is often not a real option.
If a week before quarterly planning the wind suddenly shifts and there is a new hot priority, and your team of five is already tackling 15 things, you are likely going to add item number 16, and bump it up, unless you have built a significant amount of influence in the organization.,
The important point is that even very strong teams, with a clear understanding of their demand mix and taking contextually appropriate actions to manage it, can get pushed over the edge when the organization drifts into chaos and there are no enabling constraints. Meanwhile, with the right support, a “normal” team can operate sustainably.
Critically, how you tame WIP, how you approach discovery, and how you manage demand is, I repeat, contextual. There are no one-size-fits-all approaches.
Some AI Thoughts
Are you shipping faster than you learn, or learning faster than you ship? I think a lot of companies believe they were learning faster than they could ship, and now see AI as an insta-fix.
The Ingrained Mental Model
There is a deeply ingrained mental model in product development that looks something like this: ideas flow through a funnel, get refined, and eventually land with a scarce engineering team that turns them into reality. That team is treated as the bottleneck, the point of constraint, the place where all upstream effort is justified. The entire system organizes itself around feeding that constraint as efficiently and predictably as possible.
It is a version of our funnel.
Once you believe that, a whole set of behaviors follows. Upstream work becomes about shaping and de-risking ideas before they ever reach engineering. Requirements get over-specified. Decisions get made early. Stakeholders negotiate intensely to secure their place in line. Work is packaged, defended, and handed off. The goal becomes to “get it right” before it hits the team, because the cost of being wrong is assumed to be too high once it does.
This is where many of the familiar pathologies emerge. Premature convergence replaces learning. Performative certainty replaces curiosity. Large batches of pre-shaped work move through the system, giving the illusion of progress while obscuring whether any of it will actually work. Much of the effort shifts away from understanding customers and toward managing internal dynamics, competing priorities, and access to scarce capacity.
In that world, the funnel is not really about producing meaningful change for customers. It is about allocating a constrained resource. The system’s output is not learning but decisions that have already been made, often far removed from real feedback. Engineering becomes the receiver of these decisions, rather than an active participant in shaping what should exist in the first place.
An Alternate Mental Model
There is a different way to think about the funnel.
Instead of ending at a team, it ends at meaningful change for customers. The purpose of everything upstream is not to perfectly specify work, but to learn what is worth doing. Work is shaped continuously, not front-loaded. Decisions remain flexible longer. Teams are not just executing against a queue; they are actively participating in discovery, shaping, and iteration.
In this alternative model, the constraint shifts. It is no longer engineering capacity in isolation. It is the system’s ability to learn, to focus, and to make coherent decisions across competing inputs. The funnel becomes less about filtering work down to a team and more about shaping and refining ideas as they move toward real-world impact.
Now Supercharged With AI
This is where AI enters the picture, and it is easy to misread what it changes. If you are operating in the first model, where engineering is treated as the bottleneck, AI looks like a breakthrough. If we can generate code faster, prototype faster, and ship faster, then surely the constraint has been lifted.
If you keep the same mental model, AI will not clean anything up. It will accelerate the dynamics you already have. More ideas will be generated. More work will be shaped upstream. More artifacts will be produced. More things will enter the funnel. The negotiation does not go away. The theatrics do not go away. The overload does not go away. It all speeds up.
The vibe-coded prototypes, vibe-written PRDs, and faster requirements do not solve the problem. They just replace the old rituals of documentation and premature convergence with new, higher-velocity versions of the same thing.
On the other hand, if you shift the model, AI becomes something very different. It becomes a tool for accelerating learning rather than feeding a bottleneck. It helps teams explore more options, test ideas faster, and surface connections that would otherwise be too costly to process. It reduces the cognitive burden of making sense of complex systems, allowing teams to focus on what actually matters.
The key point is that AI does not fix the funnel. It reveals and amplifies whatever version of the funnel you are already operating. If your system is oriented around managing scarcity and negotiating access to engineering, AI will make that system more intense. If your system is oriented toward learning and shaping demand toward meaningful outcomes, AI will make it more effective.
So the real question is not what AI enables in isolation. It is the version of the funnel you are running.
Questions
What is the funnel in your organization actually for? When you step back, what is it really optimizing for, and how intentionally has that been designed?
How would you describe the shape of demand your teams are dealing with today? Where does it come from, how does it take form, and how much agency do your teams have in shaping it?
When you observe how work moves through your system, what feels like learning, and what feels like negotiation or performance? How easy is it to tell the difference?
Where in your organization are decisions being made too early, and what would it look like to hold those decisions open longer?
If your teams suddenly had the ability to generate and explore far more ideas, what would actually change? What would improve, and what might quietly get worse?
What do you believe is truly scarce in your system today? Is it engineering capacity, or something less visible like focus, clarity, or the ability to make coherent decisions?
As AI becomes more embedded in your workflows, what existing behaviors or patterns might it reinforce? Which ones would you want it to challenge instead?
If you imagine your organization a year from now, with AI fully in play, what would need to be different about how demand is shaped, filtered, and acted on for that future to feel meaningfully better?
Here’s a fun little image from a team doing a bucketing exercise for their funnel/demand:
> The key point is that AI does not fix the funnel. It reveals and amplifies whatever version of the funnel you are already operating.
In some orgs I know, AI would definitely stand for "Amplified Insanity".
Great article, thanks!