The last mile is only worth what you carry home from it

Vinoo Ganesh, who says he has built the forward deployed function three times, at Palantir, at Citadel, and now at Kepler, published a piece on September 12 about a title that has come loose from its job. He describes a fellowship dinner where the same two words covered a sales engineer who joins the second call, a quota carrying rep who can write Python, and a consultant with a statement of work. His explanation for why everyone is suddenly forward deployed is blunt. The problems a product could solve identically for a thousand companies are mostly solved, and what is left lives inside the building, in workflows nobody wrote down.

The story he tells is better than the thesis. A customer blocked a move from CSV to Parquet for close to a year, and the stated reason kept changing. Storage savings did not move her. Compute did not move her. Then an engineer went and watched her work and found she was pulling CSVs onto a Windows laptop, double clicking them open, and eyeballing the rows. That was the data quality check. Parquet had no viewer at the time, so the proposal took away her only instrument and handed her nothing back. They built a viewer that night. She approved the migration two days later, and he reports the pipeline went from about seventeen hours to two.

The vault’s page on service wedges argues the same shape from the seller’s side. Sell a narrow measured outcome first, instrument the existing workflow before making any automation claim, and let delivery reveal what the repeatable product actually is.

Concede that solving the thing in front of you is real work, and somebody at the company should be doing it.

Still, I would not call it forward deployed unless something came home. Ganesh’s line is that the draft is not the asset, and knowing which parts of it are wrong is. So measure the team by what changed in the platform.