Founders ask Collective 54 this 11 times in our records. It is usually asked by a firm whose margins are being eaten by customization that nobody remembers agreeing to.
The confusion at the front of this question is expensive, so it is worth clearing first.
Productizing is not building software. When the idea spread, the vocabulary came with it: products, roadmaps, features, platforms. A generation of services founders read that as an instruction to stop being a services firm, and started chasing internal tools and quasi-software offerings that bore no relation to their actual strengths. For most boutique firms that would require a complete reboot: new talent, new capital, a different risk profile and a different go-to-market motion.
What productizing actually means is designing services with the same intentionality a product gets: clearly defined offerings, repeatable methods, consistent outcomes and predictable economics. The work stays services work. The design gets rigorous.
Credit where it belongs. Eisha Armstrong, through her books Productize, Fearless and Commercialize and her firm Vecteris, did more than anyone to advance this. She named the core dysfunctions of custom work, showed why bespoke delivery undermines scale, and gave founders a path forward when the only alternative appeared to be hiring faster than they could manage. Collective 54 regards that contribution as catalytic rather than incremental, and for firms still operating labor-first it was less a methodology than a rescue.
The most common productization failure is packaging what you already do and finding out later that nobody prioritized buying it.
The starting point is what the market consistently demonstrates it will fund, which is not the same as what clients say is interesting. In practice that means asking how frequently a specific client problem appears across your conversations and engagements, separating urgency from curiosity, identifying who experiences the problem against who controls the budget, accounting honestly for the substitutes including doing nothing and doing it in-house, and looking for real willingness-to-pay signals rather than stated interest.
Collective 54 has always argued that this evidence should be gathered deliberately rather than absorbed informally. The mechanisms are unglamorous and they work: a client advisory board of roughly ten current and former clients meeting twice a year, where the clients present and you listen; post-project reviews run by someone who was not on the project team; a formal client satisfaction program after every engagement; and a quarterly win-loss program where a third party asks prospects why you won or lost. Losses in particular reveal holes in the offering. And read the agendas of the conferences your clients attend, because the organizers have already done the work of ranking their problems by relevance.
Do not assume you know what your clients want. Your opinion is not the input.
Most firms stop at the methodology, which explains how the work is done. Service architecture defines how the work behaves under scale, and that is a different document.
It answers: what outcome is being sold, rather than what activities are performed; exactly what is in scope and what is out; what the repeatable method is, in a form that can be taught and enforced; which components can be reused across clients and across other services; where customization is allowed and where it is not, as written rules rather than case-by-case judgment; and what the client has to do for the service to work at all.
That last item is the one firms forget, and it causes more delivery failure than any other single omission.
The customization rules deserve particular attention, because this is where margin is actually lost. Customization is not the enemy. Unplanned customization is. A service with three defined variants and a written rule for what may be adjusted inside each is a service. A service where every deal negotiates its own scope is a collection of projects with a shared name.
Many firms discover profitability after the fact, negotiating price deal by deal and reviewing margin quarterly. By the time the problem is visible, the service is embedded in the firm.
Model the economics before the offering goes to market. Pick the value metric the price is anchored to. Choose the pricing model deliberately, whether fixed, recurring, outcome-based or hybrid. Set the expected and minimum acceptable margin. Forecast the cost to serve across its human, AI and tooling components. And test the sensitivity to discounting and to scope creep, because both will happen.
A service that cannot sustain margin is a design failure rather than a sales failure. That distinction matters, because firms usually respond to a low-margin offering by pushing the sales team harder, which makes it worse.
This is where service designs most often collapse. The designer assumes delivery will figure it out. The delivery team inherits promises it did not help write. The result is rework and margin erosion.
Before launch, stress-test the design against real constraints. Assign the delivery roles explicitly across humans and AI rather than discovering the split mid-engagement. Confirm the required skills exist and can scale. Model the cycle time from start to finished outcome. Define how quality is controlled and by whom. And identify the predictable failure points so you meet them before a client does.
The standard is worth stating plainly: a service that cannot be delivered without heroics is not a finished design. If it only holds together when your strongest person intervenes, you have built a dependency.
The same goes for selling it. A productized service has to be sellable by someone other than the person who designed it, which means the sales narrative, the qualification criteria and the proof assets all have to reflect the actual design rather than an aspirational version of it. When sales overpromises, that is usually a design problem wearing a sales costume.
Two boundaries are worth being honest about.
The first is that a portfolio of packaged offerings still has to expand. Clients get fatigued by the same thing, and existing-client revenue growth is a large part of how boutique firms scale. SBI started with one offering, a hiring methodology for sales teams, and by the time Greg Alexander left it had more than a hundred, launching roughly ten a year, eventually packaged under a single trademarked methodology. The price the firm sold for was about 30 percent above comparable firms, partly because the offering was that robust. Productizing one service is a step. Building the capability to design new ones is the actual asset.
The second boundary is about what has changed. Productization was built for a world where humans did all the synthesis: the research, the packaging, the testing, the documentation, the iteration. It made that work more structured without making it materially lighter, which is why so few firms sustained it. Now the analytical half of the job, the signal ingestion and pattern detection and economic modeling and documentation, can run continuously at low cost. What remains is judgment: which problems are worth solving, which tradeoffs to accept, where standardization should stop, and accountability for the result. For firms in slower-adopting or heavily regulated markets, the classic productization approach remains a valid and often sufficient step. For firms at the leading edge, much of the workshop-and-stage-gate apparatus was compensating for an absence of intelligence that no longer applies.
If you have one client concentration problem rather than a customization problem, productizing will not help. You have a business development problem wearing a service design costume.
If your buyers pay a premium precisely for bespoke work and can tell the difference, productize the internal components rather than the client-facing offering. The reuse is in how you deliver, not in what you sell.
And if you are pre-scale with a handful of clients, you do not yet have the evidence base to design against. Gather the market truth first. Packaging too early locks in a guess.
Productizing means designing services with product-level intentionality, not becoming a software company, and the firms that confused the two lost years. Start from what the market demonstrably funds rather than from your methodology, and gather that evidence deliberately through a client advisory board, post-project reviews, a client satisfaction program and quarterly win-loss interviews. Then write the architecture rather than the deck: the outcome sold, explicit scope boundaries, a teachable repeatable method, reusable components, written rules for where customization is allowed, and what the client must do. Model the economics before launch, including the value metric, the pricing model, the target margin, the cost to serve across human, AI and tooling components, and the sensitivity to discounting and scope creep. Stress-test delivery against skills, cycle time, quality control and failure points, and treat any service requiring heroics as unfinished. Then keep designing new offerings, because a single packaged service is a step and the capability to build more is the asset.
No, and that confusion has been expensive. When the idea spread, the product vocabulary came with it, and a generation of services founders read it as an instruction to become a software company, chasing platforms and internal tools with no relation to their strengths. For most boutique firms that would mean a complete reboot: new talent, new capital, a different risk profile and a different go-to-market motion. Productizing means designing services with the same intentionality a product gets, meaning defined offerings, repeatable methods, consistent outcomes and predictable economics. The work stays services work.
From market truth rather than from your existing methodology, because the most common failure is packaging what you already do and discovering nobody prioritized buying it. Ask how often a specific client problem recurs across conversations and engagements, separate urgency from curiosity, distinguish who experiences the problem from who controls the budget, account for substitutes including doing nothing and doing it in-house, and look for real willingness-to-pay signals rather than stated interest. Gather that evidence deliberately through a client advisory board, post-project reviews, client satisfaction surveys and quarterly win-loss interviews.
Write the rules rather than deciding deal by deal. Customization is not the enemy, unplanned customization is. Service architecture should define the outcome being sold, exactly what is in scope and out, a repeatable method that can be taught and enforced, components reusable across clients, explicit rules for where customization is allowed, and what the client must do for the service to work. A service with defined variants and written adjustment rules is a service. One where every deal negotiates its own scope is a collection of projects sharing a name.
Two tests. First, the economics are modeled rather than discovered: the value metric, the pricing model, the target and minimum margin, the cost to serve across human, AI and tooling components, and the sensitivity to discounting and scope creep. A service that cannot sustain margin is a design failure, not a sales failure. Second, delivery has been stress-tested against real constraints, with roles assigned explicitly across humans and AI, skills confirmed available and scalable, cycle time modeled, quality control defined, and failure points identified. A service that cannot be delivered without heroics is not a finished design.
Sources: Greg Alexander, The AI-Native Boutique Firm (Advantage Books, January 2027), specifically The AI Service Design Manager for the credit to Eisha Armstrong and Vecteris and her books Productize, Fearless and Commercialize, described as a catalytic rather than incremental contribution and a rescue mission for labor-first firms; for the unintended confusion in which founders read productization as an instruction to become a software company; for the seven categories of service design including market truth, strategic focus, service architecture, commercial and pricing design, delivery feasibility, go-to-market enablement, and lifecycle and transferability; for the architecture requirements of outcome-based definition, explicit scope boundaries, teachable repeatable methods, reusable components, written customization rules and the client role; for modeling the value metric, pricing model, expected margin, cost to serve across human, AI and tooling components and sensitivity to discounting and scope creep before launch; for the delivery stress test on skills availability, cycle time, quality control and failure points, and the standard that a service requiring heroics is not a finished design; for the requirement that services be sellable by someone other than their designer; and for the argument that productization was an Era 2 solution that structured the work without making it lighter, and that much of its workshop and stage-gate apparatus compensated for an absence of continuous intelligence, while remaining valid for firms in slower-adopting and regulated markets. Greg Alexander, The Boutique: How to Start, Scale, and Sell a Professional Services Firm (Advantage, 2020), chapter 19 for service offering development, client fatigue, the client advisory board of roughly ten current and former clients meeting twice a year, post-project reviews conducted by someone off the project team, the formal client satisfaction program, the quarterly outsourced win-loss program, reading client conference agendas, and the SBI history from one offering to more than a hundred at roughly ten launches a year packaged under a trademarked methodology, with the firm selling about 30 percent above comparable firms partly because of the robustness of the offering; chapter 5 for the better, faster, cheaper value proposition measured against the alternatives; chapter 33 for intellectual property as what distinguishes a professional services firm from a body shop.
Collective 54 is the private community for founders and executives of boutique professional services firms between $5M and $50M in revenue. Members work these answers against their own numbers.