Show notes: Do things that don't scale, at scale

Video: The FDE Playbook for AI Startups with Bob McGrew, Y Combinator.

Bob McGrew was an early engineer at PayPal, an early executive at Palantir where he ran product and engineering while the forward deployed model was being invented, and most recently the chief research officer at OpenAI, where he led the work behind ChatGPT, GPT-4, and the o1 reasoning model. So when he sat down with Y Combinator to explain the forward deployed engineer, he was not describing something he read about. He was in the room. His framing of how hot the topic has become is concrete: there are now over a hundred YC startups hiring for the title forward deployed engineer, up from basically zero three years ago. If the first note in this trilogy is the model as its inventors describe it and the second is the skeptic's warning to a job seeker, this one is the operator's playbook: how you actually run it, and when you should not.

Do things that don't scale, at scale

Start with the counterintuitive part, because McGrew leads with it. The standard startup path is well known: early on you do things that don't scale, you get very close to customers, and you keep at it until you find product-market fit. Then, the moment you find it, you do something entirely different. You embrace distance from the customer, you treat every customer the same, and you pour everything into scaling. If that works for you, McGrew is emphatic: do not run the forward deployed strategy. You have been given an amazing gift, so take it. Palantir did not get that gift. The product each customer needed was slightly different at every site, so instead of building one product they built a platform that could be customized per site, and the forward deployed engineers did the customizing. His first, second, and third piece of advice to a founder considering this is that if you can possibly avoid it, you should, because you will probably just end up doing services. Only if you genuinely try not to and fail is it a moat, because then it is the one thing that can work in your market.

Put simply: the forward deployed model is not a growth hack to reach for, it is a last resort. If you can find product-market fit and then scale by treating every customer the same, do that. You only take on the forward deployed strategy when your market makes plain scaling impossible, and then the difficulty itself becomes the moat.

The gravel road and the superhighway

Here is the mechanic that makes it work instead of collapsing into consulting, and it is the image worth keeping. At a new customer, the forward deployed engineer takes the product as it is and fills the gap to what the customer actually needs, writing rough, fast code to get there. McGrew calls this laying a gravel road to where the product needs to go. That gravel road is deliberately cheap and specific: solve this one problem, for this one customer, now. Then the product and engineering team back at headquarters looks at that gravel road and asks the only question that matters, which is what the generalized version is that will serve the next five or ten customers, and turns the gravel road into a paved superhighway. The failure mode is bringing one customer's gravel road straight into the product, which builds something over-specialized for a single site. The magic is a product team that can look at a specific hack and guess the correct, slightly more general problem underneath it.

Put simply: the forward deployed engineer builds a quick, ugly, specific solution at one customer, a gravel road. The product team's job is to see the general shape of it and pave a superhighway that carries the next ten customers. Copy the gravel road directly into the product and you have built a dead end for one customer.

Two roles: the heretic and the prototyper

McGrew is precise about team structure, and it comes down to two roles that stay constant across every iteration. The echo team are embedded analysts and account managers who go to the customer site, talk to the users, and figure out which problem is worth solving and worth demoing. The classic echo hire is a domain expert, a former army officer or someone who lived in healthcare, but with one non-negotiable trait: they have to be rebels, or as Palantir's Shyam Sankar would say, heretics. They must know how the work is done today and be convinced it is broken, because if they think the current way is basically fine they will never find the three-to-ten-times step change that justifies the whole effort. The delta team are the deployed engineers, and their skill is prototyping fast and, in McGrew's repeated phrase, eating a lot of pain. The wrong delta is a craftsman who wants perfect, maintainable abstractions; the right one writes rough-and-ready code, delivers the outcome on a tight timeline, and is willing to throw the first version away. The rhythm is fixed: arrive with an idea, spend a few months, present progress to leadership, and if it lands, deploy across the whole organization.

Put simply: you need two kinds of people. An echo who knows the domain cold and is angry that it works badly, so they can spot the enormous improvement. And a delta who can build a working, throwaway prototype fast and absorb the pain of doing it under a deadline. Neither is a normal enterprise hire.

How you know it is not consulting

The oldest knock on the model is that it is just consulting dressed up in marketing speak, and McGrew refuses to wave it away, because there is a real risk it is true. Back in 2015 people said two things about Palantir: that it was evil, and that it was a consulting business that would never scale. The test that separates a real forward deployed business from a services shop is a specific financial shape. When you start a new deployment you may actually lose money, because you need a large team on site building the gravel road. But over time two things happen. The product, improved by everything the engineers discovered, gets better suited to what the customer does, so you need fewer people on site. And you earn the right, as Sankar puts it, to work on more valuable problems inside the account. So your cost per unit of value delivered falls, and the margin on that customer starts negative and crosses into positive after a year or several. A consulting business never makes that crossing. It stays underwater on every engagement, forever.

