Optimise for Learning: A Conversation with Niles Lawrence
Agent Product Manager at Sierra
Niles Lawrence has spent over five years on Forward Deployed Engineering teams between Palantir and Sierra. Before that, he founded Vuru, a stock analysis platform, raising a seed round from Tim Draper at age 21. At Palantir, he went from FDE to Enterprise Lead, running engagements across manufacturing, airlines, financial services, and government. He’s now an Agent Product Manager at Sierra, where the FDE model has evolved into what they call Agent Development. We talked about what founding a company teaches you about FDE work, what good shadowing actually looks like, and where the role goes next.
You founded a company at 21 and raised from Tim Draper before joining Palantir. How did building your own thing change how you approached FDE work, and did FDE teach you anything you wished you’d known as a founder?
One of the things I learned that was really helpful, and the reason I liked FDE work, is that working directly with customers is really important. It shapes how you build product. You get real feedback in real time and you can improve very quickly.
As a founder, you have to be very customer-obsessed. Your whole business will win or die based on whether your customers like working with you and your product. That’s the biggest learning I took away from building a startup: how do you care about your customers, how do you listen to their feedback, and how do you build from there? That’s directly why I went to Palantir.
When I first joined, I was 24, and I was leading engagements for one of the top auto manufacturers in the world. We would go to the factory in Toledo and see how they’re building cars to understand their processes. You quickly learn it is all powered by people. You’re talking to the guy putting the mirror on the car. You’re talking to the people in charge of ordering parts. These are all real people that run these positions.
How do we build their learnings into a system that they can use to become more efficient? That’s what FDE is about. Working with very smart people in their own domain and taking their learnings to build a product at scale.
You wrote about spending months on factory floors in Toledo. What’s the difference between an FDE who shadows well and one who doesn’t?
A lot of it comes down to being very curious and very patient.
Think of anything you’re really good at. You’ll explain it very quickly because it’s so obvious to you. When you work with people that are domain experts in their own field, like manufacturing, they have been doing it for 25 to 30 years. They’re going to explain it the way they do it every day. You have to go slow with them, watch it all, take it in.
It’s actually a lot like what’s happened with AI. You have to treat your AI like it doesn’t know anything, and then slowly give it context over time for it to be effective. When you’re ramping up as an FDE and working with a customer, they’re the domain experts providing you the context. You’re the person who knows the platform best. You’re trying to figure out how to use the context provided, the platform, and your skill set to help them build something scalable and useful.
I spent almost three months in Toledo. Every week I’d fly in from New York, drive an hour south from Detroit, and spend the whole week there in person with them. Who’s the person in charge of ordering parts? Who runs the shop floor? What systems run the shop floor? How do they identify defects? Mapping a system like that is intense, but it’s something you need to do.
The reason you go into the field, to the customer, is so you can build enough domain expertise to have an opinion about what to build. It’s really hard to have an opinion about what to build when you haven’t done the work or don’t understand the details of how it works.
I asked whether it’s more beneficial to already have domain expertise or to come in fresh and learn fast.
It can work either way. What’s nice about having no context is you have very fresh eyes on a problem. A lot of great innovation comes from something outside the field being brought in. It transforms it completely.
But it depends on what you’re trying to do. If you’re focused on moving fast and executing, having the domain expertise is super helpful. Even at Sierra, as we work with large financial institutions or healthcare providers, those have a lot of complexity. If you want to be effective on the team quickly, you really need to understand those businesses.
It also depends on the domain. You definitely can’t vibe code your way through a healthcare product.
You converted 100% of your pilots at Palantir, three out of three in six months. What did you learn about what makes a pilot convert versus die?
One of the things I like about Sierra is that all of our proof of concepts are in production. We’ll work with our customer to get into production during the POC. It’s not just vaporware or a demo. I think it’s worth pushing for being in production to show tangible value.
At Palantir, what we saw was you need to be building something that’s going to be operationally critical for the business. If it’s not something that’s going to be in production and actually drive meaningful results, the likelihood of it replacing the existing solution is low, because they already have some way of doing it today. It’s just not the most efficient or scalable.
So you’re asking: is the solution I’m going to build for you 10x better than what you’re currently doing? If it is, it’s worth it. And in those scenarios, you have to take what you’re learning from the team on the ground and build it into something that can really transform the organisation.
You were at Palantir for about a year as an FDE, then moved into enterprise lead roles. What made you step back from the hands-on work?
The roles are relatively similar. When you first join Palantir, you’re going to work on an account. You’ll join an existing team and own a single workstream with an engineer. That’s the best way to learn the platform, get into the weeds, and build out that first use case.
Over time, you start to lead engagements. An enterprise lead is really about thinking how to build an account, help customers build products, expand, and figure out what else you can solve. It transitioned naturally for me. I started working on manufacturing, which is why I spent so much time in Toledo, then graduated to running the whole account, which covered safety, manufacturing, and real-time sensor based alerts.
The thing that’s very unique about Palantir is there was no concept of levels. No IC3 or whatever the traditional tech company structure is. You’re always just Echoes and Deltas. Echoes being deployment strategists and Deltas being forward deployed engineers. In that model, you’re driven by new scope or new problems, not career climbing.
If I was an IC5, I wouldn’t really want to go work on a two-man pilot. That’s a totally different scope. But Palantir’s flat organisation meant you could flex between different things. I went from manufacturing to airlines to financial services to government. I think that’s why people stay at Palantir for a very long time. You can work on so many different types of problems with the largest organizations in the world.
Personally, I always suggest people should optimise for learning and growth. Instead of staying on a large manufacturing account, I decided to work on small airlines, then moved to work in government, before working almost exclusively on pilots for six months. Can we win this deal in six to twelve weeks? That’s very different from spending a year building what was promised after the POC.
At Sierra, you’ve reframed FDE as “Agent Development.” Is that a genuine evolution of the role, or more of a rebrand?
Agent development is a much faster iteration cycle. Everything’s moving so fast with AI that it’s changed so often.
FDEs are still growing. Salesforce is planning to hire a thousand. I don’t think the role is going away. It just depends on how you think about building.
In a lot of cases, FDEs were building relatively bespoke applications on top of a platform like Foundry. Each use case is slightly different and needs to be built with components, like a dashboard or an application with alerts. You’re building within the Foundry ecosystem.
With agent development at Sierra you have a platform called the Agent Operating System, and it’s used specifically for building AI agents. You’re not building dashboard-style applications. You’re building agents, and agents are the core point of interaction across the company.
Why it’s different is you’re iterating so much faster. A customer in retail wants a “where is my order” agent. You work with them to build it, but you’ve already done that a few times. The platform knows how to build it and can be used to build it in a scalable way. The product and the outcome are more closely tied.
I asked whether a platform is almost necessary for the forward deployed model to scale.
In most cases you need a platform to leverage. The best FDEs are very smart individuals with strong technical understanding, you need to give them a set of tools. A platform is a pre-set-up set of tools to build with.
The problem with FDEs in a fully bespoke world is you’re building zero to one every single time. That makes it really tricky to have something reusable across companies or to capture learnings beyond the individual’s experience. I can’t take something I built fully custom for one customer and immediately apply it to another. But if I have a platform where I built an order lookup, I can use that again. I can generalise it as a PM and take those components into the platform so it works with another customer.
I asked about the team structure at Sierra and how engagement lengths have changed.
The speed is much faster now. At Palantir in 2017, you probably had six months to a year to build something very complicated. Now most of the time you’re building something meaningful in three months or less and iterating quickly. And with AI leverage in the current market, everything is so much faster. The iteration speed is days and weeks. We’ll often ship new agents to customers within the first week of engaging with them.
The way we’ve structured the agent development team is three roles. Agent engineers are in charge of building high-quality agents, scaling, infrastructure, everything that goes into traditional engineering work. Agent strategists are similar to deployment strategists, they own the account, its success, and growth. Then there’s the agent PM role, which is unique.
Almost every PM I’ve worked with at Sierra has the skill set to be a founder. They’re technical, they know how to engage with customers, they can think about scope, they have good EQ to engage with VPs. They also think through the strategy of the account. That’s a very interesting skill set. It’s basically why Palantir people all went and started companies.
The PMs are really in charge of taking learnings from customers and building those into scalable products that all deployments can use. Strategists are more focused on the individual account.
Where’s the biggest bottleneck in the deployment lifecycle? From my own experience, it’s discovery. Most customers don’t know what they want, where the biggest value is, or even how their own processes work.
That’s very common across the board. A lot of our discovery and pre-sale work is run by sales and sales engineering. The agent development team gets pulled in later, though we’re starting to be more exposed to the discovery part.
You’re going to approach it one of two ways. Either you work on a very hard, meaty problem right from the start, which is what Palantir used to do, because you can show value quickly if it’s real. We tend to focus on those kinds of problems at Sierra too. What is your hardest problem? What are your highest volume issues?
But in more regulated or structured environments like healthcare or banking, you might start with something smaller in scope just to show you can get through the procurement process and all the hand-holding to go live. Then you expand from there.
You still have to prove value, though. There’s no scope small enough that’s going to be useful if it’s just AI tourism. “We just want to see what this is, but we don’t really have any interest in going into production.”
There’s been a shift in the past year and a half. Initially enterprises were jumping in to experiment with AI, but now finance and legal are involved much earlier. How has that changed how you approach engagements?
I think Databricks is doing a really good job of this. Their net dollar retention is increasing. They’re growing the account. Even at Palantir, a lot of the biggest accounts were accounts that compounded over time. You started something smaller at Airbus, but then the account just grows because there’s so much more you want to do.
The nice part about forward deployed work in general is you build a lot of trust with your customer. They see you as an extension of their team. You’re not billing by the hour. It’s not consulting. They’re buying the software, they’re working with you. When they see you as a real partner for their AI adoption, they give you access to harder and harder problems.
But initially, in a POC, you’re going to get hard problems, but maybe not the hardest problem. Those require a lot of trust building. It’d be silly for a bank to give you their hardest problem on day one. Those are things you have to build towards. That comes from showing up really well, building trust, becoming a partner.
You’ve been an FDE, an enterprise lead, a founder, and now a product manager at an AI company. If someone’s a strong FDE today and wondering what’s next, what would you tell them?
One of the best parts about FDE work or agent development, anything where you’re working directly with customers and building things quickly, is you’re just very good at a lot of things. I used to joke with my friends at Palantir that Palantir did a really good job of building really smart generalists. Everyone was good at pretty much everything, but they had really strong spikes in certain areas. Customer work, technical ability, strategic thinking.
It’s worth knowing, even within the FDE role, what you gravitate towards. Do you enjoy doing the discovery work with a customer and understanding what the scope should be? A lot of people go into sales engineering roles from there. If you like the actual building and infrastructure side, you can go into building infrastructure products. If you’re drawn to working with customers, a lot of Palantir people went on to run their own FDE shops or consulting companies, operating as an enterprise lead across multiple accounts.
I went into product because after Palantir, where you over-index on a customer, which is the right approach, I wanted to try something different. Can I build a product that compounds over multiple years? At Dune, we built a public data platform housing hundreds of blockchains worth of data, petabytes of it. Very different from the customer-focused FDE work.
I always tell younger people: you don’t really know what you don’t want until you do it. You always think you know what you want, then you do it, and you realise it’s not quite right. But right now is a great time. If you’re learning about AI tooling and building and exploring, you can do so much. You can basically pick your future based on what you want to do.
Niles Lawrence is an Agent Product Manager at Sierra.