Full Pipeline.
Wrong Bets.

Your roadmap is full. Your pipeline is humming. Your teams are shipping. And the bets that fill every one of those roadmaps were placed before anyone observed what is actually happening in the environment they were supposed to address.

Every system has a constraint. A single point that governs throughput for the entire value stream. That constraint never disappears. When you address it at one node, it migrates to the next weakest point in the system. The history of enterprise IT over the past thirty years is the history of that migration.

Through the 1990s, the binding constraint was engineering capability. Building software was slow, fragile, and expensive. Waterfall processes stretched timelines to years. A series of lightweight methodologies emerged to address this bottleneck: Rapid Application Development in 1991, Scrum in 1995, Extreme Programming in 1996. In February 2001, seventeen practitioners codified what had been forming in practice for a decade. The Agile Manifesto. Small accountable teams, timeboxed increments, fast feedback loops. Agile addressed engineering as the binding constraint. Teams could build. But they still could not test, deliver, measure, or monitor what they built. The constraint moved.

By the early 2010s, the bottleneck had migrated to delivery. Teams could produce working software faster than ever, but they could not get it into production reliably. Testing was manual and slow. Configuration was fragile. Release management was a chokepoint. Operations and monitoring were disconnected from development. In 2013, Gene Kim, Kevin Behr, and George Spafford published The Phoenix Project, explicitly modeling it after Goldratt's The Goal. The book applied Lean principles, Theory of Constraints, and sociotechnical systems theory to the delivery problem. The DevOps movement that followed addressed testing, configuration, release management, operations, and monitoring as a unified value stream. CI/CD pipelines, infrastructure as code, accountable stable teams, and automated feedback loops alleviated the delivery bottleneck. For organizations that invested in it, the delivery constraint is addressed, or addressable. The system can move value from concept to production with speed and reliability. The constraint moved again.

Around 2018, the bottleneck migrated upstream to product. "Projects to Products." Product-driven organizations. The books were written. The movements launched. Except most organizations never fully built the decision layer that product leadership requires. What they call product teams are often order-taking feature factories for the business, with little connection to organizational strategy, KPIs, or value realization. They did not build a decision layer. They built a pass-through.

The intent was there. But the timing was brutal. Just as enterprise IT was beginning to address the product constraint, the pandemic hit. Markets evaporated overnight. Organizations scrambled to shift to remote work, then back to the office, then to hybrid models that satisfied nobody. Budgets were frozen, then redirected, then frozen again. Some organizations managed to build real product capability through that disruption. Many did the best they could with what they had, which often meant rebranding Business Analysts and Project Managers as Product Managers without providing the clarity of role definition, the competency through training in economic trade-off decision-making, or the capacity to learn new ways of working while simultaneously keeping the lights on. The function that was supposed to make outcome-driven decisions about what to build, what problems to solve, and where enterprise value lives was handed to people who were never given the tools or the time to learn what that function actually requires. The decision layer never fully formed. And ProductOps, the discipline designed to operationalize that layer, arrived to scale a capability that is still nascent in most organizations.

And the constraint moved past product, too.

The bets filling every roadmap are committed before they ever reach a product leader. Strategic commitments arrive pre-formed. Planning assumptions arrive untested. The highest-paid opinion in the room sets direction for every team, every budget, every roadmap. And those commitments are built the same way they were built twenty years ago: internal data, leadership experience, periodic customer surveys, and assumptions that were never validated against what is actually happening in the environment the organization exists to serve.

The constraint is now in the intelligence feeding the entire system. And every improvement below it is increasing the throughput of unvalidated bets.

The Bottleneck at the Top
of the Bottle.

Goldratt made the principle plain:

The constraint in a system of value delivery is never static. It sits wherever the system is weakest. Address it at that node and it moves to the next one. The system's total throughput is always governed by wherever the constraint currently sits, regardless of how much capacity exists everywhere else. An hour saved at a non-bottleneck is a mirage.

This is the lens through which the entire Ops lineage needs to be read. Agile did not solve engineering. It addressed engineering as the binding constraint, and the constraint moved to delivery. DevOps did not solve delivery. It addressed delivery as the binding constraint, and the constraint moved to product. Product management was supposed to be the next discipline to address the next bottleneck. It stalled. Most organizations never built the decision layer. They built feature factories.

And the constraint moved past product to the intelligence feeding the entire system. Where it is sitting now. Unaddressed.

