That distinction becomes decisive in enterprise settings.  Established organizations do not merely need to demonstrate feature. They need something than can be operated, adopted, governed, measured, and improved.  MIT CICR describes business components as combinations of people, process, data, and technology, while its operating-model research emphasises process integration, standardization, and critical capabilities. TOGAF explicitly treats architecture as a vehicle for capability-based planning, and the Business Architecture Guild treats capability maps and value streams as instruments for identifying gaps and prioritizing change.  BABOK adds the disciplines of traceability, requirements architecture, acceptance criteria, and solution evaluation.  The cumulative implication is that enterprise viability is broader than software scope (Ross, 2005; Ross, Beath and Nelson, 2020; Woerner, Sebastian and Weill, 2022; The Open Group, 2009; The Open Group, 2022; Business Architecture Guild, n.d.; IIBA, 2025).

This paper therefore argues for a more useful enterprise framing:  Minimum Viable Capability.   No specific source found for a canonical, standard definition of that exact phrase in the "bodies of knowledge (aka BOK); the definition used here is an analytical synthesis of Lean Startup, business architecture, enterprise architecture, requirements management, and AI-governance literature.  In this synthesis, a Minimum Viable Capability is the smallest coherent combination of process, people, data, technology, controls, adoption, and measurement needed for a business function to operate and produce evidence of value.   That sysnthesis is increasingly important in AI-enabled delivery, where prototyping is cheap but operational trust, data quality, governance, and organizational adoption remain difficult and value-limiting (Teece, Pisano and Shuen, 1997; Eisenhardt and Martin, 2000; Venkatesh et al., 2003; NIST, 2023; Gartner, 2024; McKinsey, 2025; BCG, 2026; Deloitte, 2026).

The Meaning of MVP
In Lean Startup thinking, the MVP exists to reduce uncertainty.  Riess's formulation is well known: it is the version of a new product that allows a team to collect the maximum amount of validated learning with the least effort.  The build-measure-learn loop matters because startups and innovation teams begin with hypothesis, not facts.  Blank's customer-development work reinforces the point:  an MVP is a method for learning who customers are, what they value, and what they will adopt or pay for.  In that view, and MVP can legitimately be a storyboard, a demo, a mock-up, or another instrument of hypothesis testing rather than a fully operational service (Ries, 2011; Ries, 2023; Blank, 2023; Blank, 2025; Blank, 2020).

This original meaning is narrower than many enterprise leaders assume.  MVP was designed to answer a learning question:  what is the minimum artefact required to test a business hypothesis? It was not designed, on its own, to answer an operating question:  what is the minimum set of organizational conditions required to run this safely and effectively inside a real enterprise? Agile sources sharpen the contrast.  The Agile Alliance's definition tracks Ries's learning logic, while Scrum insists that each increment should be additive, verified, aligned to a Product Goal, and unsable.  Agile also recognizes a related construct, the Minimum Marketable Feature, which is a small, self-contained feature that delivers significant user value.  Useful as that is, it is still feature-oriented, not capability-oriented (Agile Alliance, n.d.; Schwaber and Sutherland, 2020).

In a startup pursuing product-market fit, that distinction may be acceptable. In an enterprise, it is often a false economy.  A thin product slice may be sufficient to test desireability; it may be wholly insufficient to test whether the organization can actually deliver the outcome repeatedly, under real workloads, with acceptable risk and measurable value.  Blank's own warning that an MVP is not a "cheaper product" is best read as a caution against this kind of category error (Blank, 2013; Ries, 2023).

Enterprise Limits and the Case fo Minimum Viable Capability
Enterprise delivery operates inside an existing operating model. MIT CISR's long-running research is especially useful here.  It defines an operating model as the level of business-process integration and standardization necessary for the enterprise and, in later research, defines a business component as a unit of accountability consisting of people, process, data, and technology.  Those are not merely implementation details.  They are the substance of an operational capability. If a release does not address that combination at least minimally, it may still be a product increment, but it is not yet an enterprise capability (Ross, 2005; Ross, Beath and Nelson, 2020).  
‍

