The Smallest Useful Piece | Applied BA Cookbook

This article is part of the Applied Business Architecture Project at StephenKlahr.com, where I maintain the free Business Architecture Cookbook, field notes, tools, study resources, and practical material focused on applying business architecture in real organizations. Everything is available without registration.

Most scope problems are not caused by people who are incapable of prioritizing. They are caused by people who have learned, often correctly, that anything omitted from the current initiative may never return to the funding queue.

When business leaders hear “we can put that in phase two,” many of them translate it as “this will never happen.” They have seen priorities change, funding disappear, project teams dissolve, and backlogs become graveyards. From their perspective, adding one more requirement may be the only reliable way to protect an important need.

That behavior is frequently described as gold plating, but the underlying incentive is more complicated. Some additions are genuinely unnecessary. Others represent an attempt to manage uncertainty, satisfy a stakeholder coalition, protect against a known operational risk, or take advantage of a rare window in which the organization is willing to invest.

Telling the business to “focus on the MVP” rarely solves the problem. A better approach is to make the smaller delivery credible, useful, measurable, and safe. The business must be able to see how the first piece produces an actual outcome, how much value it is expected to generate, how deferred needs will be governed, and what evidence will trigger the next investment decision.

The objective is not to deliver the smallest amount of work. It is to deliver the smallest useful piece that produces measurable business value.

Small Does Not Mean Incomplete

A small release is not a partial process that leaves the user stranded halfway through the value stream. It is not a database without a usable workflow, a dashboard without an intervention process, or a front end that depends on uncontrolled manual work behind the scenes.

The smallest useful piece is a narrow but complete change that allows a real user to achieve a real business outcome under defined conditions.

A useful framing is:

For a specific user, when a specific event occurs, enable a specific decision or action through a bounded portion of the value stream so that a measurable outcome can improve.

Consider a broad objective such as improving the handling of customer service requests. That objective could eventually encompass every request type, customer segment, user role, communication channel, reporting requirement, and supporting system.

The first useful piece might be much narrower. The organization could begin with one high-volume request type, give a defined group of employees a consistent method for receiving and assigning the work, establish an accountable owner, provide a standard resolution path, notify the customer, and measure the time required to complete the request.

That is still a complete business outcome. It crosses process, information, technology, roles, and measurement, but it does so for one bounded scenario. The organization can observe whether people use it, whether the workflow produces the intended behavior, and whether the outcome justifies expansion.

The scope is small. The delivery is not hollow.

Tie the First Release to Quantifiable Business Value

Whenever possible, the first release should be tied to an explicit and quantifiable value hypothesis.

That value might take the form of reduced operating expense, avoided labor, improved revenue capture, lower risk exposure, faster cycle time, fewer errors, improved capacity utilization, reduced customer attrition, or better regulatory compliance. The measure does not have to be perfect, but it should be concrete enough to support an investment decision.

A useful value statement identifies:

the current baseline;
the population or volume affected;
the expected change;
the financial or operational value of that change;
the assumptions behind the estimate;
the period over which the benefit should appear;
the person accountable for confirming the result.

Suppose a larger initiative is expected to eliminate 100,000 hours of annual manual effort. Analysis may show that one high-volume process variation represents 90,000 of those hours, while dozens of uncommon variations account for the remaining 10,000.

If the first release can capture 90 percent of the credible business value while avoiding most of the remaining complexity, that is often a win.

The organization should not assume that delivering the final 10 percent is automatically justified. The remaining work may still be valuable, but it should compete for investment based on its marginal benefit, cost, risk, and opportunity cost.

This is one of the most useful ways to challenge gold plating. Instead of asking whether an additional feature has value, ask how much incremental value it creates compared with the effort and complexity required to deliver it.

The first release might produce:

90 percent of the expected benefit for 40 percent of the effort;
80 percent of the benefit for one user group while avoiding a difficult enterprise integration;
most of the risk reduction through one policy and workflow change;
enough measurable value to fund the next increment from demonstrated results.

In those circumstances, the smaller release is not a compromise. It may be the economically superior design.

Business cases often emphasize the total potential value of the complete future state while failing to show how that value is distributed across features, users, scenarios, locations, or process steps. That makes every requirement appear equally necessary.

A better approach is to identify where the value is concentrated.

The business architect should ask:

