In this video, Stacy Gordon sits down with John Greisner, a management consultant at LiminalArc, to explore why AI doesn’t remove your software delivery bottleneck so much as move it. Drawing on Goldratt’s theory of constraints from The Goal, John walks through what happens once engineering gets fast and cheap: the real slow point shifts to product management, funding cadence, and how much change your customers can actually absorb.

Stacy and John dig into why flooding your backlog with every new idea only makes that constraint worse, and why deciding better, smaller, and more often works instead. Watch so you can stop chasing engineering speed as the finish line, start treating decision capacity as your real constraint, and finally get the return on AI adoption that an operating model built for a slower era has been quietly blocking.

Video Transcript

John Greisner

AI is definitely an enabler to help build things more efficiently and faster and to automate the things that were often manual. And so the engineering work has gotten fast enough and more efficient in reducing costs that it’s kind of prompting a whole new set of questions. Where is the constraint in the system? Where is the weakest link? We are now looking at other areas that are slower than the build cycle that we’ve been trying to follow from engineering to the front end. Once you sell the front end, really then the question is how much could our customers even consume and be able to take to make it effective that they’re going to love our products?

Stacy Gordon

I’m Stacy Gordon, and every week I pull up a chair with someone willing to talk about all the unglamorous stuff that is really behind why the thing actually works or doesn’t. My guest today is John Greisner, a management consultant with Luminal Arc. John published an article titled The Bottleneck Moved: Your Operating Model Hasn’t. And it’s one of those articles that honestly I had to read many times. But at the end, John, your takeaways were simple, but extremely powerful. I’m very excited that you’re on the podcast with me today. Welcome.

John Greisner

Thank you, Stacy, for having me. I appreciate the opportunity to share a little bit more. It was kind of a fun write for me for several reasons, but I do love the story from the book The Goal and it’s one of those pieces of work that’s been around for many years. Companies like Amazon and Tesla through Elon Musk and Jeff Bezos are always kind of promoting the reading because it really teaches a lot of fundamentals about building things. And in our world, mostly we’re talking about building software, but it does teach us the very important lessons about where is the constraint in the system, where is the weakest link? And so the story of the hiking is one of those examples that’s in the book. And I can share my own hiking story. I took a whole group of nephews and nieces and friends out a couple summers ago and I had to live through the story myself.

And it was kind of funny because in the back of my mind, I am thinking about the book the goal and the hiking. And so we started off and the younger guys, they’re just sprinting up the hill and we’re all trying to keep pace. And there was a few of us, me included, that probably hadn’t hit the gym enough and we were kind of huffing. And so we ended up getting spread out. And so we all wanted to stay together and be able to get there at the same time. So the plan was is that I would go first. I would set the pace and I was setting the pace based on generally who was the slowest and that’s how we all kind of stayed together. So that’s my little story and I’m sure you all have similar stories that you can relate to.

Stacy Gordon

Oh my gosh. Well, I love it when something in your real life actually ties back to things that you experience in your professional career. It always makes it more real for me. You’re actually making me want to go read the book. So I’ll have to put that on my list. But one of the things, you have a line in your article that says Goldrat’s rule has two halves and the second half is that a constraint you elevate does not disappear. It moves and it rarely announces its new address. I really loved how you phrased that. So basically your argument is that most companies finally fixed their old slow spot. They found Herbie, they fixed building software, but they didn’t realize that a new slow spot was going to take its place. When did you start seeing this?

John Greisner

Yeah. So I mean obviously in delivering on a lot of the AI work that we’ve been doing over the last couple years, AI is definitely an enabler to help build things more efficiently and faster and to automate the things that were often manual. And so what we’ve started seeing in a few of our clients that we’ve been working with through this phase is that the engineering work has gotten fast enough and more efficient in reducing costs that it’s kind of prompting a whole new set of questions. And so it’s really a statement about yeah, it’s a tremendous accomplishment for a lot of the companies that have spent decades to focus in on adding agile practices, DevOps, cloud migrations and all the different capabilities to make that engine DevOps as well to really make it work more efficient and faster and cheaper. Even breaking down work, like I said, between 90 days of strategy, all of that helps get worked through.

But what it does is when it’s done is to the point of the book, the constraint moves. And the question that I’m posing is where does it move and what’s next?

Stacy Gordon

And so do you find, this is relatively a new concept, right? AI is changing on a regular basis. You hear customers constantly trying to figure out how they use it to develop faster. So do people even realize that they’re solving this problem, the engine of building software was always slow. Have they even really grasped the fact that they are kind of moving their bottleneck somewhere else? Do they recognize that that’s what it is that’s happening to them?That’s

John Greisner

A funny question because when I started reflecting on this this spring after seeing it, it actually took me by surprise because like I said, we’ve been working this problem for decades in this very specific area of our overall strategy to deliver customer value. And so it kind of became that epiphany moment to be like, oh my God, we are now looking at other areas that are slower than the build cycle that we’ve been trying to follow. So this is another reason why I wanted to write the articles because I love being aware of what’s coming and it even took me by surprise because the short time it took to really implement the full benefits is why.

Stacy Gordon

Well, I bet it’s a fascinating conversation to have with executives at companies because again, I’m sure they’re having that same aha moment that it’s taking them by surprise now that they’re sitting here kind of faced with different challenges. So you talked a lot about a company’s operating model, the wiring that turns strategy into things customers actually get was built for a problem that no longer exists. In plain terms, what do you mean by that and why is that kind of what I believe is probably the real headline here?

John Greisner

Yeah. So I mean the operating model, all the components kind of stay the same. So what we’re essentially doing when we’re implementing AI is we’re kind of adding almost like a race car engine to the process. And the way that I kind of think about that a little bit and the effects of that is that if you have your operating model and it’s not quite kind of wired to some of the points that I said earlier, like you don’t really have your DevOps kind of squared away, your practices and synchronizations are a little bit off and not really flowing, you add that bigger engine and it’s like putting it in an old car with a bad front end and you’re going to go off the road a whole lot faster. And so that is some of the things we’re hearing too. They’re like things are getting crazy and we’re discovering a lot more things.

So it amplifies all the operating model components. And so there are different pieces of it that start to need to be tailored a little bit more for that faster engine.

Stacy Gordon

Okay. I loved that description of the old engine with the bad front end and running off the road because I’m sure that that’s what people are feeling like right now. They’re like going, “We’ve solved a problem that we’ve been trying to solve. We’re now going super fast. We’re going to win the race. We’re going to win the competitive race,” but yet they’re not starting to see or they’re not feeling like they’re accomplishing what they though they would by being able to develop and do things faster. If you look at all the wiring that’s in someone’s organization, so all the different pieces of the operating model, help me understand how do decisions get made? How often do you plan? Who owns what? Which roles matter? Which one of those kind of gets out of date the fastest, right? So we’re turning our lens to look at the different parts of the business.

So which one of those do companies need to start looking at?

John Greisner

It’s really who’s been impacted the most in this change is the product manager. One that is getting the feedback from the engineers and the one that’s responsible for providing the highest value of work. They’re being asked more frequently. So the change in which if you think about a team that maybe might do two week sprints, the product manager is trying to build up that backlog. We tend to like to have a little healthy backlog of like two to three sprints out so there’s clarity on the team and what they’re going to be doing. That gets consumed really fast if you have a high speed engine in there. And so that puts a lot of burden on the product manager to keep that backlog healthy as well as validating did they build the right thing? Is it fit for purpose? And being able to. So it’s really putting a lot of strain and stress on that one person and that’s kind of the biggest impact.