TOGAF arrives at a similar conclusion from an architecture perspective.  The Open Group describes TOGAF as a method for defining and planning enterprise transformation grounded in capability-based planning, and its guidance links prioritized capabilities to business drivers.  The Business Architecture Guild extends that logic through capability maps, value streams, stakeholder maps, information maps, and organization maps; its public material explicitly presents capability maps as a launch point for gap identification, future-state prioritization, impact analysis, and even solution deployiment.  That is precisely the terrain where traditional MVP thinking becomes too narrow for enterprise use (The Open Group, 2009; The Open Group, 2022; Business Architecture Guild, n.d.).

BABOK adds the delivery disciplines that make viability testable.  Traceability helps maintain relationships between requirements, designs, and solution components; requirements architecture shows how elements work together to support business objectives; acceptance and evaluation criteria define what must be true for a solution to be acceptable; and solution evaluation measures the value actually delivered in use.  These are not administrative add-ons. They are the mechanisms by which a release stops being an attractive demo and becomes an accountable business intervention (IIBA, 2025; IIBA, n.d.-a; IIBA, n.d.-b; IIBA, n.d.-c; IIBA, n.d.-d).

The academic literature supports the same shift. Dynamic capabilities research treats competitive adaptation not as a static asset stock but as the firm's capacity to integrate, build, and reconfigure resources through identifiable organizational processes. Technology-adoption research likewise shows that use depends not only on perceived usefulness but also on facilitating conditions, social influence, and other contextual factors.  In other words, capability is never only technical; it is socio-technical, and organizational. A release that lacks the conditions for use is not truely viable, however elegant the code may be (Teece, Pisano and Shuen, 1997; Eisenhardt and Martin, 2000; Venkatesh et al., 2003; Rogers, 2003).

A more defensible enterprise question is therefore not, "What is the smallest product we can build?" but, "What is the smallest business capability we can put into operation with acceptable risk, adoption, and measurable value?"  That is the logic of Minimum Viable Capability.

What Makes a Capability Viable
A capability becomes viable when the organization can perform a business function coherently enough to learn from real use without losing operational control.  In practical terms, that means at least six elements must be minimally present:  a defined outcome, an executable process, accountable roles, fit-for-purpose data and technology, proportionate governance and controls, and live measurement.  Scrum's "useable increment" establishes a floor, while MIT CISR, TOGAF, the Guild, and BABOK explain why usability in enterprise settings extends beyond interface behavior to process integration, organizational accountability, and measurable value realization (Schwaber and Sutherland, 2020; Ross, 2005; Ross, Beath and Nelson, 2020; The Open Group, 2009; Business Architecture Guild, n.d.; IIBA, 2025).

The important discipline is minimal coherence, not maximal completeness.  A minimum Viable Capability is not a disguised waterfall release and not the end-state target architecture.  It is a narrow operational slice: one outcome, one segment, one value stream step, one control regime, one metric set, small enough to deliver quickly, but complete enough to run credibly.  That balance matters because over-scoping destroys speed, while under-scoping destroys trust and learning (Blank, 2021; Agile Alliance, n.d.; Gartner, 2024).

Practical Examples
Customer Self-Service Portal
A conventional MVP for a customer self-service portal might include a login screen, an account summary, and a digital request form.  That may be enough to test whether customers prefer a digital channel over phone or email.  But is is not yet a customer self-service capability.  To become viable, the release needs at least bounded identity management, service taxonomy, routing rules, acknowleedgement messages, exception handling, operational ownership, support procedures, and a measurement set such as adoption rate, contact deflection, first-contact resolution, and cycle time.  Without these elements, the organization has created an interface, not a service capability (Ross, Beath and Nelson, 2020; Business Architecture Guild, n.d.; IIBA, 2015; Venkatesh et al., 2003).