Put simply: the honest signal that you are running a software business and not a consultancy is the margin curve on a single customer. It should start negative, then climb above zero as the product absorbs what you learned and you take on more valuable work. If it never climbs, you are a consulting firm that has lied to itself.

Why AI agents, and why now

The obvious question is why a strategy that looked like a Palantir-only oddity is suddenly the default for AI startups. McGrew's answer is about product categories. A standard SaaS company replaces one known way of doing something with a better one: a new way to pay bills instead of the old way. Everyone understands that market, so there is little product discovery, and you win by building a product better than the incumbent and scaling to replace it. AI agents have no incumbent product. Nobody has built the thing before, and, McGrew suspects, what it even means to build AI agents is probably many different things we have not figured out yet. In five years we may look back and realize agents were never one thing at all. That means there is an enormous amount of product discovery to do, and the only place to do it is inside the enterprise, next to the work. This is exactly the heterogeneous, no-map condition Palantir faced across intelligence, law enforcement, and the military, which is why the same playbook fits.

Put simply: SaaS works by beating an existing product and scaling. AI agents have no existing product to beat, and no one yet knows what the right product is, so the discovery has to happen inside real companies doing real work. That condition is what forward deployed engineering is built for, and it is why the model came back.

Sell the outcome, drive the contract up

The pricing question is where McGrew says AI founders most often get lost, because the instinct from SaaS points the wrong way. In the product-market-fit world you want simple, repeatable pricing, seats or usage, and you are comfortable with small contracts because the marginal cost to deploy is near zero, so you drive the cost of serving each customer down and keep the contract size flat. The forward deployed model inverts both. You are not selling the installation of software, you are selling an outcome, the fact that you solved a problem. And you deliberately drive the contract size up over time, doing more and more valuable work for the customer, landing and then expanding. The two things to watch are the value of the outcome you deliver and the product leverage you build against it, so an engineer can deliver more without pulling in three more engineers. And because the enterprise does not believe it can succeed, and does not believe you can either, the move early on is to take the risk yourself: you pay us if it works. YC companies like Castle, doing voice agents for mortgage servicing, and Happy Robot, doing them for logistics with customers like DHL, discovered exactly this ramp on their own, going live by scaling successful calls before scaling price.

Put simply: stop pricing like SaaS. You are selling a solved problem, not seats, so price the outcome and push the contract larger over time as you solve bigger problems. And since the customer doubts everyone, including themselves, carry the risk at the start and get paid when it works.

The real opportunity is the gap

McGrew closes by zooming out, and this is the line for founders. Put on the research hat, he says, and the striking fact is that AI capability is improving extremely fast, faster than the plateau talk suggests, but adoption is nowhere near keeping up. His picture of the next five years is that capabilities race ahead and ahead while the world somehow feels increasingly ordinary: you sit in a self-driving car and, instead of marveling that no one is at the wheel, you complain about the traffic. That gap between what the models can already do and what anyone has actually adopted is the opportunity, and closing it takes human ingenuity, exploration, and a lot of pain, not an AI that wakes up over a weekend and takes over. It is the same shape as the forward deployed engineer filling the gap between a product and a customer's need, one account at a time. His analogy, which he agreed was close to the underlying truth: OpenAI is the home product team, and the startups are the forward deployed engineers out in the world getting the research adopted. He even frames his own new role in the Army Reserve, advising on technology as a commissioned officer rather than a consultant, as running the forward deployed strategy on the Army: find leadership's top priorities, and close the gap between what they want and twenty years of how things are actually done.

Put simply: the models can already do far more than the world has adopted, and that gap keeps widening as capability accelerates. The work that matters, and the best opportunity for founders, is closing it inside real organizations, which is forward deployed engineering pointed at the whole economy. Intelligence does not adopt itself.

Takeaways

• The forward deployed strategy is a last resort, not a default. If you can find product-market fit and scale by treating every customer the same, do that instead. You only run this when your market makes plain scaling impossible.
• The core mechanic is the gravel road and the superhighway: the engineer builds a quick, specific solution at one customer, and the product team generalizes it into a road that serves the next ten. Copying the gravel road directly into the product is the classic failure.
• Staff two roles. An echo, a domain heretic who knows the work is broken and can find the 3-to-10x change, and a delta, an engineer who prototypes fast, ships rough code, and eats the pain.
• The test that it is not consulting is the single-customer margin curve: negative at first, then crossing into positive as the product improves and you earn harder problems. Consulting never crosses.
• AI agents adopted this model because there is no incumbent product to copy and no settled idea of what to build, so the discovery has to happen inside the enterprise, exactly the condition Palantir faced.
• Price the outcome, not the software. Drive the contract size up over time as you solve bigger problems, and take the risk early so the customer pays when it works.
• The largest opportunity is the widening gap between AI capability and adoption. Closing it, account by account, is forward deployed engineering aimed at the whole economy.