Browse AI startup job boards in 2025 and 2026 and the title forward deployed engineer keeps turning up. On Y Combinator's Lightcone show in September 2025 (YC is a large US startup accelerator), one of the hosts said they had just checked the YC job board and found more than 100 YC startups hiring for it, up from almost none three years earlier. a16z (Andreessen Horowitz, a large venture capital firm) counted OpenAI's careers page as of its article date, June 4, 2025: 22 of 311 open roles were forward deployed engineer or solutions engineer positions.
If a job posting brought you here, Parts 1 and 2 cover where the role comes from and why companies pay for it.
But the role says something bigger than the job market. AI companies pay to send people on site because no model, however good, tells you which work to give it. If you are bringing AI into your team, the first question is not which one to buy, but which problem to solve and how you will know it is solved. Watching the real work is one way to answer that. Who will come and sit with us where the work happens is one question worth asking a vendor, not the only one.
In this article, Productize explains what a forward-deployed engineer is, why AI companies accept the cost, and what an SME owner can take from it. A disclosure of interests, up front: every source cited is an investor in or adviser to companies that work this way, so they gain if this approach succeeds. Productize also sells services in this area, acting as your head of technology for a stretch and building internal tools with AI, both listed on our services page.
Part 1What is a forward-deployed engineer?
A forward-deployed engineer is an engineer a software company stations inside a customer's organization to make the software actually do the work the customer needs, not to install it and leave. Bob McGrew, an early executive at Palantir and former Chief Research Officer at OpenAI, defines it this way: "So a forward deployed engineer is someone, typically technical and an engineer, who sits at the customer site and fills the gap between what the product does and what the customer needs."
The role was born at Palantir, a data analysis software company that started by selling to US intelligence agencies. Every customer needed something different: "the product that they needed was slightly different at every place." Rather than build a separate product for each, Palantir built a core system that could be adapted to each place, and sent engineers to adapt it on site.
McGrew's image is that the FDE "goes and builds like a gravel road to where the product needs to go." The engineer lays a rough road to the spot one customer needs. Back at headquarters, the product team picks the roads that would serve the next 5 to 10 customers and paves them into highways. The first customer gets the gravel road. The next customers get the highway.
Sounds like hiring consultants? McGrew does not brush that criticism aside: "I think there's actually a real risk that it's right." The difference McGrew points to: the longer the team stays with a customer, the better the software fits the work, the fewer people must be sent on site, and the team moves on to more important problems. So cost, measured against the value of the work delivered, keeps falling.
The early stage can lose money, though. McGrew says margins start out negative and turn positive after "maybe a year, maybe multiple years." That is McGrew's opinion, and the episode gives no figures to back it up.
Part 2Why AI companies have to send people to sit with customers now
McGrew's answer is short: "With AI agents, there is no incumbent product." There is no established product for an agent to replace. Sell a new bill payment program and everyone already knows what it should do; you only need to beat the existing vendor. But for an agent that takes over people's work, nobody yet knows all it must do in each organization, and every organization's workflow differs. As for finding that out, McGrew says "you can only do it from inside the enterprise."
Joe Schmidt of a16z puts it this way: "Enterprises buying AI are like your grandma getting an iPhone: they want to use it, but they need you to set it up."
Sending people on site is expensive, so Schmidt points to the software companies that won the move to the cloud. ServiceNow's gross margin at IPO was 63.2% and Workday's was 54.1%, rising to 79% and 75% in 2024. Schmidt's argument: accept thin early margins in exchange for owning the customer's workflow. a16z gives these figures without a source and picked only winners. Companies that carried on-site teams and failed are not in the article.
Sarah Wang and Martin Casado of a16z also argue that temporarily low margins in AI apps do not mean the business is bad, but they admit "Low margins will, at times, be a fatal aspect of the business." All of this is investor opinion, not proven fact.
What to take from this part is not the margin numbers, and not that someone must be stationed with you. These on-site teams exist to find out what an agent has to do in each organization. Until you know which work you want AI to do, buying the best one and putting it in place gets you nothing.
Part 3An SME does not need to hire an FDE, but it needs to pick the problem and the measure first
Most SMEs have no budget to station an engineer, and do not need one. If your company is small enough to walk past every desk, you probably see the problems every day already. So what is missing is usually not seeing. It is choosing which problem to solve first, and agreeing how the result will be measured. From the sources above, 4 things help with that.
Pick a problem in your top 5. McGrew says "If you're not solving one of the top five priorities for the CEO, it's probably not going to work." A large company needs someone at the top clearing the way for the on-site team. In an SME, that is you. If the problem is not on your mind every week, the team is unlikely to change how it works.
If you are not sure which problem weighs most, watching the real work helps you choose. The advice from Emergence Capital (a venture capital firm) to services businesses using AI is "Sit doers next to builders." Put the people doing the work beside the people building the system, with no retelling in between. If you hear about the work from a department head rather than seeing it yourself, take 2 hypothetical examples. The sales lead says the team replies to customers too slowly, but someone watching all day sees the time going into hunting for the latest price across several files. The delivery team says there are not enough trucks, but someone standing there sees truck runs replanned every morning because orders arrive incomplete. If you only listen to the summary, you will get AI that solves the wrong problem.
Measure finished work, not the number of features. McGrew explains "you're not selling the installation of software. You're selling an outcome." Measure the same way: count finished work, such as quotes sent out within the day, complaints closed on first contact, or bills entered into the system without corrections. To know whether anything improved, though, you have to count where things stand now.
If the result says stop, you have not paid for a whole project. If it says go on, take these numbers to the first question in Part 4.
Beware of building whatever people ask for. McGrew warns that the fastest way to end up as just a consultancy is this: "It's where you build the product in the field that the customers are asking for." The person you get to talk to is often a single point of contact, who wants what is easy for them to fix more than what changes the business. In an SME, that may be a department head asking AI to do the work they find tedious, not the company's most valuable work. If you want to try building it yourself, read One Agent Is Enough, Until the Evidence Says Otherwise.
Know where your data goes and who maintains it, before you sign. The Emergence Capital playbook tells vendors plainly: "ensure your MSA/engagement letters give you the ability to use the data from your service to improve your service." In other words, write the contract so the vendor may use data from your work to improve its own service. That is not wrong, but you should know whether your contract says so. The same goes for maintenance. The person who comes to help will leave someday, and if nobody on your team can change what they built, it stops where they left it.
Part 45 questions to ask before you hire anyone to do AI
AI vendor demos always look good. These questions work with any vendor. Questions 2 and 3 will last longest: even if AI someday sets itself up, you will still need to ask about your data and who looks after the system.
If you want someone to help choose what to tackle first, the Productize service for that is Acting as your head of technology for a stretch, described on the page as The person who decides with you whether this is a fix, a build, or a buy
. If you already know which tool you want, the Internal tools built with AI service goes from the real problem through to a system in use, handed over with a way to maintain it yourselves
. Both are services we sell, and the 5 questions above apply to us as much as to any other vendor. If you are not ready to talk to anyone, the eight-question self-assessment takes about five minutes, and no email is required.
If you had to pick one task tomorrow and count it for 5 days, which would it be, and what number would make you willing to stop? Once you can answer both, ask which AI to buy.
Sources and references
- Bob McGrew with the hosts of Lightcone (Y Combinator), The FDE Playbook for AI Startups with Bob McGrew, September 8, 2025 source
- Joe Schmidt (a16z), Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups, June 4, 2025 source
- Sarah Wang, Martin Casado (a16z), Questioning Margins is a Boring Cliche, August 21, 2025 source
- Jake Saper, Lotti Siniscalco, Rishub Nahar, Kabir Sial (Emergence Capital), The AI-Native Services Playbook, March 30, 2026 source
Read next: All articles · Y Combinator's playbook is your competitor's plan · One Agent Is Enough, Until the Evidence Says Otherwise