The right Minimum Viable Capability would still be small.  For example, the organization might launch only one request type, such as address changes for retail customers in one region, but include the full operational chain:  authentication, validation, routing, exception handling, notifications, dashboarding, and a small support playbook.  That release is narrower than the end-state portal, yet much stronger than a thin MVP because it allows the business to observe live adoption, throughput, defect rates, and channel-shift economics uner real conditions.  It converts "Will customers click?" into the more valuable question, "Can we deliver this service end to end with acceptable quality and measurable benefit?" (Schwaber and Sutherland, 2020; IIBA, n.d.-d; Rogers, 2003).

Finance Automation
Finance automation exposes the problem even more sharply because control failure is costly.  A thin MVP might automate invoice classification on one screen or use AI to pre-populate coding suggestions.  That can demonstrate technical feasibility, but it does not yet constitute a viable finance capability.  A minimum viable finance capability would usually require confidence thresholds, segregation of duties, approval paths, audit trails, exception queues, reconciliation logic, cut-off rules, and a fallback manual path.  It would also require metrics such as touchless processing rate, exception rate, processing time, error rate, control breaches, and user override frequency (IIBA, 2025; IIBA, n.d.-c; NIST, 2023; Gartner, 2025).

Again, the capability slice can remain tight.  A prudent first release might focus on one invoice class, one business unit, and one approval threshold.  But if month-end control, auditability and exception handling are absent, the organization is not learning about operational value; it is merely staging a demo. In finance and other regulated domains, the lesson is blunt, the fastest route to production is rarely the thinnest screen.  It is the smallest slice that can survive contact with real governance and real users (The Open Group, 2009; IIBA, n.d.-a; NIST, 2023).

Why AI Raises the Bar
AI changes the economics of delivery, but not the logic of viability.  Generative AI hasaccelerated experimentation across software development, customer service, and knowledge work, and software development remains one of the most active functions for enterprise GenAI investment. Yet the evidence from industry research is consistent: the unresolved challenge is not getting from zero to prototype; it is getting from pilot to scaled, governed, measurable value.  Gartner warned that at least 30 percent of GenAI projects would be abandoned after proof of concept because of poor data quality, in adequate risk controls, escalting costs, or unclear business value. Deloitte now frames the enterprise problem as moving beyond experimentation to embedding AI, governing it responsibly, and producing measurable value over time.  BCG reports that only a small minority of firms are capturing meaningful value from AI at scale, largely because operating models were not built for it (Gartner, 2024; Gartner, 2024b; Deloitte, 2026; BCG, 2026; McKinsey, 2025).

NIST's AI Risk Management Framework explains why.  The AI RMF is built around Govern, Map, Measure, and Manage. and NIST's playbook explicitly connects AI governance to existing organizational governance, data governance, risk mapping, standards for experimental design, data quality, and documented intended uses.  NIST also defines trustworthy AI in terms that go far beyond model accuracy alone, including validity, reliability, safety, security, resilience, accountability, transparency, explainability, privacy, and fairness.  For GenAI-enabled software delivery, NIST SP 800-218A adds a practical reminder:  AI-generated code should be evaluated before use just as rigorously as human-written code (NIST, 2023a; NIST, 2023b; NIST, 2024).

The strategic implication is clear.  As AI makes prototyping cheaper, the bottleneck shifts toward business intent, data fitness, control design, adoption, and measurement.  Minimum VIable Capability therefore becomes more important, not less important.  In an AI-enabled enterprise, building the wrong thing quickly is easier than ever; building the right thing so that it operates responsibily and creates value is still hard. McKinsey's survey research reaches a compatible conclusion: organizations that capture AI value at scale do so through coordinated practices spanning strategy, talent, operating model, technology, data, and adoption, not through tooling alone (McKinsey, 2024; McKinsey,, 2025; BCG, 2025; Deloitte, 2026).