How do they then navigate this new world that they’re living in?

Stacy Gordon

Yeah. I think that’s interesting because I think one of the concepts that you had in my plain language is that if ideas are cheap or free, why not build them all? Why does throwing more ideas at the problem actually make things worse? And so this is really, I think, what you’re describing for that product owner of going, he’s got people coming in from every direction giving him all these new ideas and he’s got this really fast engine of being able to build them, but that doesn’t necessarily mean that you should just because you could.

John Greisner

That’s right. And I think that’s the hazard or the impulse is just fill that backlog as fast as you can for them. And that puts a lot of stress on the back end of it, which is the customer receiving things they really don’t need and the change impact to that. So it really takes that discipline, which we have been talking about for many years too, to understand what’s the highest priority and being really spot on. And so it’s that decision that is first and foremost on the spotlight now. It’s like make clear decisions on what the customer needs and being able to prioritize that.

Stacy Gordon

So you believe that a company can actually get better at that. That is something that if they have the right guidance or the right framework or the right research, what is it that a company can do to kind of make more informed decisions about which ideas are worth investing in and which ideas aren’t?

John Greisner

Well, and AI, just like with engineering, is a great companion to help those discussions, but it still, at the end of the day, takes a human to be able to make that judgment call on what’s the most important business problem to solve, what capabilities need improving and to be able to do that. But they do have a helper too to kind of go through and vet ideas, but the cost of delay scenario that I mentioned in the article is a little bit different than the way it’s traditioned because we’ve often looked at how much effort someone takes over value. And now with effort being low, we’re really focused on highest value and what that means to our customers. So the disciplines are there. I mean, different companies excel in that space a little bit more than others, I would say, to the point of if your capabilities and skills aren’t there, this is going to amplify and make it clearer.

So if companies are still struggling with product management and how it should work and connect to strategy, you’re going to feel this pain much more and more faster essentially.

Stacy Gordon

Well, one of the things I thought was so interesting or the claims from your article is that it talked about the real slow point actually may be outside your company entirely. Customers can only, and I love this word, absorb so much change. So how did you actually land on that?

John Greisner

Well, so it’s really the full circle. So in just thinking about if we trace this constraint, if you will, from engineering to the front end, once you sell the front end, really then the question is how much could our customers even consume? And we’ve all been victims to too much change and the change fatigue we feel in some of the products that we use and how rapidly. So it is a real problem and a challenge that companies are now going to have to really wait and take a look at. We didn’t have this problem so much because we often couldn’t keep up with what the customer needed.

Stacy Gordon

So

John Greisner

That wasn’t the problem space, but now we do have to really weigh how much can the customer consume and be able to take to make it effective that they’re going to love our products. So we are now dealing with really two different areas that are highlighted now because of the faster engine.

Stacy Gordon

Yeah. I do wonder, again, I think the pattern within your article talks about, again, having to look at different areas of the organization under different lenses. And so I can only imagine the heightened effort that an organization will have to put on customer research of being able to go, okay, we’re going to really have to measure the changes that we’re making to start getting that real powerful feedback fast so that we are kind of meeting the pace that they’re interested in. Not going too fast, but also not going too slow.

John Greisner

Yeah. I love what you’re saying about measurements because we focus so much on engineering measurements to make sure that engine is running smoothly and is efficient. And we haven’t so much on the front end and back end because that wasn’t our constraint, that wasn’t our problem. But now that those are becoming first class rights to focus on, we have to think about what are the metrics that we want to kind of measure to make sure that we’re not causing or slowing the whole system down. So the question on ideation becomes really a powerful area that we’re going to have to look at and see how long does it take to iterate through our ideas and connect the strategy? Because if it takes us the same amount of time, which was very forgiving in the because we were waiting always on the engineering side to finish the work, God bless them for all the hard work that they have to go through.

So we had slack in the system to be able to deal with this problem. Now the slack is being taken away, so we have to really manage and measure that side as well as like you said, the customer side too, how much could they consume?

Stacy Gordon

Well, and I think it’s probably something that they didn’t even realize that it’s like, I’m sure nobody really had a foundational measurement for how long it took to go from ideas to getting them vetted and put them in the backlog, right? They were just constantly complaining that their ideas never made it out fast enough. So I think the change that organizations are going through is in such real time evaluation of all of their different parts of their organization that they probably, when we talk about that bottleneck or that constraint moves, is it always the product person that they go to first or is it even if the product person gets something, is there more of a revenue officer that might have it sitting on their desk? I mean, I’m assuming an organization may have to look across the board to see who’s slowing the process down.

John Greisner

Well, it’s all interconnected on the front end and even starting to signal, and I mentioned it briefly in this article and there’s another article that’s going to come out in talking about the portfolio side of it with funding. And so when we talk about how often do we fund ideas in this new world of going from ideation to delivery much faster, that feedback loop into how we fund and how we allocate across all the capabilities is also going to connect to that. So the front end is all interconnected. And so what the product manager will need is ability to flex much more faster than the system was willing to do before. Well,

Stacy Gordon

On the finance end, I do think that’s interesting because I think traditionally you get a bucket of money, you build out a roadmap, you align budget items to each one of those things. So maybe that’s where you’re getting that flexibility on the product owner to go, from finance and them managing their P&L, you can’t really look at it the way that you used to do on your roadmap. Okay, I’ve got $100. I’m going to $25 in first quarter for this feature and $25 in second quarter for this feature. I mean, you have to be able to change and move faster about even your overall thinking about budgeting.

John Greisner

Yeah. And like I said, some companies have narrowed the focus to look at budgeting more frequently. Some do it on quarterly. Some are still locked into the annual. And so for those that are still locked in, then there’s going to be definitely a system constraint or a barrier to be able to move faster because it’s tied to something that isn’t, I’ll call it cadenced or synchronized. And that’s something also that I mentioned about one of the changes is that you have to reevaluate your cadences based on your placement of that and the frequency you need to make that decision. And funding is one of those that it does get impacted if you’re able to produce more quickly.

Stacy Gordon

So ultimately, if you kind of step back and you start to look at the entire organization, I mean, ultimately this could mean full organizational transformation unless you just want to tackle one small little thing and then figure out where the bottleneck moves. It potentially says, “Hey, for the best of the best companies out there who recognize they’ve solved this 20 year problem of software development that they’ve had, they really should probably look at the organization over as a whole and start really using those different lenses to kind of identify perhaps for them specifically what their problems are.” But organizational management change and transformation has always been slow and painful and can cost a lot of money. So in your mind, how long is this really going to take for a company to be successful and where do they maybe start or where do they maybe get stuck?

John Greisner

Well, so I think looking at the fundamental question is where is their slowest part is where they should start. And so different companies are in different places in adopting AI, but the cautionary tale is a little bit like if your system isn’t set up to handle a faster engine, you probably have some work to do still in the area of the build to be able to apply it. And so like I said, it’s going to amplify a lot of the outer boundaries and even the things within delivery, it’s going to amplify. So back to the car metaphor, it’s going to steer you off the road very quickly. So I hate to say it depends like the consulting answer, but it depends on where you’re at, where your problems are. But as people are kind of trying to gravel with adopting AI, they’re running their pilots, they’re trying this out, and there are definitely some challenges they’re starting to see.

And I think the challenge is really putting the spotlight on their operating model. And it’s a good thing to try to advance and companies are looking to use it, it is going to highlight deficiencies or other areas that need to be fixed. So transformation is a loose word, but just implementing AI like, “Hey, if we just do these couple things and we set up the AI environment, we’re good.” It definitely impacts a lot more than just the capability itself. So to your point, it’s a wider change that you need to think about and strategize around.

