and What They All Get Wrong About People
Every few years, a new framework arrives in the mid-market executive’s inbox, promising to unlock innovation. The names rotate; the pitch does not. Adopt this methodology, the argument goes, and your organization will transform itself from a follower into a leader.
The frameworks themselves are not frivolous. Lean Startup, Agile, Blue Ocean Strategy, Design Thinking, Six Sigma, Disruptive Innovation, Jobs to be Done; each represents serious intellectual work by serious people, and each captures something genuinely true about how value gets created or destroyed. The problem is not that they are wrong. The problem is that they are incomplete in the same way, and the piece they all leave out happens to be the piece that matters most for midsize companies trying to innovate in the AI era.
They leave out the people.
Not in the superficial sense of “people matter”. Every framework pays lip service to culture, teamwork, and leadership. What none of them adequately addresses is the specific human dynamics that determine whether an innovation effort lives or dies inside a real organization with real politics, real budgets, and real careers on the line. For a 200-person company without a dedicated innovation team, without a Chief Strategy Officer, without a bench of internal champions who have done this before, that omission is fatal.
The Efficiency Bias
Before examining each framework individually, it is worth naming the deeper pattern. Nearly all of these models were designed to answer some version of the same question: How do we do things better? Lean asks how to iterate faster. Agile asks how to develop faster. Six Sigma asks how to produce more consistently. Even the frameworks that claim to be about discovering the new, Blue Ocean and Disruptive Innovation among them, tend to frame discovery in terms of analysis and process rather than imagination and judgment.
This is the efficiency bias at work. It is not that efficiency is unimportant; efficiency is the foundation on which innovation must be built. But when every framework in your toolkit is fundamentally about optimizing process, you end up with an organization that is extraordinarily good at refining what already exists and structurally incapable of creating what does not yet exist. The distinction between Efficiency Questions and Innovative Questions is not academic; it is the difference between sustaining your current market position and building the capabilities that will define the next one. This is the core insight of Innovating Beyond Efficiency.
Lean Startup and the Myth of Directionless Iteration
Lean Startup’s Build-Measure-Learn loop is elegant, and for a startup with three employees and a whiteboard, it is the right instinct. You do not know what the market wants; build something small, measure the response, learn, and iterate.
The difficulty arises when this methodology gets imported into a midsize company that already has customers, revenue, infrastructure, and a reputation to protect. The instruction to “fail fast” assumes that failure is cheap. In a company with 500 employees and $200M in revenue, failure is never cheap. A poorly conceived product pivot burns capital, demoralizes teams, confuses customers, and erodes the trust of a board that approved the investment based on a strategic rationale.
The deeper problem is that Lean Startup treats innovation as a discovery process that can be managed through rapid experimentation alone. It has little to say about the organizational preconditions that make experimentation productive rather than chaotic. Who decides what to test? How are competing hypotheses prioritized when three VPs each believe their initiative deserves the next sprint? What happens when the data from a test is ambiguous, which it almost always is? These are not process questions; they are leadership and culture questions. Lean gives you a loop. It does not give you the judgment to know what belongs inside it.
Agile and the Architecture Deficit
Agile was born as a corrective to Waterfall development, and it was the right corrective. Rigid, multi-year project plans that assumed requirements would not change were failing spectacularly. Agile’s answer, short sprints, working software, adaptive planning, was a genuine improvement for software teams.
The unintended consequence has been an industry-wide bias toward speed at the expense of architecture. When the entire development organization is oriented around two-week cycles, the incentive structure rewards visible, shippable increments and penalizes the unglamorous work of building systems that scale. The result, compounding over years, is technical debt: a growing burden of shortcuts, workarounds, and architectural compromises that eventually makes every new feature twice as hard to build as it should be.
For mid-market companies, this is particularly dangerous because the technical debt is often invisible to non-technical leadership until it reaches a crisis point. The CIO or VP of Engineering knows the platform is fragile; the CEO sees a team that “shipped 47 features this quarter” and concludes everything is fine. Agile’s metrics reinforce this illusion; velocity charts go up and to the right while the foundation quietly deteriorates. The human failure here is not laziness or incompetence; it is a measurement system that makes the wrong things visible and the right things invisible.
Blue Ocean Strategy and the Capability Gap
Blue Ocean Strategy asks a genuinely powerful question: instead of competing in crowded markets, can you create uncontested market space? The analytical tools it provides, the strategy canvas, the four-actions framework, are useful for identifying where conventional competition has created blind spots.
The gap is what happens after the ocean is found. Identifying an uncontested market space is an analytical exercise; defending that space against competitors who will inevitably follow you into it is a capability exercise. Blue Ocean has almost nothing to say about the technological, organizational, and cultural capabilities required to sustain a first-mover advantage in a world where tech-native competitors can enter your new market with superior digital infrastructure and move faster than you can consolidate your position.
For midsize companies, this capability gap is the central challenge of innovation, not the identification of opportunity. Most experienced executives can articulate at least three or four promising strategic directions for their business. What stops them is not a lack of vision; it is the honest recognition that their organization, in its current state, cannot execute on that vision. The technology is not ready. The data is not clean. The team has never done anything like this before. Blue Ocean acknowledges none of these realities.
Design Thinking and the Execution Chasm
Design Thinking brought empathy into the strategic conversation, and that was a valuable contribution. Understanding the user’s experience, mapping pain points, generating solutions from the user’s perspective rather than the engineer’s; these are good instincts. The workshops produce energy, alignment, and often genuinely creative ideas.
The problem is what happens when the workshop ends. Design Thinking produces concepts. Translating concepts into products, services, or business model changes that actually work at scale requires a completely different set of capabilities: technical architecture, data infrastructure, organizational change management, and sustained executive sponsorship through the long, unglamorous middle period where the initial excitement has faded and the hard work of implementation grinds on.
This is the execution chasm, and it is where most innovation efforts go to die. Not because the idea was bad, but because the organization lacked the technical platform to deliver it, or because the change required cross-functional collaboration that the culture could not sustain, or because the executive sponsor got promoted and the next one had different priorities. Design Thinking’s silence on these dynamics is not a minor limitation; for the mid-market, it is the whole ballgame.
Six Sigma and the Variance Paradox
Six Sigma is spectacularly good at what it was designed to do: reduce variation in manufacturing processes, eliminate defects, and drive cost out of operations. For the operational core of a business, these are worthy objectives. No one wants their supply chain or their financial reporting to be “creative”.
The paradox is that innovation is variance. Every new idea, by definition, deviates from the established process. Every experiment produces results that do not conform to the existing control charts. When an organization internalizes the Six Sigma mindset so thoroughly that variance becomes culturally synonymous with failure, it creates an environment where innovation cannot survive. People who propose unproven approaches are perceived as reckless. Projects that do not have clear, measurable outcomes from day one are deprioritized. The entire system selects for incremental improvement and against the kind of exploratory work that produces breakthroughs.
The human cost is significant. In a Six Sigma culture, the most creative and strategically ambitious employees learn to keep their ideas to themselves. They have watched what happens to colleagues who proposed something genuinely new; the proposal got benchmarked, measured against existing metrics, found to lack sufficient ROI justification, and quietly shelved. Over time, the organization’s innovation capacity does not just stall; it atrophies. The people who might have driven transformation either conform to the efficiency mindset or leave for environments that value imagination.
Disruptive Innovation and the Paralysis Problem
Clayton Christensen’s work on disruption is among the most important contributions to business strategy in the past fifty years. His observation that successful companies fail not because they are poorly managed but because they are well managed, optimizing for existing customers while ignoring the low-end entrants who will eventually eat their market, remains profoundly relevant.
The unintended effect on mid-market executives, however, has often been paralysis rather than action. Disruption theory, as commonly understood, is essentially a threat narrative: somewhere out there, a startup is building the thing that will make your business irrelevant, and by the time you see it clearly, it will be too late. This framing, while analytically accurate, offers the executive very little in the way of a constructive response. It tells you what to fear. It does not tell you how to build.
For a mid-market CEO, the productive question is not “how do I avoid being disrupted?” but rather “what capabilities can I build that would allow me to be the one doing the disrupting?” That question requires a fundamentally different orientation: not defensive vigilance but offensive investment in technology, data, and the human capital required to leverage both. Christensen’s framework diagnoses the disease beautifully. It does not prescribe the treatment.
Jobs to be Done and the Scale Problem
Jobs to be Done is perhaps the sharpest tool in the innovation toolkit for understanding customer motivation. Its core insight, that customers do not buy products but rather hire solutions to accomplish specific “jobs” in their lives, cuts through the noise of demographic segmentation and feature-based competition to reveal what actually drives purchase decisions.
The limitation is that JTBD is a demand-side framework operating in a supply-side world. Knowing what job the customer needs done does not tell you how to build the organization, the technology platform, the data infrastructure, and the governance model required to deliver that solution at a price point, quality level, and speed that makes the business viable. Bridging the gap between customer insight and organizational capability is the hard part; JTBD has almost nothing to say about it.
For midsize companies in particular, the constraint is rarely insight. Most executives have a reasonably clear understanding of what their customers need. The constraint is capability: can the organization actually build and deliver the thing the customer wants, in a way that is sustainable, scalable, and defensible? That question requires a strategic technology roadmap, not just a customer research framework.
The Common Thread
The pattern across all seven frameworks is consistent. Each one captures a genuine piece of the innovation puzzle: iteration speed, development agility, market positioning, user empathy, process quality, competitive dynamics, customer motivation. None of them adequately addresses the human and organizational infrastructure that determines whether any of these pieces actually fit together inside a real company.
Innovation in the mid-market is not primarily a methodology problem. It is a leadership problem, a trust problem, a culture problem, and increasingly a technology-capability problem. The frameworks treat innovation as though it can be proceduralized; as though following the right steps in the right order will reliably produce transformative outcomes. What they miss is that innovation emerges from environments where people feel safe enough to challenge assumptions, where cross-functional collaboration is genuine rather than performative, where leadership provides strategic direction without micromanaging execution, and where the technology platform is robust enough to support experimentation without collapsing under the weight of technical debt.
These are not conditions that any single framework can create. They are conditions that require sustained, strategic leadership; the kind of leadership that treats technology and culture as two dimensions of the same challenge rather than separate domains to be managed independently.
The question for mid-market leaders is not “which framework should we adopt?” It is a more fundamental one: Are we asking the right questions about innovation in the first place? If every question your organization asks about technology starts with “how do we reduce cost” or “how do we improve efficiency”, then no framework, however sophisticated, will produce genuinely innovative outcomes. The frameworks are answering the questions you are asking; this is why Innovating Beyond Efficiency is so focused on refining the questions.
