How Not to Become Accenture
The forward-deployed model has a dark side: it can become body-shopping with a product demo attached.
The slide says “strategic services.” The reality is custom work, weak repeatability, vague scopes, overloaded deployment leads, and a product roadmap quietly captured by whoever pays the most for exceptions.
This is how software companies become consulting firms by accident.
Again, consulting is not the insult. Accenture is a real business with real capabilities. The danger is category error. If investors, employees, customers, and leaders believe they are building a scalable software company while the operating model depends on ever-growing human labor, the company will make bad decisions.
The precise failure mode is not “having services.” It is selling software multiples on consulting economics, letting bespoke work set the roadmap, and hiding the labor required to make the product succeed.
Forward deployment only works when the field creates leverage.
Services are not automatically strategic
There is a fashionable argument that services are good now because AI makes software more embedded and vertical. That is partly true. It is also too convenient.
Services can be a learning engine. They can also be a margin sink, a sales crutch, a roadmap distortion machine, and a way to avoid hard product decisions.
The difference is whether services produce reusable assets.
A deployment that teaches the company a repeatable workflow pattern is valuable. A deployment that creates a one-off integration for a customer outside the ICP may be expensive distraction. A domain workshop that produces evaluation criteria for future customers is leverage. A domain workshop that exists because the product has no opinion is labor.
The question is not “Do we have services?”
The question is “What does our services work become?”
The body-shop symptoms
A company is drifting into body-shop territory when:
- every large customer requires a unique implementation plan;
- sales promises that deployment can solve anything;
- product says “that is services” and services says “that is product”;
- margins depend on undercounting internal expert time;
- the best deployment people become permanent account heroes;
- documentation improves but the product does not;
- the same manual steps repeat across customers without automation;
- customer selection gets looser because services can patch the mismatch;
- success stories cannot be explained without naming the specific people who made them work.
The last one matters. If the value proposition depends on heroic individuals, the company has not built a model. It has built a talent bottleneck.
The productization obligation
Forward-deployed teams should carry a productization obligation.
After every serious deployment, the team should identify what changed in the company’s reusable system. That may include product features, templates, evaluation sets, onboarding flows, integration packages, sales qualification rules, pricing changes, risk artifacts, partner playbooks, or internal training.
If nothing reusable changed, the company should be honest: it sold labor.
That may be acceptable for a strategic account, especially early. But it should not be confused with progress toward software scale.
A useful operating ritual is the deployment retro. Not a customer success recap. A conversion review.
Ask:
- What did we do manually that repeated from prior deployments?
- What did we learn that should affect ICP or qualification?
- Which customer-specific work should never be repeated?
- What should become product?
- What should become a playbook?
- What should become an agent-assisted workflow?
- What should become a pricing or packaging change?
- What should become refusal language?
The output should be owned, dated, and revisited. Otherwise the retro becomes theater: smart people naming patterns that never change the product, pricing, qualification, or deployment model.
Protect the product from the field
This sounds contradictory, but it is not.
The field should inform the product. It should not hold the product hostage.
Forward-deployed companies need strong product judgment because customers will constantly ask for reasonable things that destroy repeatability. A request can be valuable to the account and still bad for the product. A workflow can be real and still too narrow. A customization can save a renewal and still teach the wrong lesson.
The product organization must distinguish market signal from account noise.
That requires customer selection, pattern tracking, and a clear theory of the product’s future. Without those, the loudest customer becomes the roadmap.
The answer is not to ignore the field. The answer is to interpret the field through strategy.
Keep services economically visible
Body-shopping often hides behind bad accounting.
A company celebrates software ARR while ignoring implementation hours, expert time, executive involvement, support load, custom maintenance, and opportunity cost. The gross margin looks fine because the real cost is distributed across functions.
Forward deployment needs honest economics.
Track deployment effort by customer type. Track time-to-value. Track repeatable versus custom work. Track expert utilization. Track automation impact. Track the support tail after launch. Track whether newer deployments require less human effort than older ones. Track sales commitments that required exception handling. Track custom maintenance after the account is “live.”
The goal is not to shame services. The goal is to see whether services are becoming more leveraged.
The elite version
The elite version of forward deployment looks less like “we will do whatever the client needs” and more like “we know this problem deeply enough to guide the client through a proven transformation while turning edge learning into product.”
That is a very different posture.
The company has opinions. It says no. It qualifies hard. It standardizes aggressively. It uses domain experts to define quality, not to handcraft every answer. It uses AI agents to absorb repeatable deployment labor, not to create uncontrolled automation. It prices services in a way that reveals demand and protects focus. It rewards field teams for productized learning, not just happy accounts.
The forward-deployed company does not avoid services. It metabolizes them.
That is how it avoids becoming Accenture by accident.