Stacy Gordon

Well, that’s what I thought was interesting about your article too, your example leader, Alex. He doesn’t fix everything. He just starts because sometimes analysis by paralysis. And so if someone were to take a first step, what would you recommend they do?

John Greisner

Yeah. So I think a great question first and kind of lead into when we think about transformations, limital arc, we do like to think about it as a slice, one particular area. And so you can continue to develop the capabilities and understanding and competencies around AI, running some pilots, looking at it, but really look at one slice for your organization and see how you would implement it and the changes you would make and then be able to kind of scale that out. So take more of a pointed view on, yes, fixing the one problem, but in more of an isolated area until you understand the impact and change to the overall area.

Stacy Gordon

I loved the takeaways. I mentioned this up at the top of the interview, that I felt like I walked away with three really simple items from your article that made a lot of sense to me. And so I want to make sure people hear these and walk away with them as well. So it basically says your bottleneck moves. When delivery becomes fast and cheap and is no longer the bottleneck, the bottleneck will find a new address and you need to figure where that is before optimizing anything else. Number two, upstream. The scarcity is decision capacity, not ideas. Feeding the funnel faster makes the bottleneck worse. Deciding better, smaller, and more often makes it work. And finally downstream, the customer sets the pace. What they can absorb, not the capacity, is the final constraint. So build the cadence that senses it. Anything else that we’re missing from those three things?

I think they’re simple but powerful in ways that leaders in their companies really need to look at AI, how they’re using it and how they’re going to be competitive in their landscape.

John Greisner

Yeah. I mean, the important thing is start where you’re at, but understand where it’s going too. That’s the important thing. As you do start to resolve and implement some of these benefits, you will need to start looking more at the pace of the customer. You will need to address the front end frequencies, the funding models. And so yeah, but start exactly where you’re at, just keep moving. And if you have more work to do in the build area, that’s the place to spend it. You can definitely start to take advantage and have AI and some of the agents and skills help you through that process. So there’s some great ways to leverage to get you to a full implementation. So

Stacy Gordon

John, one of the things that I always like to ask is if we had a product owner, for example, listening to our conversation and you were going to recommend him one thing to do on Monday when he went into work that he could impact or change based on what we’ve been talking about, what would it be?

John Greisner

Yeah, I think the first fundamental is what we’ve talked about with cadence and placement. And so the one company that we’ve been working with for a while, one of the things that the product manager quickly did was as the team changed from more of a scrum base to a flow base because time boxing in that sense didn’t make as much sense with the synchronization, it was about placement of those decisions. So understanding what are the decisions you’re making upstream and downstream and then repositioning the cadences around that. And so that will help smooth out what they need to do and keep things going to help kind of flow the work through.

Stacy Gordon

Sure. Well, I think that one big takeaway for me is if people aren’t open to change, they’re in big trouble because I think we all have to look about how we change from a very personal level and how we do work and productivity to an organizational level and at a competitive level and things like that. So I definitely think people better be ready for change for sure.

John Greisner

And there’s a little bit more summer left for your summer reading, and if you haven’t had a chance, you can first read the article, but also read the book the goal that this is based on.

Stacy Gordon

I mean, listen, John, we cannot put too much on my reading to-do list. Let’s be clear. I mean, I’m a girl of $2 words. We talk about it all the time, but I felt like it was very interesting. I’m going to put it at the top of the list, which I have two books on it. So I think we’ll definitely be able to get there. So now I’m going to turn it back to you now that I’ve told the whole world about my maximum two book reading list. I always like to ask my guests two questions. I am a big energy drink fan, and so I’d like to know from my guests, what’s your energy drink of choice and why?

John Greisner

I’m going to throw you off a little bit. It’s probably water.

Stacy Gordon

Water. Oh my gosh. And the answer I never thought I would get, water. Okay.

John Greisner

And maybe at best Gatorade. So that’s my-You’re not

Stacy Gordon

Even

John Greisner

A coffee drinker? I drink too much coffee in the morning, so I have to make sure I stay hydrated in the afternoon.

Stacy Gordon

Oh, another healthy guy. I love it. Okay. I will just on the side stick to drinking the bad energy drinks. Okay. Now the real question, this is my favorite. If you were invited to pick a topic to present on at a conference, what’s a topic you would choose that would get you booed at the industry conference?

John Greisner

That AI adoption is easy.

Stacy Gordon

I mean, you definitely get some giggles for sure. Yeah,

John Greisner

Definitely.

Stacy Gordon

Especially since what’s the actual number, less than 20% of enterprise AI efforts are actually in production today. So I’m going to make sure I get a ticket to that conference for sure. Well, that is a wrap everybody on our topic today. The bottleneck moved, your operating model hasn’t. John, if listeners wanted to find this article or get in touch with you, how would they do that?

John Greisner

Yeah, you can go to the liminalarc.co website and under resources, you’ll find a series of blogs, and this is one of them to what Stacy mentioned. We do try to publish pretty regularly industry perspectives and helps as people are trying to gravel with some of this information. So definitely encourage you to sign up for it and take a read.

Stacy Gordon

Awesome. John, again, thank you so much and thanks to all of you who tuned in. If this made you side-eye your own company a little bit, good. That was the plan. Share our conversation with the one person who needs to hear it. Hit follow so our next conversation finds you, and I’ll catch you next time. Same chair, more caffeine and a new topic. Take care.

My last six posts made an argument: AI fails on conditions, not models; capabilities are the unit; AI has three jobs and one it can’t take; transform by slices, never all at once. The most common response I get is some version of: okay, I buy it. What do we actually do on Monday?

Fair question. Here’s what it looks like on the ground: the way we run it, and honestly, the way anyone should run it, including your own internal team. Steal the process. The stages matter more than who executes them, and each one is built to earn the trust the next one spends.

Stage One: Understand, Before Anyone Signs Anything

It starts with conversations, not contracts. The lay of the land: who the players are. Who owns what, who’s carrying the board pressure, who becomes the champion, who might feel threatened. What the goals and objectives actually are, in the sponsor’s own words. The known constraints: regulatory, technical, political, budgetary. Every enterprise has walls that don’t move, and pretending otherwise is how proposals get written that deals die on. And most important: what success looks like, in numbers somebody is willing to write down.

Underneath those questions we’re really testing two things from earlier in the series. Is there a real business problem with money attached, not a use case hunting for a justification? And does the fourth condition exist: is intent governed, is there a sponsor who can say what winning means and kill what isn’t working? If either answer is no, the honest move is to say so and stop. Trust required so far: none. Cost: conversations.

Stage Two: Align on One Room, One Frame

Next, a working session with the leadership and the people who’ll live with what follows. We walk the argument you’ve just read: why pilots die, the four conditions, capabilities versus applications, what AI is actually for, why slices. Not as a pitch, but as a working frame the room applies to their organization in real time.

Remember the warning about automating the artifacts, that the point of a story was never the story but the shared understanding? The workshop is that principle applied to strategy. The deliverable isn’t the deck; it’s collective cognition: a leadership team that can make consistent decisions about this work when nobody from the outside is in the room. The test of a good workshop is the same one I’ve seen convert career transformation leaders: everyone can locate their own work inside the frame. The output is concrete: shared language, and a chosen area of the business where the pain, the value, and the appetite line up.

Stage Three: Hypothesize Where We Think the Seams Are

In that chosen area, we form an extraction hypothesis: which capabilities we believe are trapped in which containers, where the value sits behind which seam. Notice the word. It’s a hypothesis: written down, specific, falsifiable. That’s what directed R&D means, and the next stage exists to test it. The code gets a vote.