I saw this at the DevOps Enterprise Summit in San Francisco in 2016, presenting a case study on the Lean DevOps transformation we ran inside Johnson and Johnson. The world's largest healthcare company. Highly siloed, matrixed IT organization. The kind of place where people say "DevOps just won't work here." We used enterprise architecture to identify constraints, run experiments, and decrease lead-time across all of IT rather than optimizing specific functions or products. We focused on system throughput. And through those experiments, we uncovered something that mattered more than velocity: the enterprise IT organizations that survive are the ones that learn to continuously re-align IT with business intent. Not deliver faster. Deliver the right thing. The constraint was not in the engineering or the delivery. The constraint was in knowing what to build and why.

That question has only become more urgent. Roadmaps are filled to capacity with commitments to build things that may or may not ever deliver value, because those commitments are based on assumptions that were never tested against observed reality. The system is optimized for throughput at every node below the constraint. And the constraint itself, the intelligence that determines what gets built and why, has never been operationalized.

The intellectual foundations of strategic planning were dismantled thirty years ago. In 1994, the structural reason planning kept failing was identified with precision:

Analysis disaggregates. Synthesis integrates. The formal planning process was exceptionally good at the former and structurally incapable of the latter. The harder organizations tried to be rigorous in their planning, the further they moved from the emergent, adaptive intelligence that effective strategy actually requires. Planning produced commitment to a predicted future, and that commitment made organizations less capable of perceiving when the actual future was different from the predicted one.

Two years later, the blade was sharpened further. The essential problem, as "Strategy as Revolution" laid bare, is the failure to distinguish planning from strategizing. Planning is ritualistic, reductionist, extrapolative, and elitist. It works from today forward, not from the future back. And then the line that should be carved into the wall of every boardroom in the Fortune 500:

Where are you likely to find people with the least diversity of experience, the largest investment in the past, and the greatest reverence for how things have always been done? At the top. The people holding the strategy pen are the people least equipped to see what the strategy needs to address.

The research on how leadership actually spends its time confirmed what the theory predicted. Senior managers devote less than 3% of their time to building a shared perspective on the future. The urgent drives out the important. Every quarter. And organizations respond to the resulting drift not by investing in foresight but by restructuring. Cutting denominators rather than growing numerators. Optimizing what exists rather than sensing what is emerging.

This is the constraint that has been sitting at the top of the strategic funnel, unaddressed. Enterprise IT did not spend thirty years failing to build and deliver software. Agile addressed the engineering bottleneck. DevOps addressed the delivery bottleneck. Both effectively. The system can now move value from concept to production faster than at any point in history. But the constraint is no longer in the code or the pipeline. The constraint is in the intelligence. Roadmaps are filled to capacity. The pipeline is full. The teams are shipping. But the bets that fill those roadmaps were placed before anyone observed what was actually happening in the environment those bets were supposed to address. The system is optimized for throughput of commitments that were never validated.

The planning process cannot produce strategy. The people running it are the least likely to see what needs to change. And the constraint will not wait to be noticed. It simply moves to wherever the system is weakest.

It moved to the top of the funnel. And nobody built the infrastructure to address where it landed.

The Missing
Discipline.

The sensing gap. The structural distance between what is actually happening in an organization's environment and what reaches decision-makers in a form they can act on. This gap is not visible from inside the organization. Organizations that have it are not aware of what they are not seeing. That is the defining characteristic of the problem. They are planning, executing, and adapting. Doing strategy the way strategy has always been done. What they do not have is a way to know whether the information available is the information that matters. Whether the signals reaching the decision-making level are the signals that would actually change the decisions being made. Whether the planning process is beginning from an accurate read of what is happening in the communities and markets the organization exists to serve, or from an accumulated set of internal assumptions that have never been systematically tested against external behavioral reality.

The discipline that closes this gap is what I am calling ForesightOps.

ForesightOps is the operational infrastructure for continuous behavioral research. It transforms what organizations observe about real human behavior into strategic intelligence that improves decision quality before commitments are made. Not after outcomes have revealed what was missing.

It is not a research methodology. It is not a technology platform. It is not a consulting engagement with a terminal state. It is the discipline of building the systems that make genuine organizational listening continuous, scalable, and connected to the decisions that matter. It persists. It compounds. It operates whether or not an external advisor is in the room. The advantage widens with every cycle.

This is the gap in the Ops lineage. Not a missing feature. A missing discipline. The constraint moved, and nobody built the infrastructure to address where it landed.

The organizations that hedged well in every previous disruption share one characteristic. They did not predict the future. They built the infrastructure to see it forming. They placed better bets because they had better intelligence feeding the decision. Not better analysts. Better systems.

You cannot react your way to alpha. You have to build toward it.