How to Define and Delivery Minimum Viable Capabilities
The practical method is to design delivery around a capability hypothesis rather than a feature hypothesis. Start with one business outcome and make it measurable.  Then define the minimum end-to-end slice required to achieve that outcome for a bounded user segment or scenario.  That slice should specifiy the process trigger, major decision points, accountable roles, required data, supporting technology, essential controls, acceptance criteria, and outcome metrics. BABOK's traceability and requirements architecture are useful here because they connect business need, requirements, design elements, and solution components in a way that supports change control and impact analysis (IIBA, n.d.-a; IIBA, n.d.-b; IIBA, n.d.-c).

Release discipline also changes. In a Minimum Viable Capability model, the Definition of Done cannot be limited to feature behavoir.  It should incliude the minimum conditions for live use:  role clarity, data integrity, control readiness, support readiness, and instrumentation of value metrics.  A phased rollout is often the best compromise between speed and safety:  one segment, one geography, one product class, or one transaction type.  That approach reduces scope without deferring the core realities of use.  It also mitigates one of the most common enterprise risks: "demo success, operational failure" (Schwaber and Sutherland, 2020; IIBA, n.d.-d; Rogers, 2003; Venkatesh et al., 2003).

The main risk and mitigations are now easier to state clearly.  Scope inflation occurs when teams interpret "capability" as "full transformation"; mitigation is to slice narrowly around one outcome and one value stream fragment.  Operational fragility arises when support, controls, or exception handling are deferred; mitigation is to make them part of the minimum release criteria. Adoption failure occurs when users lack training, incentives, or facilitating conditions; mitigation is to plan pilot, communications, support, and role changes as first-class delivery work.  AI-specific failure arises when intended use, data governance, and oversight are vague; mitigation is to apply the AI RMF and proportionate testing, evaluation, verification, and validation before scaling (Venkatesh et al., 2003; NIST, 2023; Gartner, 2024; Deloitte, 2026).

For product and delivery organizations, this reframing has structural implications.  Product managers should define success in terms of operational outcomes, not only shipped scope. Architects should help shape bounded capability slices rather than distant end-state diagrams. Business analysts should strengthen traceability from intent to controls, data, and acceptance criteria. Operations, risk, compliance, and change leads should be involved earlier, but in a thinner, more selective way.  The goal is not heavier governance; it is earlier, smalled, better-targeted governance.  This is how organizations increase delivery speed without externalizing risk into production (Ross, Beath and Nelson, 2020; The Open Group, 2009; IIBA, 2015; Gartner, 2024).

Conclusion
MVP remains a valuable idea, but in enterprise settings it is often interpreted too literally and too narrowly.  Its original purpose was to accelerate learning under uncertainty.  That purpose still matters.  The problem is that enterprise organizations must learn not only whether a feature is desirable, but whether a capabilty can operate coherently inside a live business.  That requires attention to process, people, data, technology, governance, controls, adoption, and measurement.  The strongest modern question is therefore not, "What is the smallest product we can build?" It is, "What is the smallest viable capability we can put into the organization that can operate, be adopted, be governed, be measured, and create value?" Organizations that answer that question well will combine speed with operational clarity, and will scale change more successfully as AI accelerates the pace of delivery (Ries, 2011; Ross, Beath and Nelson, 2020; NIST, 2023; McKinsey, 2025).

How Requirementum QGR Helps
Requirementum QGR can support this shift by helping organizations define the smallest release that is not merely buildable, but operationally meaningful.  In practice, that means clarifying business intent, capability scope, process impacts, stakeholder roles, data and integration needs, traceable requirements, acceptance criteria, governance points, and measurable outcomes before delivery accelerates.  Through Intentium, it's AI-enabled delivery approach, Requirementum QGR can help structure business intent, process models, rules, decisions, and validation criteria so that delivery teams and AI tools work toward coherent business outcomes rather than isolated artefacts.