Stage Four: Ingest Two to Three Weeks of Truth

Then the navigator goes to work. We ingest the code, and the data around it, and map what’s actually there: domains, subdomains, bounded contexts, the duplicates, the dependency knots. Machines do the archaeology at about 80% accuracy; experienced humans judge the rest. Months of discovery compressed into weeks.

What comes out is the value backlog: the inventory of value propositions worth solving. Each is scored on two axes, how much the slice is worth and how cleanly it cuts, then sequenced economically by weighing value and cost of delay against effort. We are hunting for a specific shape: high-value use cases that can be extracted in ninety-day increments. And it’s a living backlog: the first study seeds it, every delivered slice refreshes it, and the ranking moves as the work teaches us. Alongside it, an end-state picture: if every piece could move freely, this goes to the ERP you already own, this retires, this gets built custom because it’s how we win.

Three honest notes. The depth of the map flexes with the need: some problems can be pulled apart and monetized without a full architectural view, some estates demand the deep map first. The stages don’t change, the depth does. Sometimes the study says not here or not yet, and a few weeks of truth that prevents a multi-year mistake is one of the best purchases an enterprise can make. And notice where we still are: nobody has touched production. Everything to this point sits deliberately below the trust barrier.

Stage Five: Extract the First Ninety Days

Now we cut the seam: the top of the value backlog. Inside the slice, the four conditions get created for real: the capability encapsulated, the data validated at its source, one team that owns it, your people on that team from day one, and intent governed by the number we wrote down in stage one. The navigator maps, the junior engineers build under test-first supervision, humans judge. The slice goes to production. And then the only measurement that matters: the value we promised is the value we produced, in numbers your CFO accepts.

Then the loop turns. Slice two starts easier, because slice one left the conditions behind. Somewhere around slice three, the cadence should be yours, not ours. The goal was never a permanent engagement. The backlog has a bottom: we go only as far as there’s economic value to be achieved, and when the marginal slice stops paying, the work is done. What stays when we leave is a capability that was previously not possible for you.

One structural promise ties all five stages together: every stage is a gate. Stop after any of them and you keep everything of value: the map, the frame, the backlog, the proof. If a partner won’t structure the work that way, remember the tell from the last post: anyone proposing to transform everything before proving anything is asking for trust they haven’t earned.

The whole series was the whole story. This is the first slice. Buy the slice.

This is Part 7 of a seven-part series. Start wirh Part 1 here.

The argument so far, in one breath: your pilots work and don’t pay because they simulate conditions your enterprise doesn’t have; the conditions are four, and testable; the place you create them is a capability, not an application; and once created, AI has three real jobs and one it can never take. That leaves the question every executive actually gets paid to answer: how do you run this? Across a real enterprise, with a real board, on a real clock?

Here’s where transformations die a second death. Having accepted everything above, the organization does the instinctive thing: it tries to do it everywhere at once.

Horizontal Is Why Your Last Transformation Failed

You’ve seen the horizontal play. Pick a layer: a new governance model, a new team structure, a new engineering practice. Roll it across the whole organization. Train everyone. Announce the operating model. Measure adoption. We watched this fail for fifteen years in agile transformations, and you’ve watched it fail in ERP rollouts, Six Sigma programs, digital, and cloud. The failure has a signature: everything moves and nothing finishes. Every team is 20% transformed, no team is done, the old system and the new system run simultaneously everywhere, and eighteen months in, the sponsors quietly stop asking.

The alternative is vertical: pick one slice and install the whole system in it. Not one practice everywhere. Everything, somewhere. One capability, cut at its natural seam, with new structure, clean data, a new delivery model, lightweight governance, and AI inside the boundary, all the way to production. When I walk transformation leaders through this, including people who’ve spent careers pushing horizontal change uphill, I have yet to hear a real objection. They’ve lived the alternative.

The Loop

The whole approach fits in one loop.

• Identify the business problem: a real one, with money attached, not a use case hunting for a justification.
• Carve the slice: the capability that owns that problem, cut at the seam, through the org, the application, and the data.
• Create the conditions inside it: the four from earlier in the series, built for real in one bounded place.
• Put AI to work: navigator first to map it, junior engineers under supervision to build it.
• Prove the value: in production, in numbers your CFO accepts, in roughly ninety days.
• Then do it again.

The pattern behind the loop is the strangler fig. The fig doesn’t fight the tree; it grows around it, capability by capability, until one day the old tree is structure, not function. That’s how you get off the legacy platform without the bet-the-company rewrite. Each slice you pull gets a deliberate decision: this piece goes to the ERP you already own, this piece retires, this piece gets built custom because it’s how we win. Slice by value proposition, never lift-and-shift. The backlog of slices burns down over time, and every one of them pays its own way.

Two disciplines keep the carving honest. First, slices are cut from a map, not freehand. The capability map and the end-state picture come before the knife, and every slice is a deliberate move on that map, so the slices accumulate into an architecture instead of a new kind of fragmentation. Second, the backlog is sequenced economically. Inventory the value propositions worth solving and weigh value and cost of delay against effort. Many of you know this as WSJF. Take them in that order, and re-rank as each slice teaches you something. All of which surfaces the thing no transformation program ever says out loud: you only go as far as there’s economic value to be achieved. When the marginal slice stops paying, you stop. The transformation has a bottom.

Ninety Days or It Isn’t a Slice

The economics are the governor on the whole system. If a slice can’t prove its value in about a quarter, it wasn’t scoped as a slice; it’s a project wearing a slice costume. Cut deeper. The ninety-day proof does three jobs at once: it pays for the work, it buys leadership patience with evidence instead of vision, and it de-risks the next slice before you cut it.

It also respects something the transformation industry keeps pretending away: trust is earned in stages. Nobody, no vendor and honestly no internal team either, should be handed production on a promise. The gradient runs: map the estate first, which requires almost no trust. Show the plan. Prove one slice. Widen the aperture. If somebody proposes to transform everything before proving anything, the size of the ask is the tell.

What Compounds

Here’s what the horizontal play never delivers and the vertical play can’t help delivering: each slice leaves the conditions behind. An encapsulated capability. Data that’s clean at the source and stays that way. A team that owns something and knows it. A governance rhythm that funds hypotheses and kills losers. The second slice starts easier than the first; the fifth starts easier than the second. Somewhere along the way, transformation stops being a program you’re running and becomes a thing your organization knows how to do, which was the actual goal all along. Not “we adopted AI.” Not a vendor relationship you can’t exit. A capability that stays when the program ends and the consultants go home.

The Whole Story

We drew a map: pilots live in the quadrant with conditions; enterprises live in the quadrant without them. We read the gauge: twenty working pilots and zero ROI is a measurement, not a mystery. We named the four conditions and gave you the tests. We changed the unit from applications to capabilities, and found the seams. We put AI in its three right jobs and kept judgment human.

And now the ending, which was hiding in the first post all along: don’t move the pilot to the organization. Move the organization, one slice at a time, to where the pilot can live.

Somewhere out there is a CTO with twenty pilots and a board asking where the money went. The next twelve months can be more demos. Or they can be four slices. Clean one boundary. Deliver one slice. Measure it. Do it again.

In my next post, we’ll explore why you can’t bet prodcution on a promise.

This is Part 6 of a seven-part series. Start with Part 1 here.

This series has been about conditions: why pilots die in production, what the four conditions are, why capabilities and not applications are the unit you create them around. Now the question underneath everything: once you’ve done that work, once a capability is genuinely free, encapsulated, with clean data and one team that owns it, what is AI actually for?