Which users, customers, transactions, locations, or scenarios produce most of the benefit?
Which change removes the largest constraint?
Which requirements are necessary to realize value, and which merely improve the experience around it?
Where does the value curve begin to flatten?
What portion of the expected benefit can be realized before the most expensive dependencies are addressed?
At what point does the marginal cost of expansion exceed the marginal value?

The answer may reveal that the first release captures nearly all the available benefit. If so, the correct next decision may be to scale cautiously, redesign the remaining scope, or stop.

Finishing every item in the original concept is not the same as maximizing business value.

Begin With the Outcome, Not the Feature Inventory

Scope expands quickly when discovery begins with a request for requirements. Stakeholders naturally describe every feature they can imagine because they have not yet been given a basis for deciding which ones belong in the first delivery.

Beginning with the business outcome changes the conversation. Instead of asking what the solution should contain, ask what must be different after the first release.

What decision should someone be able to make that they cannot make today? What work should become faster, safer, more accurate, or less expensive? Which customer, employee, supplier, or partner should experience the improvement? How will the organization recognize that the change is working? How much of the total expected value can this first change reasonably produce?

Once the outcome and value hypothesis are clear, individual requirements can be tested against them. A proposed feature either contributes directly to the first outcome, addresses a legitimate operational or regulatory risk, enables measurement, or belongs to a later stage.

This does not make prioritization effortless, but it replaces general preference with a defensible decision rule.

A capability map can help identify what the organization must be able to do, while a value stream can show where the outcome is produced. Neither artifact should be treated as a release plan. The fact that a capability will eventually require significant maturity does not mean every component of that capability belongs in the first implementation.

The architecture describes the destination and the dependencies. The delivery sequence determines the smallest coherent path toward measurable value.

Constrain the Scope in Several Dimensions

Teams often try to reduce scope by removing a few features from a long list. That may lower the work estimate, but it does not necessarily produce a coherent first release.

A better approach is to constrain the initiative deliberately across several dimensions.

The first release might support one user group rather than every persona, one triggering event rather than every business scenario, one request type rather than every variation, or one business unit rather than the entire enterprise. It might cover the normal path while explicitly deferring rare exceptions, provided those exceptions have a safe fallback. It might use a bounded volume, a limited channel, or a defined operating period.

The best boundary is often the one that isolates the highest concentration of business value.

If one customer segment, business unit, process step, or transaction type produces most of the expected benefit, begin there. This gives the organization a better chance of proving value without carrying the cost and complexity of the entire enterprise scope.

These boundaries should be written into the scope, not left as informal assumptions. Otherwise, stakeholders will continue designing for the enterprise-wide future while believing they are discussing the first release.

A useful scope statement identifies:

the business outcome being pursued;
the quantifiable value expected from the first release;
the users and scenarios included;
the locations, channels, products, or transaction types covered;
the conditions deliberately excluded;
the measures that will determine whether the increment works;
the evidence required before the organization expands it.

The exclusions are as important as the inclusions. A scope statement that only describes what is being built leaves every adjacent need available for debate.

Slice Vertically Through the Business

One of the most common mistakes is reducing scope horizontally.

The team builds the data model first, plans the interface for a later release, postpones the operating process, and assumes training and support can be addressed near deployment. Considerable work may be completed, but the organization still cannot produce a business outcome.

The smallest useful piece should instead be a thin vertical slice through the business. It should include enough of the required capabilities, process, information, technology, policy, governance, measurement, and role clarity to make the outcome possible.

This does not require every component to be fully automated or scaled. A manual handoff may be reasonable during a bounded first release when the volume is controlled, the owner is known, the work is measurable, and an exit condition has been established. A temporary file transfer may be preferable to building a permanent integration before the organization has confirmed that the process itself works.

The danger is not manual work by itself. The danger is unmanaged manual work that becomes invisible operational debt.

A temporary workaround should therefore have an accountable owner, a capacity limit, a control mechanism, and a defined point at which it must be automated, redesigned, or discontinued.

The value measure also needs to account for the workaround. A release should not claim savings in one area while quietly transferring an equal or larger burden to another team.

Separate Essential Scope From Adjacent Value

Gold plating often hides inside requirements that are individually reasonable.