REFERENCES
Agile Alliance (n.d.) ‘What is a Minimum Viable Product (MVP)?’ Agile Alliance Glossary.
Agile Alliance (n.d.) ‘What is a Minimum Marketable Feature (MMF)?’ Agile Alliance Glossary.
BCG (2025) Are You Generating Value from AI? The Widening Gap.
BCG (2026) Design Your Company for AI, Not AI for Your Company.
Blank, S. (2013) ‘An MVP is not a cheaper product, it’s about smart learning’, Steve Blank, 22 July.
Blank, S. (2015) ‘Why build-measure-learn isn’t just throwing things against the wall and see if they work’, Steve Blank, 6 May.
Blank, S. (2020) ‘Customer discovery in the time of the Covid-19 virus’, Steve Blank, 7 April.
Blank, S. (2021) ‘A path to the minimum viable product’, Steve Blank, 20 April.
Business Architecture Guild (n.d.) The BIZBOK Guide.
Business Architecture Guild (n.d.) Industry Reference Models and Companion Guide.
Business Architecture Guild (n.d.) ‘Business Architecture and SAFe: The courtship begins’.
Dearing, J.W. (2009) ‘Applying diffusion of innovation theory to intervention development’, Research on Social Work Practice, 19(5), pp. 503–518.
Deloitte (2026) Beyond Pilots: Transforming IT for AI at Scale.
Eisenhardt, K.M. and Martin, J.A. (2000) ‘Dynamic capabilities: what are they?’, Strategic Management Journal, 21(10–11), pp. 1105–1121.
Gartner (2024a) ‘Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025’.
Gartner (2024b) ‘Gartner survey reveals only 48% of digital initiatives are successful’.
Gartner (2025) ‘How Business Architects Can Help Design Strategic Portfolios Through Capability-Based Planning’.
Gartner (2025) ‘How to Scale Your Finance AI Pilots’.
IIBA (2015) A Guide to the Business Analysis Body of Knowledge Version 3.
IIBA (n.d.-a) ‘Trace Requirements’.
IIBA (n.d.-b) ‘Define Requirements Architecture’.
IIBA (n.d.-c) ‘Acceptance and Evaluation Criteria’.
IIBA (n.d.-d) ‘Measure Solution Performance’.
IIBA (n.d.-e) ‘Solution Evaluation’.
McKinsey & Company (2024) The State of AI in Early 2024: Gen AI Adoption Spikes and Starts to Generate Value.
McKinsey & Company (2025a) How COOs Maximize Operational Impact from Gen AI and Agentic AI.
McKinsey & Company (2025b) The State of AI: Global Survey 2025.
NIST (2023a) Artificial Intelligence Risk Management Framework AI RMF 1.0.
NIST (2023b) AI RMF Playbook.
NIST (2024) Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: NIST SP 800-218A.
Ries, E. (2011) The Lean Startup. New York: Crown Business.
Ries, E. (2023) ‘What is an MVP?’, Lean Startup Co.
‍Rogers, E.M. (2003) Diffusion of Innovations. 5th edn. New York: Free Press.
Ross, J.W. (2005) ‘Forget strategy: focus IT on your operating model’, MIT CISR Research Briefing.
Ross, J.W., Beath, C.M. and Nelson, R.R. (2020) The Digital Operating Model: Building a Componentized Organization. Cambridge, MA: MIT CISR.
Schwaber, K. and Sutherland, J. (2020) The Scrum Guide.
Teece, D.J., Pisano, G. and Shuen, A. (1997) ‘Dynamic capabilities and strategic management’, Strategic Management Journal, 18(7), pp. 509–533.
The Open Group (2009) TOGAF Version 9.
The Open Group (2022) The TOGAF Standard, 10th Edition.
Venkatesh, V., Morris, M.G., Davis, G.B. and Davis, F.D. (2003) ‘User acceptance of information technology: toward a unified view’, MIS Quarterly, 27(3), pp. 425–478.
Woerner, S.L., Sebastian, I.M. and Weill, P. (2022) Develop Ten Capabilities to Accelerate Digital Transformation. Cambridge, MA: MIT CISR.
‍