The market offers two answers, and both are wrong. One camp says AI replaces the engineers: the workforce story, the one boards want to hear. The other says it’s a better autocomplete: the skeptic’s story, the one your senior engineers mutter after the third demo. The truth is more specific and more useful: inside a clean boundary, AI has three real jobs. And there is one job it can never take.

Job One: The Navigator

Before AI writes a line of production code for you, it should tell you the truth about what you have. Point it at a legacy estate and it can extract domains and subdomains, cluster what changes together, map the data, and surface the duplicates. The archaeology I described in the last post, months compressed into days. Point it at your data, same move: don’t ask AI to make sense of the swamp, ask it to show you the swamp, where the data is born, where it breaks, where two systems disagree about what a customer is.

Two disciplines keep this honest. First, navigator, not oracle: in our experience this class of analysis comes back about 80% right, and the remaining 20% is exactly where the danger lives. Every finding gets a human judge. Second, the output isn’t the deliverable; the decision is. The navigator exists so that humans can decide where to cut, what to keep, what to kill, faster and with better information than archaeology ever allowed.

Job Two: The Junior Engineer

I’ve been calling AI a junior engineer all series, and I mean it precisely. A junior engineer is genuinely productive under specific management: clear scope, bounded assignments, tight feedback, and somebody checking the work. Rope management. Give a junior engineer a vague mission inside a tangled codebase and you get confident chaos. Give them a well-defined story inside a clean boundary and they’ll outwork everyone.

So the discipline inside the slice looks like this: keep the cycles small, the context high, and the dependencies low. Constrain the agent with tests: humans define what done means, the agent works until the tests pass, humans inspect what it did. The sandbox is the management system.

And here’s where it compounds. Inside a genuinely clean boundary, this stops being one developer with a copilot and becomes a delivery team of agents: distinct agents for analysis, design, build, test, and deploy, working a separation of concerns, supervised by a pair or two of experienced developers sitting above them at the product tier. The people who used to do the typing move up a level and orchestrate. Whether the delivery tier eventually needs any humans in it at all is a live hypothesis where the conditions are real. But notice what never goes away: supervision doesn’t disappear. It moves up.

Job Three: The Operator

The first two jobs work on the software. The third works on the business, and it’s the one everything else exists to unlock.

Something important happens once a capability is genuinely encapsulated: the business objects inside it stop being rows scattered across systems and become real, addressable things. The order, the claim, the candidate, the crew, the policy. Each with one definition, validated data at its source, a clear interface, and an owner. And once the business objects are clean, AI can act on them, and across them.

On them: the use cases everyone wanted from day one, finally standing on something. Triage the claim. Score the candidate. Route the order. Price the policy. Decisions made at machine speed, inside governed bounds, auditable precisely because the boundary is clean.

Across them is where it compounds. Because the bounded contexts share well-defined seams, AI can reason across the object graph: the customer as they actually exist across sales, service, and billing, with no data lake in between. Next-best-action. Anomaly detection before the quarter closes. Forecasts built on data you actually trust. New products assembled from assets that used to be trapped in the monolith.

Here’s the uncomfortable recognition: this is the job everyone tried to give AI first. The twenty pilots from the start of this series were almost all attempts at job three, launched before jobs one and two had created the conditions it runs on. The job was never wrong. It was just gated.

And notice what changes economically. The navigator and the junior engineer pay in cost and speed, which is engineering leverage. The operator pays in revenue, margin, and decision quality: the ROI the board was actually asking about. We think of the arc as extract, enhance, exploit: extract the understanding, enhance the capability, exploit the clean estate. Most of the market is trying to exploit what it never extracted.

The Job It Can Never Take

Everything above is execution. Magnificent, economically transformative execution, at machine speed, inside human-drawn bounds. What it is not, and will not become on any timeline that should affect your planning, is judgment.

Taste, insight, discernment. The connection between two ideas that no training corpus holds because nobody has written it down yet. The call that weighs a decision against twenty years of watching this specific industry punish that specific mistake. General AI has read everything public and knows nothing about you: your team, your clients, your history, the reasons behind the reasons. Without that context, it is, for real knowledge work, far less useful than the hype suggests. Building that context layer for organizations is, I’d argue, the most underexplored frontier in enterprise AI. Almost nobody is working on it. That’s a future post.

This is why the replace-the-humans story fails on its own terms: it automates the cheap part and discards the scarce part.

The Trap: Automating the Artifacts

One warning before the next post, because I watch smart teams walk into it. The artifacts of software delivery were never the point: the stories, the specs, the plans. They were the excuse for the conversation that got everyone on the same page. Have AI generate the stories and skip the conversation, and you’ve reinvented the functional spec, thrown over a wall, at machine speed. You haven’t saved toil. Automate the typing. Keep the thinking together. If your AI rollout is quietly deleting the places where shared understanding gets built, it’s amplifying more than your codebase.

So: navigator, junior engineer, operator, and a judgment layer that stays defiantly human. What’s left is the part the whole series has been building toward: how you actually run this. One slice at a time, proven economically in ninety days, compounding as it goes. That’s the next post.

This is Part 5 of a seven-part series. Start with Part 1 here.

The last post ended with a question: which slice? If the way out of the pilot graveyard is creating the four conditions in one real place at a time, one boundary with production inside it, then everything depends on where you draw that boundary. And here’s the problem: most organizations can’t answer the question because they are thinking in the wrong unit. They think in applications.

So before we can find the seams, we have to break a thirty-year habit.

When You Hear “Application,” Hear “Monolithic Container”

An application is not a thing. It’s packaging. It’s how a set of business capabilities happened to get bundled together: by a vendor’s roadmap, by an acquisition, by a decade of “just put it in the same codebase because that’s where the team was.” When somebody says we need to modernize the ERP, or we have to get off the AS/400, they are talking about the box, not what’s in it.

And what’s in it? Everything. We’ve run capability analysis against a lot of these systems, and the honest description of what comes back is an antique mall: live capabilities next to dead ones, duplicates of things that exist in three other systems, the genuinely differentiating logic of the business sitting in the same container as commodity functions you could buy off the shelf tomorrow. The application is a La Brea tar pit with all the bones in it. The bones don’t belong together. They just sank in the same place.

You cannot create the four conditions around a container like that. You can’t encapsulate everything. You can’t assign one team to own all of it. The application is exactly the tangle we’ve spent two posts saying you can’t automate.

Capabilities Are the Unit of Decision

A business capability is a thing your company does: take an order, screen a candidate, dispatch a crew, price a policy. Capabilities decompose cleanly: domains, subdomains, bounded contexts, all the way down to the data. And unlike applications, capabilities have natural edges. A bounded context is precisely the line where one definition of customer ends and another begins. Those edges are where encapsulation is possible. Which means those edges are where the four conditions can actually be created: where a team can own something, where data can be validated at its source, and where an agent can work inside a boundary instead of drowning in a container.

This is the answer to which slice. A slice is a capability, cut at its natural seam, taken all the way down through the code and the data.

Nobody Knows What’s in These Things

Here’s the objection, and it’s a legitimate one: nobody in your organization can tell you what capabilities live in the estate. The containers are dark. The people who packed them are gone. The documentation lies.

This is where AI earns its first honest paycheck, before a single agent writes a line of production code. Point it at a legacy codebase and AI-assisted capability extraction can map the domains and subdomains, cluster what changes together, and surface the duplicates. In our experience it comes back about 80% right, with humans judging the rest. Work that used to take months of archaeology compresses into days. Notice what that is: AI as navigator, making the estate visible, not AI as easy button rewriting it. That distinction is the whole subject of the next post.

