The Forward-Deployed Company, Part 2: How to Define the Outcome a Forward-Deployed Team Is Paid For

Part 2 of The Forward-Deployed Company. How to define an outcome, measure it so the result survives an argument, contract on it, stay accountable to a result that takes a year to show up, and use all of that to tell a forward-deployed firm from a consultancy with a new job title.

Read ten forward-deployed engineering job postings and count how many promise some version of "driving business outcomes." Then read ten vendor decks and do the same. In my reading, most of them do. The phrase has become the category's way of saying "we're not consultants."

Now try an experiment. Ask three people at the same company, say the head of the FDE team, the CFO, and the customer's sponsor, what a business outcome is for their current engagement. Ask them to be specific enough that you could write it into a contract. My bet is you'll get three different answers, and none of them will survive the contract.

That matters more for this model than for almost any other. Part 1 argued that the difference between a forward-deployed company and an expensive services firm is whether the work compounds. The other half, which I'll come to later in this part, is accountability: a consultant is accountable for a recommendation, and a forward-deployed team is accountable for a number. If that's the line, then the definition of the number carries the whole model. A vague outcome is where forward deployment slides back into consulting, because nobody can tell whether you delivered anything.

The good news is that nobody has to invent this. The machinery for defining, measuring, and contracting on outcomes was built decades ago in finance, operations, and project management. The forward-deployed world just hasn't borrowed it yet.

The phrase that means nothing yet

It's worth being clear about what's at stake before getting into the tools.

When a project can't show what it changed, it can't defend its budget.

The most quoted statistic in enterprise AI is MIT's finding that about 95% of generative AI pilots stall without measurable P&L impact. Gartner's forecast from Part 1 adds that 70% of enterprises will abandon FDE-led agentic projects by 2028, partly because of cost. Both numbers share the same hidden factor. When a project can't show what it changed, it can't defend its budget, and the first bad quarter kills it.

That's why "drives business outcomes" is a dangerous slogan. It promises accountability without saying accountability for what. The fix has four parts, and I'll take them in the order a pod would use them in the first week of an engagement: decompose the goal, baseline it, map cause to effect, and decide how you'll prove it was you.

Start with a driver tree

The first tool is the value driver tree, and it's older than most of the people using the word "outcome." It's a staple of corporate finance, laid out in McKinsey's long-running Valuation textbook by Tim Koller and colleagues, and it's mainstream enough that SAP ships it as a feature of its analytics product. SAP's documentation describes the purpose in one line: "visualize the entire value chain of your business, instead of looking at isolated KPIs."

The idea is simple. You start with a number the business cares about and break it into the things that drive it, then break those down again, until you reach something a team can actually change.

Let me walk through one example. Say your customer is a mid-sized subscription software company, and its sponsor asks you to "improve customer support." That's a wish. Now decompose it. Support cost is contact volume times cost per contact. Volume is driven partly by repeat contacts, the customers who come back within a week because the first answer didn't fix their problem. Cost per contact is driven by handle time and by how often a conversation gets escalated to a more expensive specialist. On the revenue side, customers who need three contacts to fix one problem cancel more often than customers who need one.

Keep going until you hit a node that passes two tests. Someone at the customer already measures it, and a pod could move it within a few weeks. In this example, the node is probably the repeat-contact rate, the share of issues that come back within seven days. It's already in the support system. It's directly downstream of the quality of the first answer. And it connects upward to both cost and churn.

That's the node you sign up for: a specific rate, in a specific system, with a known path up the tree to money. "Improve customer support" was never going to survive a contract.