How do I design and continuously improve our delivery model to drive margin?

A methodology is not a delivery model

Asked to describe their delivery model, most firms produce a methodology: a slide explaining how they do the work, a few templates, some war stories. That is a component, not a system.

A delivery model is the set of decisions that make expertise commercially viable, operationally feasible and economically durable. What problem does this solve and for whom. What exactly is being sold, and what is explicitly not. How is value created, measured and communicated. How is it delivered consistently without heroics. Where does customization add value, and where does it destroy margin.

These are interconnected. A pricing choice constrains delivery feasibility. Delivery design constrains margin. What sales promises constrains operational complexity. Answer them in isolation and the answers will contradict each other, which is why firms can feel chaotic even when individual projects go well.

Design the architecture, not just the method

Five architectural decisions are where margin is won or lost.

Define the offer as an outcome rather than a set of activities. Activities invite the client to compare your hours to someone else hours. Outcomes invite them to compare your result to the cost of not having it.

Draw explicit scope boundaries. What is in and what is out, written down, before the work is sold. Scope that was never bounded cannot be enforced later without a fight.

Build from reusable components. Design the parts that recur across clients once. Greg Alexander is blunt about the alternative: a firm where every engagement is a one-off cannot staff itself correctly, because it never knows what skills it will need, which forces the owners and a handful of stars to do most of the work.

Write rules for customization. Custom work is not the enemy. Unbounded custom work is. The question is where variation genuinely creates client value and where it just multiplies delivery complexity for the same fee.

Name what the client has to contribute. Many models assume client inputs, access and decisions that were never contracted for, and the cost of waiting lands on your margin.

The test Alexander applies is worth adopting: services that cannot be delivered without heroics are not finished designs. If the model only holds together when your strongest person intervenes, you have designed a dependency rather than a service.

Be imaginative about delivery

Most boutiques are conventional here. They convert expertise into a methodology, train staff to apply it, and deliver it with expensive labor and very little automation. The result is a service that is expensive and hard to sell, which caps growth.

Alexander tells the story of a bookkeeper who let small business owners outsource bookkeeping for 9.99 dollars a month, combining automation with offshore labor, against competitors charging hundreds for something similar. She was doubling revenue and profit annually. He tried to invest and she did not need the money. He calls her the one that got away.

The principle underneath is that clients hire a boutique because you can do what they do better, faster or cheaper, measured against the alternatives rather than in the abstract, and those alternatives include doing nothing and doing it in-house. The strongest position combines all three.

Structurally, three mechanisms decouple revenue growth from headcount growth. Services become technology-enabled, so work people used to do is performed by systems. Labor moves offshore, where the market leaders run roughly forty percent of their work and boutiques run less than five percent. And gig networks let a firm flex capacity to match demand rather than carrying it. The best boutiques are not the ones with the most employees. They are the ones with the most free cash flow.

Prove the model can actually be delivered

This is where service designs most often collapse. The design assumes delivery will figure it out, delivery inherits promises it did not help make, and the result is friction, rework and margin erosion that looks like an execution failure but was a design failure.

Stress-test before launch rather than after. Are the required skills available at the level the model assumes, and can they scale. What is the realistic cycle time from start to outcome. How is quality controlled, and by whom. Where are the predictable failure points, and will the client hit them before you do. Which parts are performed by people and which by systems, decided deliberately rather than discovered mid-engagement.

The diagnostic that exposes an unstandardized model is cash flow per project. When Capital 54 looked at a commercial photography boutique, some projects produced strong cash flow and others were negative. The conclusion was not that the firm picked bad work. It was that the delivery model was not standardized and therefore not scalable. They passed.

Two further notes. Procedure manuals for the delivery staff are what let work be assigned to teams strategically rather than reactively. And output quality is only half of what sophisticated clients buy: quality is measured by the finished product, service by how the client feels while working with you, and far fewer firms deliver the second. Put it inside the model rather than alongside it, by laying the client emotional journey on top of the operating procedures.