Better Seams to Cut

Once you can see capabilities instead of applications, a strategic question replaces a technical one. For each capability, ask: is this where we win, or is this table stakes? Where you differentiate, it deserves to be custom: encapsulated, owned, evolved, eventually agentic. Where you don’t, it belongs in a system you already have. Most of what’s inside that AS/400 isn’t going to be custom software in your future. It’s going into the ERP, the GIS, the platforms already on your floor.

All of which exposes lift-and-shift for what it is: repackaging the tar pit. Point AI at the whole container, rewrite it, and you get a new big application nobody understands, still unintegrated, with all the hard decisions still unmade. The alternative isn’t heroic. Draw out the cuts before you touch anything: this piece to SAP, this piece retired, this piece custom because it’s how we compete. Then cut one seam.

So what’s the recommendation here? Exactly what it sounds like: build the capability map. You don’t need to boil the ocean. Pick the area of the business where the pain lives and map that. It’s the first artifact of everything that follows, and it’s the one deliverable you keep no matter what you decide to do next.

Stop modernizing applications. Start liberating capabilities. The next post is about what AI actually does once a capability is free: what it’s genuinely good at inside a clean boundary, what it can’t do, and why the answer is neither replace the engineers nor just a better autocomplete.

This is Part 4 of a seven-part series. Start with Part 1 here.

In the last post I made the case that your AI pilots aren’t failing: they’re measuring you. Every pilot works because somebody builds it in a protected world; and every pilot dies in production because your real conditions live there. The gap between the two is your readiness gap, quantified. Which raises the obvious question: readiness for what, exactly?

Most of the industry answers with a maturity model. Five levels, a spider chart, an eighteen-month program to get to Level 3, and a comfortable consulting engagement measured in workshops. I want to offer something more useful: four conditions. Not levels, actual conditions. Either they exist where you’re trying to run AI, or they don’t. All four are testable, and you can test them this week.

The organizing idea behind all four: you can’t automate a tangle, only a clean boundary. Everything below is a different way of drawing a boundary.

Condition One: Encapsulated Technology

AI needs a bounded space to work in. That means capabilities with real edges: code that belongs to somebody, interfaces that hide what’s behind them, dependencies managed at the boundary instead of leaking through everything. The absence looks like the enterprise I described in the last post: shared codebases nobody owns, branches that live for months, eighteen teams required to touch anything. Dependencies don’t show up in the org chart; they show up in the code, and AI lands right where they show up.

The Test: can one team change one capability without asking permission of another? If the answer is no, an agent can’t either. It will just generate the merge conflicts faster.

Condition Two: Clean Data at the Source

Not clean data in aggregate. Clean data at the source: validated, owned, and documented where the team creates it. The industry has spent two decades building compensating controls for bad data practice: warehouses, lakes, lakehouses. Push everything into one place and make it one central team’s job to understand every business rule in the company. No team can. There is no easy button here, and pointing AI at the swamp doesn’t drain it: garbage behind an abstraction layer is still garbage.

Data work still matters, arguably more. This is an argument about where it happens. The pattern is a data mesh: data owned, validated, and served where it is created, by the team that owns the capability. Build it the way you build everything else in this series: inside the boundary you are about to automate, one slice at a time. Let the rest of the swamp wait its turn.

The Test: pick a critical data element. Do you know where it is born, and is it valid there, or does somebody fix it downstream? If it’s fixed downstream, AI is consuming the unfixed version everywhere else.

Condition Three: An Organization Designed Around Ownership

Teams aligned to business capabilities: domains, not components. The absence is familiar: a QA team, a front-end team, a back-end team, and a piece of work that touches all of them, coordinated by meetings. In that design nobody owns an outcome, so there is nothing an agent can be accountable to. AI doesn’t fix an ownership vacuum; it floods it with output nobody is responsible for. And scale doesn’t break the rule: a capability too big for one team decomposes into subdomains that aren’t. Ownership holds at every level.

The Test: for any business capability that matters, can you name the one team that owns it? One team. If the answer is a list, the condition doesn’t exist.

Condition Four: Intent Governed at the Top

This is the big one, the one condition that the twenty-pilot story violated most visibly. Energy without direction: boards demanding results, engineers experimenting, and no mechanism between them, no place where an AI hypothesis goes to get funded, measured, scaled, or killed. Governance here does not mean bureaucracy. It means somebody can say what we are trying to learn, what we are trying to earn, what we are going to stop doing, and what number tells us the truth. Directed R&D instead of undirected. Harmonized instead of standardized.

The Test: when a pilot succeeds, is there a system that moves it into production, and when a pilot fails, is there a system that kills it? If pilots accumulate, intent isn’t governed, it’s ambient.

Here’s the Part That Should Change Your Plan

You do not need all four conditions everywhere. That is the trap: hearing “conditions” and scheduling a three-year enterprise readiness program, which is just the maturity model wearing a new hat. Remember what we proved in the pilot. We can create these conditions. Your innovation colony created all four in a small, artificial space. That’s also the difference between a pilot and what comes next: a pilot simulates the conditions; a slice creates them for real, with production inside the boundary. A slice is not a bigger pilot. The work is to create the conditions somewhere real: one boundary, one capability, one portfolio, one slice of the enterprise where all four conditions genuinely hold. In the agile world, we called these expeditions. That’s the difference between transforming the company and transforming a slice of the company that pays for and builds momentum for the next slice.

Which slice? That’s the next post: why the application is no longer the unit of decision, and how to find the seams worth cutting.

Until then, run the four tests. They take a week, they cost nothing, and unlike your pilots, they measure the thing you can actually fix.

This is Part 3 of a seven-part series. Start with Part 1 here.

I was talking to a CTO client recently who mentioned he had twenty AI pilots running inside his organization. Twenty. Every one started the same way. A mandate from above to use AI, but all of them disconnected from all the others. His words: “We’re learning the same lessons twenty times over, in different places, and none of it is turning into forward progress.” And none of them producing clear ROI that anyone could point to.

The standard diagnosis goes something like this: too many pilots, not enough coordination, wrong tools, wrong models, wrong talent. The board wants results, so the prescription follows: buy better tools, hire more AI talent, try a newer model.

All of that misses. The pilots aren’t the problem. The pilots aren’t even failing.

Every Demo Works

In the last post I mentioned the LiminalArc Four Quadrants, the model I used for fifteen years to explain why agile pilots thrived in the upper-right quadrant and died when they moved into the upper-left, where the real enterprise lives. If you missed it, the short version is this: a pilot succeeds because somebody built it a protected world. Small, self-contained, no dependencies, hand-picked data. One team that owns the whole thing, and somebody who owns the outcome and genuinely cares if it works.

A pilot is a temporary simulation of the conditions AI needs: encapsulation, clean data, real ownership, clear intent. That is why every demo works. The demo isn’t lying to you. It’s a preview of what AI does when those conditions exist.

Then the pilot touches scale: other teams, other users, real requests. Production is just the place where scale becomes unavoidable, and it’s the upper-left quadrant, where your real conditions live. The shared codebase nobody owns. The data with three conflicting definitions of customer. The process with eleven handoffs. And it dies. Nothing changed between the demo and the death except the substrate. We watched agile pilots die this exact death for fifteen years. The technology changed, the map didn’t.

The Amplification Law

