Forward deployed engineers should productize learned workflows into core product rather than remain as permanent deployment consultants.
While forward deployed engineers are necessary early to discover workflows, their output should be productized into scalable features, not remain as ongoing consulting. ✦ AI generated
Jesse · a16z Podcast · 2026-07-31 · original ↗
starts at this moment · 22:15
“Is application layer companies just for deployed companies that are kind of doing the last mile of work?”
My my view on this is that for deployed engineers are necessary or newly necessary for early stage AI companies because the workflows are new, right? If you're building a SAS company 5 years ago, most SAS products are pretty well explored, right? like you roughly know what the user is trying to do and your job is maybe come with a slightly cleaner workflows but broadly you know what the user is trying to do with a design app or a CRM or something like that because those workflows have been explored with AI products nobody knows what the workflows are because nobody's used these things before so a for deployed engineer in this case is honestly just embedding with the customer to learn the workflow for the first time as the customer learns the workflow for the first time and they're kind you know, kind of paving the road like you they're kind of laying out the track as they see which way the train is going in a way. Uh but long term, I think they should just be building product, right? Like once you know what the workflow is, you should not be relying on four deployed engineers anymore because once you know what the workflow is, if you can productize it, you should productize it and then become, you know, typical company with these scaling properties of a tech company.
verbatim transcript · starts at 22:15
22:15slightly cleaner workflows but broadly you know what the user is trying to do with a design app or a CRM or something like that because those workflows have been explored with AI products nobody knows what the workflows are because nobody's used these things before so a for deployed engineer in this case is honestly just embedding with the customer to learn the workflow for the first time as the customer learns the
22:39workflow for the first time and they're kind you know, kind of paving the road like you they're kind of laying out the track as they see which way the train is going in a way. >> Uh but long term, I think they should just be building product, right? Like once you know what the workflow is, you should not be relying on four deployed engineers anymore because once you know what the
23:00workflow is, if you can productize it, you should productize it and then become, you know, typical company with these scaling properties of a tech company. >> Yeah. And if you can't do that, then you're just building a glorified consulting truck. >> Well, I'd love to dig into this more because I know when we started working together, probably almost exactly three years ago, and you guys landed on this
23:18idea, there were two things that were relatively contrarian that now feel kind of standard. The first was when you started an AI customer service, a lot of people were like, that's a G GPT rapper. And we talked a lot about like why that's not the case. And then the second thing you did was say like, hey, we actually want to do the work ourselves, like we don't want to just be a software