A dashboard would be useful. Additional configuration would provide flexibility. Another user group would eventually benefit. A more sophisticated integration would reduce future technical work. Expanded reporting would help executives understand the program.

The problem is not that these ideas lack value. The problem is that value alone does not determine sequencing.

For the first delivery, each proposed addition should be tested against four questions:

Is it required to produce the initial business outcome?
Is it necessary to operate safely, legally, securely, and reliably?
Is it necessary to measure whether the change works?
Does its incremental value justify its incremental cost, complexity, and delay?

When the answer to all four questions is no, the item may still be worthwhile, but it probably does not belong in the first piece.

This test also prevents teams from misclassifying essential quality as gold plating. Security, accessibility, regulatory compliance, data integrity, operational controls, and support readiness are not optional merely because they are not visible features. Small scope cannot become an excuse for reckless delivery.

The discipline is to keep the breadth of the release narrow while preserving the quality required for its intended use.

Make Every Addition Replace Something

Scope discussions remain theoretical when adding an item carries no visible consequence. Stakeholders can support a small release in principle while continuing to add requirements individually.

A fixed-capacity approach makes the tradeoff explicit. When someone proposes another item for the first release, the question is not simply whether it has value. The question is:

If we add this, what are we willing to remove or delay?

A second question should follow:

How much additional business value does this produce, and is that value worth delaying the benefits already within reach?

This shifts the conversation from advocacy to prioritization. It also makes the opportunity cost visible. A requirement is no longer competing against an abstract desire for speed. It is competing against another named outcome, feature, risk treatment, delivery date, or benefit.

The business architect can strengthen the discussion by showing two or three sequencing options rather than presenting one scope as a fait accompli. Each option should explain what the organization receives, how much value it is expected to produce, what it defers, what risks it accepts, and how soon it can begin generating evidence.

The recommendation should still be clear. Options are useful for exposing tradeoffs, not for avoiding judgment.

Understand Why the Business Is Gold Plating

A stakeholder who keeps adding scope may not be seeking perfection. The person may be responding rationally to the organization’s history.

If initiatives routinely lose sponsorship after the first release, stakeholders will fight to include everything now. If the backlog is rarely revisited, deferral will look like rejection. If executive attention depends on a large launch, the team will be pressured to make the first delivery appear more substantial. If multiple departments must support the initiative, each may demand its own requirements as the price of continued participation.

This is why scope control is partly a governance problem.

The organization needs credible decision rights. Stakeholders should be consulted, but someone must be accountable for deciding what enters the release. When every stakeholder possesses an informal veto, scope will expand until the initiative satisfies the most cautious or politically influential participant.

The team also needs a credible path beyond the first delivery. “Phase two” should not be a vague promise. Deferred work should have an owner, a rationale, a decision point, and a description of the evidence needed to reconsider it.

Not every deferred item deserves a future commitment. Some may prove unnecessary once the organization observes actual user behavior and realized value. The purpose of the backlog is not to guarantee that everything will eventually be built. It is to preserve the decision trail and ensure that legitimate needs are not quietly forgotten.

People are more willing to accept sequencing when deferral is governed rather than dismissive.

They are also more likely to accept a narrow first release when they can see that it captures most of the expected business value.

Show the Cost of Delay in Business Terms

Requests to reduce scope are often framed as delivery-team concerns. The work is too large, the timeline is under pressure, or the technical team lacks capacity.

Those may be valid constraints, but they are not always persuasive to the business. The stronger argument is that every additional item delays the first opportunity to produce value and learn from real use.

A proposed enhancement should therefore be translated into its consequence. Does it delay the first operational benefit? Does it postpone risk reduction? Does it extend the period in which employees remain dependent on a failing process? Does it defer revenue, savings, service improvement, or regulatory compliance?

Suppose an added feature delays implementation by three months while contributing only 2 percent of the expected benefit. The relevant question is not whether the feature would be useful. It is whether that incremental value justifies postponing three months of benefits from the remaining 98 percent.

The discussion should not imply that faster is always better. A rushed release that creates operational disruption can destroy more value than it creates. The objective is to make the relationship between added scope, delivery timing, risk, and expected benefit visible.

Once those consequences are explicit, the business can make an informed choice rather than treating every requirement as free.

Avoid the “Cheap MVP” Trap

