Discovery Discipline in Enterprise Software Sales

Picture 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 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 decide how much work the deployment really takes, have not yet been met. The price was fixed at the point of least information.

This article follows that fixed price through the rest of the engagement. We will trace what happens when the team learns more, why the timing of a correction matters as much as its size, and what discovery work can do to protect the number before it is committed.

Trace the sequence of events in order. First, the team signs at a fixed price. Second, the team begins to discover the customer's actual operating habits, which are often different from what the sponsor described. Third, the gap between the fixed price and the real workload creates pressure to reprice. Fourth, if the team asks the customer to accept a new number, the relationship absorbs the cost. The diagram below lays out this sequence so you can see where each step sits relative to the others.

The source makes a specific point about timing. Correcting an initial price 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 precisely when the vendor is asking the customer to believe in the product and in the vendor's judgment. A correction that might be small in money can still be expensive in trust.

The source ties this problem 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 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 in effect be paid for out of the customer's money. That permission is temporary: it expires as the engagement matures. The diagram below shows the two states and the transition between them.

To see why pricing keeps moving toward outcomes, the source uses a two-dimensional map. Each pricing model can be located by answering two questions. The first asks how much of the outcome can be credited to the product. The second asks how much autonomy the software has in producing that outcome. The map below places the three models on those two axes.

When the vendor prices the outcome, responsibility for that outcome moves toward the vendor's own staff. The source names the forward-deployed function as the role that provides the guarantee. This function sits between the customer's day-to-day operations and the vendor's pricing and product decisions. Its work is to learn how operators actually behave, so the outcome the vendor promises matches what the deployment will really produce.