Run improvement as a loop

Continuous improvement is not an initiative. It is a set of feedback mechanisms that run whether or not anyone is paying attention, fed by client and market reality rather than internal opinion.

Four mechanisms do most of the work. A client advisory board of roughly ten clients, half current and half former, meeting twice a year with prework, where the clients present and you listen. Post-project reviews on every engagement, run by someone who was not on the team, covering objectives, profitability, timelines, budgets and adherence to procedure. A client satisfaction program after every project, covering service as well as quality. And a quarterly win-loss program run by a third party, because losses reveal holes no internal review will surface. Alexander cautions that generic tools such as Net Promoter Score are too coarse and too easily gamed to be useful for boutiques.

The evidence that the loop is running is observable, and it is the same list an acquirer works through in diligence. Methodologies under version control. Employees progressively certified. Existing clients paying more for the same service, which is the clearest proof that quality went up, because the client validated it with money. Client satisfaction trending up rather than flat for a decade. Profit margins trending up, which requires that revenue and headcount growth have come apart. And the purest signal, the quality of the client roster: a firm whose clients three years ago were companies the prestigious firms would not touch, and whose clients today are names people recognize, is improving.

What Era 3 changes

Productization was the Era 2 answer to this question, and it was the right one for its time. Eisha Armstrong work through Productize, Fearless and Commercialize, and through Vecteris, helped a generation of labor-intensive firms take their first step out of Era 1. The core insight, that custom work does not scale, remains correct. It forced clarity about what was being sold, reduced delivery variability, made fixed and recurring pricing viable and improved margin predictability, and for firms in slow-adopting industries it is still a valid and often sufficient step.

Its limit was feasibility rather than thinking. Productization assumed the hard work of service design, meaning research, synthesis, packaging, testing, documentation and iteration, would still be done by humans supported by tools. It made the job more structured without making it lighter.

What changes in Era 3 is the cost of the loop. Sales conversations, lost deals, delivery artifacts, pricing outcomes, margin data and client behavior can be synthesized continuously rather than episodically, so degradation is detected while it is cheap to fix, economics can be modeled before a service goes to market, and feasibility can be stress-tested against real constraints rather than assumed. Much of the Era 2 apparatus of workshops, stage gates and periodic portfolio reviews existed to compensate for the absence of continuous signal, and becomes lighter when the signal is there. The constraint moves from bandwidth to judgment: deciding which problems are worth solving, where standardization should stop, and which tradeoffs to accept becomes the scarce input rather than the deferred one.

When this answer flips

A firm still validating what the market will pay for should not standardize prematurely. Locking a model around three engagements encodes your sample rather than the market.

Standardization also has a ceiling that depends on what you sell. Where the value genuinely is bespoke judgment on high-stakes problems, over-engineering the model strips out the thing clients are paying for. The lever there is fee level through specialization rather than delivery efficiency.

And in industries that adopt slowly, because of regulation or conservative buyers, Era 2 productization is the right destination for now. Skipping ahead to an AI-native model in a market that will not accept it is a way to be early and wrong at once.

The short answer

Treat the delivery model as a system rather than a methodology. Define the offer as an outcome, draw explicit scope boundaries, build from reusable components, write rules for where customization is permitted, and name what the client has to contribute. Stress-test feasibility before launch, because a service that needs heroics is not finished, and watch cash flow per project, because wild variation means the model will not scale. Be imaginative about delivery mechanics, since technology enablement, offshore capacity and gig networks are what decouple revenue growth from headcount growth. Run improvement as a permanent loop of client advisory board, post-project reviews, client satisfaction and win-loss, and judge it by version-controlled methodologies, existing clients paying more, rising margins and an improving client roster. In Era 3 that loop gets cheaper and faster, which makes judgment about what to standardize the binding constraint.