The language of minimum viable products can be counterproductive in large organizations. Stakeholders sometimes hear “minimum” as underfunded, temporary, or low quality. Employees may assume the organization is asking them to tolerate another inadequate tool. Sponsors may worry that an intentionally narrow release will appear unimpressive.

Terms such as smallest useful increment, first complete slice, or minimum operationally viable scope often describe the intention more accurately.

The first piece should be respectable. It should solve a real problem for the users included in its scope. It should have clear ownership, adequate controls, usable data, operational support, and a way to measure the result.

It does not need to solve every related problem.

A small release earns trust when users can see that its boundaries were deliberate and that it produces meaningful value. A poor release loses trust when its limitations appear to be the product of careless planning or budget exhaustion.

A release that captures 90 percent of the available business value is not cheap, incomplete, or unserious merely because it omits the final 10 percent. It may reflect disciplined economic judgment.

Use Expansion Gates Instead of Assumed Rollout

Many initiatives describe a pilot but behave as though enterprise deployment has already been approved. The pilot becomes a ceremonial stage rather than an actual test.

A useful first delivery should lead to a decision. Before implementation, the team should define what evidence would support scaling, revising, pausing, stopping, or declaring the current scope sufficient.

The measures will vary, but they may include adoption, cycle time, error rate, customer outcome, employee effort, financial impact, operational stability, or control effectiveness. The measures should be closely connected to the original business outcome rather than selected because they are easy to collect.

The review should also examine unintended effects. A process may improve one measure by shifting work to another team. Automation may reduce handling time while increasing exceptions. A new workflow may appear successful only because experienced employees are compensating for design weaknesses.

Expansion should follow evidence, not momentum.

If the first release produces most of the expected value, the review should not automatically authorize the rest of the original scope. It should determine whether the next increment is still the best available use of organizational capacity and investment.

The organization may decide to:

expand the successful release to additional users or business units;
address a remaining high-value scenario;
redesign a costly low-value portion of the concept;
defer the remaining work until conditions change;
stop because the first release already captured sufficient value.

Stopping after a successful first release is not necessarily a failure of ambition. It may be evidence that the organization understands diminishing returns.

Questions That Keep a Working Session Focused

When scope begins expanding, a business architect can return the discussion to a small set of practical questions:

What is the first business decision or outcome we need to improve?
What is the baseline, and how will the improvement be quantified?
Which user, scenario, location, or transaction type contains most of the available value?
What percentage of the total expected benefit can the first release reasonably capture?
What must be included for the change to be safe, usable, and measurable?
What can remain manual or limited during a controlled first release?
Which conditions are explicitly outside the first scope?
What requirement would we remove if we added this one?
How much incremental value does the proposed addition create?
What evidence would justify expanding to the next user, scenario, location, or transaction type?
What result would tell us that further investment is not justified?
Who has the authority to make the final scope decision?

These questions work because they do more than challenge individual requirements. They establish a repeatable decision structure.

Scope Control Is Really Value-Based Sequencing

Good scope control does not begin by cutting random requirements. It begins by selecting a coherent path through the value stream and concentrating the first investment where it can produce the greatest credible benefit.

The business architect’s contribution is to preserve the strategic outcome while decomposing the change into pieces the organization can absorb, govern, measure, and evaluate. This requires more than drawing a smaller box around the solution. It requires understanding dependencies, operational readiness, stakeholder incentives, decision rights, value concentration, and the organization’s capacity to adopt change.

The smallest useful piece should produce an outcome, generate evidence, and create a credible foundation for the next decision. It should be narrow enough to deliver without carrying the entire future state on its back, but complete enough that the organization can judge whether it is moving in the right direction.

Scope control succeeds when stakeholders believe that smaller is a deliberate first move, not a quiet abandonment of their needs.

The goal is not to do less for its own sake. The goal is to deliver the first piece that is complete enough to use, small enough to learn from, and valuable enough to justify the investment.

When that first piece delivers 90 percent of the business value, the organization may already have won.

The remaining 10 percent should have to earn its place.

About the Applied Business Architecture Project

At StephenKlahr.com, I am building a free collection of applied business architecture field notes, practical tools, reference material, study resources, and working approaches for connecting strategy to execution. The focus is on methods that can be used in real organizations with real constraints, competing interests, and imperfect information.

Everything is available without registration at StephenKlahr.com.