Pricing and Packaging the Forward-Deployed Company
The forward-deployed company has a pricing problem: it is selling software, learning, implementation, trust, and sometimes outcomes at the same time.
If it prices everything like software, it hides services cost and teaches sales that human labor is free.
If it prices everything like consulting, it weakens the software margin story and trains customers to buy hours instead of product value.
If it avoids the question, the model becomes economically illegible.
Pricing is not just monetization here. It is operating design.
Do not make deployment free by accident
Free implementation can be a reasonable strategic choice. Accidental free implementation is different.
Accidental free implementation happens when the company includes heavy deployment work in the subscription because it wants the software ARR, does not want procurement friction, or has not yet measured the cost.
The customer learns that complex setup is included. Sales learns that services do not affect deal economics. Product loses pressure to reduce deployment burden. Finance sees gross margin too late. Implementation becomes overloaded.
If deployment is strategically important, price it or explicitly invest in it.
Those are different choices. Both can be valid. But the company should know which one it is making.
The paid pilot trap
Paid pilots are common in forward-deployed models because they reduce risk for both sides. The customer gets proof before full rollout. The company gets compensated for discovery and implementation effort.
The trap is letting pilots become custom consulting projects with no conversion logic.
A good pilot should test specific assumptions:
- Can the product create value in this workflow?
- What data and integration burden exists?
- Which trust gates are required?
- Which roles must change behavior?
- Which repeatable deployment steps are emerging?
- What would make expansion obvious?
A bad pilot is “let’s see what we can do together.”
That may sound collaborative. It often means scope drift, unclear success criteria, and a final readout where everyone agrees the work was interesting but nobody knows what should happen next.
Package pilots around decisions, not activities.
Separate fees without separating the experience
Customers experience the product and implementation together, but pricing may still need to separate them.
A setup fee can make deployment effort visible. A services package can protect margins. A premium onboarding tier can align complexity with price. An outcome-based component can signal confidence. A subscription can capture ongoing software value. Usage pricing can scale with workflow volume. A retainer can fund continued domain support.
The right answer depends on category, ACV, buyer expectations, implementation burden, and margin structure.
The principle: pricing should reinforce the behavior the company wants.
If the company wants customers to take deployment seriously, do not make it feel like a throwaway add-on. If the company wants to avoid bespoke work, do not sell unlimited customization. If the company wants to learn from early deployments, price discovery in a way that buys access and focus. If the company wants software margins, show how implementation effort declines over time.
Package the path to value
Forward-deployed companies should package deployment as a path to value, not a bucket of hours.
Customers do not want “40 hours of implementation.” They want confidence that the system will work.
A better package might include:
- workflow assessment;
- data readiness review;
- integration setup;
- trust and risk workshop;
- domain-specific evaluation design;
- user rollout plan;
- review queue configuration;
- success metrics;
- first-value milestone;
- deployment retro and expansion recommendation.
This communicates that implementation is a designed product experience.
It also makes repeatability easier. If every deployment follows a recognizable path, the company can improve the path.
Outcome pricing requires operational courage
Outcome pricing sounds attractive in AI because customers want results, not tools.
But outcome pricing makes the company responsible for more of the stack. If the company is paid on claims processed, leads qualified, revenue influenced, tickets resolved, or hours saved, it must understand which inputs it controls and which it does not.
Forward deployment can make outcome pricing more plausible because the company is closer to the workflow. It can inspect data, shape process, define review gates, and identify customer responsibilities.
But outcome pricing without operational control is gambling.
Before pricing on outcomes, ask:
- Do we control enough of the workflow to influence the outcome?
- Can we measure the outcome cleanly?
- Can the customer undermine the outcome through poor process?
- Do we have the right to refuse bad inputs?
- Does the upside compensate for the risk?
- Will this push us toward better product or more custom labor?
If the answer is unclear, start with milestone-based or hybrid pricing.
Pricing should expose bad strategy
Good pricing makes tradeoffs visible.
If customers refuse to pay for implementation, maybe the problem is not urgent enough. If services fees kill deals, maybe the product is targeting the wrong segment. If every deal needs discounting plus custom work, maybe the ICP is too broad. If pilots never convert, maybe the success criteria are weak. If high-value customers need expensive deployment but expand massively, maybe the company should embrace an enterprise model rather than pretending to be self-serve.
Pricing is a diagnostic.
For forward-deployed companies, the worst pricing model is the one that hides the truth long enough for the company to scale confusion.
The practical rule: price in a way that makes deployment effort visible, customer commitment real, and repeatability measurable. If pricing makes bespoke work feel free, the company will get more of it.
