The Delivery Delusion
Why Internal Digital Products Fail in Health Systems — Even When Delivery Succeeds
Executive Brief
If you enjoy this article, you can find the follow-up series, The Alignment Files, starting with the link to Part 1 of a 5-part series below.
In this series, I dig deeper into the root causes and whythis is one presentation of a broader problem for Product Managers in the Healthcare Digital domain of hospitals and health systems.
Why This Matters Now
Health systems are investing heavily in digital platforms, clinical tools, analytics, and workflow automation. Many of these initiatives are delivered on time, technically sound, and compliant—yet still fail to achieve sustained clinician adoption or meaningful operational impact.
This is not primarily a technology problem. It is a product judgment problem.
The Structural Problem in Health Systems
Health system IT and digital organizations have become highly effective delivery engines. Agile, SAFe, DevOps, and vendor implementation playbooks have professionalized execution. However, this success has created an imbalance: Delivery excellence has replaced product judgment as the primary success signal.
As a result:
Products, both vendor- and in-house-developed, are approved without rigorous validation of their clinical or operational value.
Go-live is treated as success.
Adoption struggles are blamed on “change resistance”.
Systems are maintained and persist long after their value has eroded.
Two Predictable Failure Modes in Healthcare Digital
1. Upstream Failure: Initiating Without Clinical or Operational Legitimacy
Initiatives are often approved based on executive sponsorship, strategic narratives, vendor positioning, or isolated complaints.
What is often missing is evidence of scale, clarity on the clinical or operational decision being improved, explicit tradeoffs, and a credible answer to: “What happens if we do nothing?”
Without this discipline, health systems activate expensive digital initiatives that were never positioned to deliver meaningful value.
2. Downstream Failure: Implementation Without Clinical Success
In healthcare, implementation is not success.
A system can be live, integrated, trained, and supported, and still fail because it disrupts clinical workflow, adds cognitive load, conflicts with professional judgment, or lacks trust.
Adoption becomes partial.
Advanced features go unused.
Failure is not technical; it is behavioral
The Bottom Line for Health Systems
Digital transformation fails when the organization mistakes activity (shipping features) for achievement (changing outcomes).
The Factory will always be loud; it demands to be fed.
Leadership’s role is not to speed up the line, but to assert the Upstream Judgment to validate the work and the Downstream Accountability to measure the result.
Internal product organizations do not fail because they lack the capacity to build; they fail because they build the wrong things efficiently.
When delivery excellence substitutes for clinical and operational impact, the result is a high-performing factory that generates expensive waste.
The true advantage lies in the organizational discipline to decide
A.) what not to build upstream, and;
B.) the rigor to ensure value is realized downstream.
The Persistent Paradox of “Successful” Failure
Across internal IT, digital, and informatics organizations, particularly within large healthcare and hospital systems, there exists a persistent and deeply frustrating paradox.
Product teams routinely deliver solutions that are technically robust, compliant with specifications, validated through testing, and deployed into production environments on schedule. From a delivery standpoint, these initiatives are frequently labeled as successes to be celebrated.
And yet, when examined over time, many of these same products fail to produce the outcomes that originally justified their existence. Users adopt them unevenly or reluctantly.
Advanced features remain unused. Workarounds persist. Stakeholders express dissatisfaction that the product is “not doing what we expected,” even though it is doing precisely what it was designed and built to do.
Eventually, the product becomes quietly sidelined—maintained, supported, and paid for, but no longer central to the work it was meant to improve.
This paper argues that these failures are neither accidental nor primarily technical. They are structural.
They arise from a deeply ingrained misplacement of emphasis within product organizations, where execution excellence has become the dominant—and often exclusive—measure of success.
The Factory as the De Facto Center of Gravity
Over the past two decades, internal product organizations have professionalized delivery at an unprecedented level.
Agile methodologies, scaled frameworks, DevOps practices, and modern engineering platforms have dramatically improved teams' ability to build and deploy software.
However, these same advances have also produced an unintended consequence: the delivery engine—the factory—has become the moral and operational center of the product system.
In practice, this manifests in subtle but powerful ways. Organizational language shifts toward throughput, velocity, and capacity. Funding models align around project delivery milestones. The factory becomes not just a mechanism for execution, but a justification for its own existence.
This paper does not argue that factory excellence is undesirable. On the contrary, without a capable factory, even the best product judgment cannot be realized.
The problem arises when factory operations crowd out two equally essential responsibilities: upstream judgment and downstream value realization.
Internal Products and the Illusion of “Non-Commercial” Work
A further complication in internal IT and digital organizations is the widespread belief that internal products are fundamentally different from commercial ones because they do not directly generate revenue.
In commercial environments, poor product decisions are punished quickly and visibly. Customers do not buy products they do not value.
Internal products lack this immediate feedback. They do not fail loudly. Instead, they fail quietly.
The absence of revenue does not mean the absence of economics. Internal products consume scarce and valuable resources: skilled labor, leadership attention, infrastructure, compliance effort, and opportunity cost.
The difference is not that internal products are non-economic, but that their economics are obscured. This obscurity makes disciplined product judgment harder, not less necessary.
Framing the Core Question
The central question this paper seeks to answer is not:
How can we deliver faster?
or,
How can we improve adoption through better training?
Those questions are downstream of a more fundamental one:
How do product organizations ensure that they are solving the right problems, and that the solutions they deliver actually produce sustained, meaningful value in the environments where they are deployed?
Why the Pragmatic Framework is the Right Reference—Even When It Is Resisted
The Pragmatic Institute Product Management Framework (Pragmatic) occupies a distinctive position in the contemporary product management discipline.
Unlike delivery-centric methodologies, Pragmatic does not define product management by ceremonies, artifacts, or roles. Instead, it defines product management by accountability across the full lifecycle of value creation, from problem discovery (left) through sustained market or organizational impact (right).
The Persistent Misinterpretation: “Too Commercial for Internal IT”
Pragmatic is frequently rejected by leaders in internal IT and digital organizations because the framework is perceived as “too commercial”. This objection conflates language with intent.
Pragmatic’s underlying philosophy is not revenue-centric; it is economics-centric.
Internal products do not escape economics simply because revenue is indirect or absent. They still require investment decisions, tradeoffs, prioritization, and lifecycle accountability.
What differs is not whether economics apply, but how value must be demonstrated.
Reframing Pragmatic for Internal Product Contexts
When translated appropriately, the Pragmatic framework aligns naturally with internal product environments. Upstream Pragmatic activities map cleanly to internal contexts when language is adjusted:
“Market” becomes population served or clinical domain.
“Customer” becomes user, clinician, operator, or stakeholder.
“Revenue potential” becomes patient outcome impact, cost avoidance, risk reduction, throughput improvement, or quality gain.
Crucially, Pragmatic insists that these questions be answered before the factory is activated.
Failure Mode 1: Upstream Initiation Without Legitimacy
We now turn to the first primary failure mode: upstream initiation without legitimacy.
This section examines how internal organizations routinely activate the factory without sufficiently validating whether a problem is real, material, and worth solving.
Upstream work is not primarily creative. It is discriminatory. Its purpose is to separate problems that are real, material, and worth solving from those that are merely plausible, fashionable, or politically convenient.
The Illusion of Demand and Political Sponsorship
In internal environments, demand is often inferred from requests, escalations, or executive interest, rather than validated through systematic inquiry. A common upstream error is to treat problem articulation as proof of problem legitimacy.
One of the most pernicious upstream failure patterns in internal IT is the substitution of political sponsorship for product judgment.
When a senior leader champions an initiative, questioning the underlying problem can be perceived as resistance rather than responsibility.
In such environments, upstream product management becomes performative, conducted to justify a predetermined decision rather than to interrogate its necessity.
The “Mandate Lane” and High-Risk Bypasses
The political reality of large health systems often means that some initiatives will inevitably bypass the full scrutiny of the validation gate due to a “strategic imperative” or the sheer political capital of a senior stakeholder.
The danger is not that these mandates exist, but that the risk is unacknowledged. If an initiative forces its way into the factory without upstream validation, the organization must explicitly log this as a “High-Risk Mandate.”
The logic is simple: By skipping the Upstream Safety Filter, the stakeholder is trading certain execution cost for uncertain value. The Sponsor, not the Product Team, must therefore retain accountability for the resulting adoption gaps.
The “Default to Build” Trap: Escaping the “You Hum It, We Code It” Mindset
A critical component of Upstream Judgment is the rigorous evaluation of how a validated problem should be solved. In mature product organizations, this is the Build/Buy/Partner decision matrix.
However, in many internal IT and digital organizations, this matrix has collapsed into a single default reflex: Build!
This phenomenon—often colloquially described as “You hum it, we code it”—stems from the Factory mindset. When an organization measures itself by the utilization of its engineering capacity, it subconsciously rejects “Buying” or “Partnering”, because those paths do not feed the Factory. They are viewed as “lesser” IT work, even when they will often offer faster time-to-value, lower maintenance burdens, and higher reliability.
The Product Manager’s Role as Solution Architect
Upstream responsibility requires decoupling the problem from the code. A Product Manager’s job is not to fill the engineering backlog; it is to solve the business problem.
Buy (SaaS/COTS): When the problem is standard (e.g., HR, ERP, CRM) and speed is paramount.
Partner: When a specialized third party can deliver the outcome with shared risk.
Build: Reserved only for problems that provide a unique competitive advantage or where no market solution exists.
When this discipline is missing, internal organizations build expensive, custom versions of commodities, creating massive long-term technical debt for problems that could have been solved with a subscription.
How Vibe Coding Exacerbates the “Build” Default
The danger of the “Default to Build” mindset is currently being amplified by the rise of AI-powered “Vibe Coding.”
In the past, the barrier to “building” was high: it required budget, architects, and developers. This friction sometimes forced a “Buy” decision. Today, AI tools have lowered the cost of initial code generation to near zero.
The Accelerator: A domain expert (doctor, researcher) who might have previously requested a vendor solution now feels empowered to “just build it myself” using AI.
The Consequence: This democratizes and distributes widely the “You hum it, we code it” fallacy. The Vibe Coder skips the market scan entirely. They assume that because they can generate the code, they should.
This results in a proliferation of “Micro-Builds”—custom, single-use applications that ignore established market platforms. The organization moves from “Default to Build” (at the enterprise level) to “Default to Code” (at the individual level), bypassing the Build/Buy/Partner analysis entirely and accelerating the accumulation of unmanaged shadow assets.
While often framed as innovation, this dynamic creates a Shadow Factory. Because the cost of “building” has dropped to near zero for these individuals, the natural economic friction that usually stops bad ideas vanishes.
The Trap: Organizations mistake a functioning script for a production-ready product.
The Reality: These tools escape the Upstream Safety Filter and the Factory’s architectural controls. They arrive downstream as technical debt disguised as innovation—unsecured, unintegrated, and unscalable.
To correct this, organizations must reframe Citizen Development not as “Product Delivery,” but as “Upstream Discovery and Validation.”
A user-built tool is not a product; it is a high-fidelity requirement. It serves as robust evidence of a problem, but it must still pass the Validation Gate before the central organization accepts the liability of supporting it.
The Missing Question…“What Happens If We Do Nothing?”
Practical upstream judgment requires explicitly asking: What happens if we do nothing?
If the answer is “inconvenience” or “frustration,” further scrutiny is required. Not all inefficiencies warrant product intervention74. Internal product teams often fail to articulate this counterfactual because they are structurally incentivized to build. Capacity seeks utilization.
Failure Mode 2: Downstream Delivery Without Value Realization
The False Equivalence of Delivery and Success
In internal product organizations, delivery is often treated as the terminal event of product responsibility. Once a solution is deployed, documented, and operationally supported, the organization shifts its attention elsewhere.
This behavior reflects a deeply ingrained but flawed assumption: that implementation is synonymous with success. From a technical standpoint, delivery confirms only that a system can function as designed. It says nothing about whether the system is used, whether it changes behavior, or whether it produces the outcomes and value that initially justified its creation.
Implementation is a Technical Event; Customer Success is a Social One
A central argument of this paper is that customer success, whether internal or external, is fundamentally a human and organizational phenomenon, not a technical one.
Implementation answers questions such as: Does the system work? Is it secure? Is it compliant?
Customer success answers very different questions: Do people trust it? Does it fit their workflow? Does it reduce friction or add to it? Is value, however measured, achieved?
The Absence of Ownership for Value Realization
Perhaps the most consequential downstream failure is the absence of clear ownership for value realization. Delivery teams own build. Operations teams own uptime. Training teams own onboarding. But no single role or function owns the question: Is this product delivering the value we expected, and if not, what will we do about it?.
This accountability gap allows downstream failure to persist indefinitely. Products remain in production because no one has both the authority and the mandate to declare them unsuccessful.
Why Customer Success Exists — and Why Healthcare Is Not Exempt
Why Commercial Organizations Created Customer Success
Customer Success did not emerge as a customer-experience enhancement or a rebranding of support. It emerged as a control function in organizations that discovered a structural truth: Delivery does not guarantee value.
In modern commercial models, organizations have learned, often painfully, that:
Selling a product does not ensure adoption.
Shipping a product does not ensure outcomes.
Training users does not ensure behavior change.
As revenue shifted from one-time transactions to recurring, outcome-dependent models, organizations faced a new risk: silent failure after delivery. Customer Success was created to close this gap by owning adoption beyond launch, proving value, and protecting the economic return on product investment by eliminating attrition and churn.
Why the Same Logic Applies to Health Systems
Health systems often reject Customer Success because they lack subscription revenue or explicit churn. But this difference is superficial. Health systems also invest heavily before value is proven and depend on sustained adoption to realize the benefit.
The absence of revenue does not remove the risk. It just removes the signal. In healthcare, value erosion does not appear as revenue churn. It appears as workarounds, partial feature adoption, parallel systems, and user abandonment.
The Core Insight
Customer Success exists because value is realized over time, not at delivery. Health systems need it because they routinely invest in products whose success depends on sustained human behavior change, and currently have no function that owns that risk.
Defining Customer Success in Healthcare
Customer Success in healthcare does not operate in a conventional commercial environment. Instead, it exists at the intersection of clinical behavior, operational workflows, institutional risk, and cultural trust.
Healthcare Customer Success can be defined as:
The ongoing responsibility to ensure that a delivered digital or clinical product is adopted in practice, integrated into real workflows, trusted by its users, and demonstrably contributing to the clinical or operational outcomes that justified its creation.
Outcome Realization and “Worth the Squeeze”
Healthcare Customer Success should exist to answer a single, uncomfortable question:
Was this product worth the total cost of discovering, building, deploying, operating, and sustaining it?.
In the absence of revenue, internal products require a different—but no less rigorous—test of success. This value may be indirect or qualitative, but it cannot be purely aspirational.
Conclusion: Reclaiming Product Judgment Beyond the Factory
This paper has argued that the most persistent failures of internal product organizations are not failures of execution. They are failures of judgment.
The factory runs efficiently—products ship.
And yet value either fails to arrive or quietly dissipates as user attrition occurs.
Reframing Product Management’s Highest-Order Responsibility
The fundamental responsibility of product management is to decide if and whether the factory should run, and to remain accountable until value is derived or outcomes are measurably demonstrated. This responsibility exists regardless of whether products are commercial or internal.
What Changes If This Thesis Is Taken Seriously
If the arguments of this paper are accepted, several practical shifts follow:
Initiation becomes a decision gate, not a formality: Product teams are empowered—and expected—to stop weak initiatives before incurring costs.
Delivery is re-centered as a means, not an end: Factory excellence remains critical, but no longer substitutes for product life cycle judgment.
Adoption and behavior change become product work: Not training artifacts or support afterthoughts, but integral design concerns.
Value realization must be owned, measured, and revisited: Even when imperfect, even if qualitative, and especially if uncomfortable.
The factory will always be loud. Judgment must be made louder.
SM