Forward-Deployed Engineering and Deployment Work

Imagine a vendor that closes a deal after a single conversation with the executive who championed the purchase. By the time the contract is signed, the pricing tier, any setup fee, the definition of success, and the commitment to consumption are all written down. Yet the people who will actually use the software, and whose daily habits will determine how much work the deployment really takes, have not yet been met. The price was fixed at the point of least information.

This article asks a practical question: what goes wrong when a price is fixed before the operators' habits are known, and what can a team do about it? The answer draws on three ideas from the source: the price can become a liability, the stage of the deployment controls what can be booked as revenue, and in outcome-based pricing the vendor must guarantee the result. The forward-deployed function is the role that makes that guarantee workable.

Follow the price through time. At signature, the price is a fixed number that everyone has agreed to. At that moment the team knows the executive's view of the problem but not the daily routines of the operators. The gap between what the price assumes and what the operators actually do is invisible at signing. It appears only once the software is in use.

The before and after panels show the same relationship over time. Before discovery, the price is committed while habits remain unknown. After discovery, the habits are known, and if they differ from what the price assumed, the team faces a correction. The changed nodes mark the point where the price stops fitting the customer, and the terminal node marks the cost the source highlights.

The source makes a specific point about timing. When the team discovers that the initial price was wrong, correcting it means asking the customer to accept a new number at the moment the relationship most needs trust. Repricing later therefore costs credibility, and that cost is paid exactly when the vendor is asking the customer to believe in the product and in the vendor's judgment.

The source ties this directly to discovery work. The discovery discipline described in Chapter 8 is, among other things, the pricing team's main protection against setting a price that will later need correcting. The way to avoid an unwelcome repricing is therefore to learn enough about the operators and their routines before the number is committed, rather than hoping the number holds.

The second challenge concerns the stage of the deployment. The source states that stage changes what the vendor is allowed to do. Early in a relationship, custom work can be recorded as license revenue, and the discovery effort can be paid for out of the customer's money. That permission is temporary. It expires as the engagement matures.

The timeline shows the same deployment at two points. Early on, the permission is available and custom work can be booked as license revenue. Once the engagement matures, that permission is gone, and the changed node marks the shift. A team that has been relying on the early permission without noticing will find that its accounting and its commercial options change when the stage changes.

To see why pricing keeps moving toward outcomes, the source uses a two-dimensional map. Seat, usage, and outcome pricing can each be placed on it, and the placement depends on how much of the result can be credited to the product and how much autonomy the software has in producing that result.

The comparison columns place the three models along the map. Seat pricing sits in the corner where attribution is weak, because the software assists a person who does the job. Usage pricing, which is what a vendor pays a foundation-model provider for consumption, sits in the middle. Outcome pricing belongs to the case where the software itself owns the result, such as a resolved customer inquiry or a completed sale. Moving from seat toward outcome means the software does more on its own and its contribution is easier to tie to a specific result.

The source identifies the forward-deployed function as the role that makes the outcome guarantee work. When the vendor prices the outcome, it must be able to deliver the outcome in the customer's actual environment, and the forward-deployed team is the group that is present in that environment. Its job is to learn the operators' real habits, because those habits determine how much work the deployment takes and whether the promised outcome is achievable.

Information then has to flow in two directions. Findings about the customer's daily routines feed back into pricing decisions, so the price reflects what the work actually requires. The same findings shape delivery, so the team builds and configures the deployment around how the operators really work. Without this loop, the price is set on assumptions and the guarantee is backed by guesses.

A price fixed at contract time is set before the operators' habits are known. Correcting it later costs trust at the moment the relationship most needs it, so discovery before commitment is the main protection. The stage of a deployment controls what can be booked: early custom work may be recorded as license revenue, but that allowance expires as the engagement matures. Seat, usage, and outcome pricing can be placed by attribution and autonomy, and outcome pricing depends on the vendor guaranteeing the result. The forward-deployed function is the role that learns the real habits and carries that guarantee into delivery.