In 1990, Michael Hammer wrote “Reengineering Work: Don’t Automate, Obliterate” in Harvard Business Review. Companies were using technology to speed up broken processes instead of fixing them. Stop paving cow paths. There is a line often attributed to Bill Gates that says it even more plainly: automation applied to an efficient operation magnifies the efficiency; applied to an inefficient operation, it magnifies the inefficiency.

AI is that law with a much bigger multiplier. This is the “penalty went up” point from the last post, with the actual mechanism attached. For the first time, the automation doesn’t just execute steps faster. It generates work product: code, branches, tests, decisions. Instrument a broken process with AI and you get a process that produces more broken stuff per unit of time: the industrial production of AI slop. A codebase with no ownership plus AI-accelerated developers equals more branches, created faster, feeding the same merge hell. AI is a junior engineer you pay in tokens instead of a salary. Put a thousand junior engineers into your systems exactly as they are today. What happens?

The cause, said plainly: the conditions AI needs have not been created. Those are encapsulated technology, clean data at the source, an organization designed around ownership, and intent governed at the top.

Your Pilots Are Measuring You

Now put the two facts side by side. Every pilot works. No pilot pays. That gap is your readiness gap, quantified. The distance between the conditions inside the innovation colony and the conditions in production is the exact distance your organization has to close. Your pilots aren’t failing, they are measuring you, and most organizations have never even looked at the report card. It’s also why buying more instruments never moves the needle. A better tool, a bigger model, another platform: each measures the same gap, more expensively.

What to Do About It

Two moves. First, treat your pilot portfolio as diagnostic data. Where did each one stall? Data quality, handoffs, nobody owning the outcome, no path to production. Every stall point names a missing condition. You’re sitting on twenty free readiness probes you already paid for. Second, corral the energy, knowing it’s not the cure: convert every pilot into a hypothesis under lightweight governance, roll out the winners, kill the rest deliberately. Governance organizes the learning. It doesn’t create the ROI.

Creating the conditions does. That’s the next post: the four conditions, what each of those conditions actually means, and how to test whether or not you have them.

Stop asking why your pilots aren’t scaling. Start asking what they are telling you about your system and what about that system is killing them.

This is Part 2 of a seven-part series. Start with Part 1 here.

Over the past fifteen years I have stood on a lot of stages explaining why agile fails in large enterprises. What emerged over those years was a model LiminalArc calls the Four Quadrants. As we find ourselves in the midst of doing a ton of AI transformation work, I find the model as applicable now as it has ever been. AI transformation is failing for exactly the same reason that agile transformation failed, and the model saw it coming both times.

The Map

The Four Quadrants model suggests two axes. The horizontal axis is predictability versus adaptability. Executives need to make and meet commitments, and they need to respond to constant change, and by definition those needs will compete with each other. The vertical axis is emergent versus convergent. Sometimes you know exactly what you want and you need it fast, cheap, and on schedule. Sometimes the requirements aren’t defined, or even definable, and you’re testing hypotheses to find out what works.

Cross the two axes and you get four quadrants. The lower-left is traditional, governed, and predictable delivery. The lower-right is agile’s home base: making and meeting commitments in small batches. The upper-right is the land of experimentation. Small, independent teams, few if any dependencies, funded to solve problems rather than deliver against a fixed scope. Lean Startup lives there, along with innovation and most pilots.

The upper-left, predictive-emergent, is the quadrant of chaos and heroics. Organizations built for predictability, behaving emergently. Plans nobody believes, death marches, a handful of heroes making it happen when it counts. Here is the uncomfortable part: that’s where most of the enterprise market actually lives. It was true in 2012 and it’s true today in 2026.

The Agile Version of This Story

A company wants to go agile, so it stands up a pilot. Without quite realizing it, it builds that pilot in the upper-right quadrant. Small dedicated teams. No dependencies. Clear mission. Room to learn. The pilot works, because of course it works. Every condition it needs has been created for it.

Then the pilot “scales.” It moves into the upper-left, where the rest of the organization lives: the dependencies, the shared systems, the competing commitments, the heroics. And it dies. The company concludes that agile doesn’t work here. But agile was never the thing that failed. The conditions the pilot ran on didn’t travel. They were never going to travel. Nobody built them anywhere else.

The AI Version Is the Same Story

An innovation colony gets stood up: encapsulated scope, hand-picked data, one team that owns the whole thing, somebody who has a mandate and genuinely cares about the outcome. That’s the upper-right quadrant, a temporary simulation of every condition AI needs. The demo works, because of course it works. Then it moves toward production, into the upper-left where the real enterprise lives, and it dies there just like agile before it did. And the company starts wondering if AI is overhyped.

It’s the same map and the same trajectory. Only the technology changed.

Why I’m Writing This Series

Two things are different this time, and that’s why this deserves more than just a nod to the parallel. AI does more than underperform in the upper-left the way agile did. It amplifies the problem, because AI generates work product, so the chaos compounds instead of idling. The penalty went up. But the technology can also, for the first time, help build its own road. AI is remarkably good at mapping the upper-left: what’s in your estate, where the seams are, and what dependencies are getting in your way.

So over the next five posts, I’m going to make the full argument for why AI fails, and what you can do about it. We’ll look at what the pilot graveyard is actually telling you. We’ll name four conditions you can test in a week. We’ll build a map of your enterprise landscape you can actually use. We’ll get at AI’s real jobs once the conditions exist, and the one job it can never take. And we’ll lay out how to run the whole thing in a way that proves value every ninety days with a defined end-state.

It starts with a conversation I had recently with a sitting CTO who counted his AI pilots and got to twenty. That’s next.

Ellen has run product for her group for years, and she can name the week the job changed. It was not a reorganization and no one announced it. The gap between strategy and delivery simply became amplified, one conversation at a time. The build engine was faster than it had ever been, and every team lead, stakeholder, and steering group brought her the same four words. What do we do next?

The question arrived faster than she could answer it. Decisions that once waited invisibly in a long development queue now waited visibly on her calendar. Feeding that calendar was a wall of options: each one better polished, each one possible, each one assembled in greater efficiency with an AI agent collaborative process, complete with requirements and a business case. Ellen’s own role had changed. She used to spend her weeks eliciting ideas and shaping them. What the agents cannot do is commit the organization to one, or answer for it. The judgment to decide, the one thing that did not scale, had become her primary job.

The Fuzzy Front End Lost Its Buffer

Donald Reinertsen and Preston Smith named this territory more than three decades ago: the fuzzy front end, the stretch between a market signal and a committed decision to act, where initiatives wander before development begins. The fuzz always had a cost, but a buffer absorbed it. When building took quarters, the long queue behind every decision worked as that buffer. Intent had time to firm up while the engine ground through the backlog. The fuzz was never only a discipline problem. What to build is genuinely hard to know in advance, and the front end rarely had a rigorous process for making it clearer. It stayed that way because the constraint lived downstream. Fuzz was not the bigger problem, so it was tolerated rather than fixed.

A fast, inexpensive build engine removes the buffer. Fuzzy intent no longer waits; it passes straight through the engine and ships. There is no interval in which clarity catches up, so half-agreed intent becomes shipped clutter at machine speed. It spends the customer’s limited capacity for change on things nobody agreed were the problem.

Fuzz was tolerated while the constraint lived downstream. The buffer is gone.

The Scarcity Is Decision Capacity

So if ideas, build capacity, and information (telemetry, synthesized feedback, and adoption signals) are abundant, what is the scarcity now? It is decisions, the organization’s capacity to converge and agree, quickly and repeatedly, on the next problem worth solving for the customer. Clarity alone is not enough. One person can make a choice, but a choice becomes a decision only when the organization is bound to act on it. That is what deciding means at organizational scale. McKinsey’s research on organizational decision making suggests how strained that capacity already is. Managers at a typical large company spend 37 percent of their time on decisions, and say most of that time is used ineffectively. Only one in five reports an organization that excels at deciding.

37 percent of managers’ time goes to making decisions. The majority of it, by their own account, is used ineffectively.

A faster engine does not need a better decider. It needs an organization that can decide well many times over, in parallel, without routing every choice through one calendar. That makes decisioning a core governance capability, one the operating model has to hold deliberately, with people accountable for it and measures that show whether it is keeping pace.

Part of building that capability is shrinking what has to be agreed. In place of a long-range roadmap, one testable intent comes forward at a time: the problem to solve, a value hypothesis, and a confirmation plan describing how the team will know it was right within weeks. Options stop being arguments and become candidates for evidence. Decisions get faster because the thing being agreed on gets smaller.

Agreement also has a clock, and almost no one reads it. The engineering side of the house already measures its half of the loop; in “Are You Building the Right Thing,” Adam Whaley clocks time to feedback, the interval from starting a piece of work until a real user responds to it. The upstream mirror is simpler than it sounds. Measure the elapsed time from an idea arriving to its entry in a product backlog as committed work. Call it upstream lead time. Nearly none of that interval is production; it is deciding and aligning, which is what makes it the most honest proxy available for decision capacity. Deciding will need its own family of measures, the way delivery eventually got its own; this one is the place to start, because it is the one every organization can already compute.

One guard keeps the measure honest. Entry into the backlog has to mean committed intent, not a parked idea. Otherwise the number improves while nothing has actually been decided. Ellen stopped asking her teams how much was in flight and started asking how long each intent had been waiting to become one. The items waiting longest are not the hardest problems. They are often the ones nobody is empowered to decide.

Redesign the Clocks, Not the Gates

The instinctive fixes fail in opposite directions. More gates make agreement slower, rebuilding the heavyweight front end that was survivable only when the build was slower still. No governance makes agreement meaningless, because nothing binds the organization to act. The redesign is about placement and cadence, who holds which decisions and how often each decision renews.

Placement

A decision belongs at the boundary where its information lives, and risk is what sorts it there. Two properties settle it: reversibility, and the cost of being wrong. Low-risk intents, inexpensive to reverse and contained if mistaken, belong in the queue directly. Agents rank them, the team picks, and the confirmation plan catches the errors. Higher-risk intents need a named owner inside an explicit allocation envelope, because someone has to commit the organization and answer for the outcome. Some decisions genuinely cross boundaries: moving money or people between products, retiring a bet, changing direction. Those travel upward. Where the right value measurement does not yet exist, compensating controls hold the line until it does. Coordinated decisions are the ones that queue; the design goal is to grade honestly, delegate everything the grade allows, and need as few of the traveling kind as possible. Ellen graded every option on those two properties before asking who decides, and kept the high-risk calls herself.

Cadence

Three tiers set the rhythm. Strategy moves slowly, and should; direction is expensive to whipsaw. Portfolio allocation renews quarterly or on evidence triggers, adjusting envelopes rather than re-litigating every line. Product intent renews at the speed of the learning loop. One rule disciplines all three. Governance has to renew faster than the assumptions it governs expire. When assumptions held for years, calendar planning worked. Telemetry now retires assumptions in weeks.

Governance design is placement and cadence, who decides and how often. Get either wrong and governance becomes the bottleneck

The three tiers are connected, and that is the warning. A system moves at the pace of its slowest clock. Anything left on a slower rhythm will set the pace for everything else. Pace also depends on the size of the work.

How the enterprise moves money, and how strategy above the portfolio keeps up, is a larger redesign that deserves its own treatment. However fast the front end learns to decide, everything connected to it has to be able to follow.

What Ellen Learned

By the second quarter, Ellen’s review looked different. Intents came forward monthly, in units small enough to decide and confirm. Of the last eleven ideas, five were stopped before the build, when the evidence said no and stopping was still cheap. Alex, her group’s delivery leader, asked what she would tell a peer walking into the same storm. Three lessons she held:

1. Measure the front end as a queue. Upstream lead time is as measurable as the delivery lead time beside it, and until it is measured, the most expensive queue in the system keeps hiding in plain sight.
2. Test governance against the pace of evidence. Check where each decision sits and how often it renews. If evidence arrives in weeks and permission arrives in quarters, the teams are not the problem; the operating model is.
3. Sequence the redesign honestly. Start where the operating model can move now: placement and cadence. Then name what still sets the pace for everything connected to it.

The question that used to fill her calendar still arrives every week. What changed is that the organization can now answer it, at the speed the question deserves.

This post comes from our management consulting practice, which specializes in designing and implementing operating models that align governance, processes, and technology to drive measurable business outcomes.

Sources

Donald G. Reinertsen and Preston G. Smith, Developing Products in Half the Time, Van Nostrand Reinhold, 1991. Popularized the term “the fuzzy front end.”

McKinsey & Company, “Decision making in the age of urgency,” April 2019.

Adam Whaley, “Are You Building the Right Thing: The Metrics That Measure How Fast You Learn,” July 2026. Source of the delivery learning-loop metrics referenced.

Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement, North River Press, 1984. Character homage, names only, in tribute.

Alien, directed by Ridley Scott, 20th Century Fox, 1979. Character homage, name only, in tribute.

If you lead product today, you’ve probably felt the ground shift. The old advice was to ship something rough and learn in public. Now a rough launch gets punished. Users expect polish on day one, and a first version that looks unfinished can cost you the second chance you were counting on.

So the industry has done what industries do. It kept the Minimum Viable Product and swapped the adjective. First came the Minimum Lovable Product, the smallest thing people will love rather than tolerate. Then came the Minimum Adaptive Product, software that reshapes itself around each user. Both are sensible responses to a real change. Both leave the same assumption untouched.

That assumption is that the noun is what we’re optimizing. The product. When building was slow and expensive, that made sense. The first version was the costly thing, so we argued about how good it had to be before we dared show anyone. “Minimum” and “viable” were doing real work, because every build was a bet you couldn’t easily unwind.

AI has quietly removed that constraint. When a polished experience costs a weekend instead of a quarter, the first version isn’t the expensive thing anymore. Being wrong is still cheap to discover. Being wrong and unable to change course is what now costs you. The bottleneck has moved from making the product to changing your mind about it.

Which points to a different word than lovable, viable, or adaptive: adaptable.

The distinction is easy to miss and worth holding onto. An adaptive product changes itself for the user. That’s a feature, and it lives inside the product. An adaptable product is one you can change cheaply as you learn. It’s a property of how the thing is built, and of how ready your team is to keep experimenting: not a feature bolted onto the product itself. In practice, that means short feedback loops, components that don’t require a full rebuild to change, and a team with real authority to act on what they learn. One reshapes around the user. The other lets you reshape around the truth.

Seen this way, the strategic question changes. It’s less “What are we building, and is it good enough to launch,” and more “How cheaply can we learn we were wrong, and act on it.” The first version stops being a verdict on the idea. It becomes the opening move in a loop you intend to run many times.

None of this retires the discipline that made the MVP useful. Clear hypotheses, real users, and honest evidence still decide who wins. What changes is where the advantage sits. How much that’s worth still depends on how sure you are: a well-understood build doesn’t need to pay for it, but the more you expect to be wrong, the more that property is worth having. In a market where anyone can build almost anything quickly, the durable edge is how quickly the next version can be different, not the product you launch.

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.