Don't Shy Away from Services: A Conversation with Kabir Sial
Investor at Emergence Capital
Kabir Sial is an Investor at Emergence Capital, investing in early-stage B2B companies. Before moving into venture, he spent five years at Palantir in engineering and product roles across the commercial business. He studied Computer Science and Applied Mathematics at UC Berkeley and earned an MBA from Harvard Business School. We talked about how FDE shaped his view of product, why founders shouldn’t fear the services label, and what he’d tell FDEs thinking about their next move.
You studied CS and Applied Maths at Berkeley, went to Harvard Business School, spent five years at Palantir, and now you’re investing at Emergence. That’s a lot of different seats. How did FDE lead to venture?
When I was at Berkeley, the rite of passage for anyone studying CS was to go be a software engineer at Google or big tech. I had interned there and I didn’t really enjoy it. It was slow. The scope of your work tends to be very limited.
What excited me about Palantir was that I’d be responsible for spending time with customers, scoping out what they’re trying to do, and then just going and building it myself. A lot of the value came from hearing how customers were trying to do something with the product and where it failed, and then literally building something in the next two days and showing it to them. Sometimes completely from scratch. At that stage of my career, that felt like a really good learning opportunity for someone who wants to maybe one day start a business.
After five years, I went to HBS looking to start a company. I played around with a few ideas, and in that journey I met a bunch of VCs. I was a scout for a fund called Contrary, got a chance to intern at Notable Capital for about eight or nine months. During that period, I just enjoyed the day-to-day work enough that I ended up wanting to do it full-time.
There are trade-offs. When you’re deeply embedded in a specific problem as an engineer or PM, you only think about that one problem. You think about all the things that could go wrong and everything you need to fix to make it work for a customer. As an investor, you don’t get that depth. But the entire job is meeting really smart people and hearing about how they view the world and how they want to shape certain problems. The energy I got from that was enough to compensate for the lack of depth.
Kabir also spent time as a product manager at Verkada and in engineering roles at Amazon. I asked how those stints in more traditional product and engineering organisations changed his view of the FDE model.
Did those experiences show you that FDEs have gaps compared to traditional product managers, or that they have advantages?
It’s definitely an advantage. I started doing product work while I was still at Palantir, towards the end of my time there. A big reason I was able to do that was because I’d spent so much time actually building parts of the product and hearing across many different customers and verticals how they used it. That helps you inform your intuitions about both how to build and what to build.
Verkada was a slightly different experience. Product is not as tightly coupled with engineering there. You only think about what you want to build, not necessarily how to build it. For my personality and background, I had a lot more fun in the Palantir style of doing product, which was much more tightly coupled with FDE and core software engineering.
But there’s also a disadvantage. The biggest thing I felt as a PM was a natural inclination to overfit to a very specific customer’s feature requests. That inclination is probably fine at a business like Palantir, which has a couple of hundred customers that tend to be very large. You benefit from overfitting to what those customers want.
At a business like Verkada, which has many more, smaller customers, you have to be more disciplined about which features and workflows you actually support. I remember speaking to a customer that was not very large and I started scoping out exactly how we’d build this one thing they really wanted, something highly specific to them. My manager told me, why are you doing this? It doesn’t make any sense. We need to make a business case. We need to decide where this fits from a priority perspective. That was a good lesson.
Kabir’s FDE background now shapes how he evaluates founders. At Emergence, he’s drawn to companies that look messy early on, the ones doing hands-on, customer-specific work before they’ve figured out the product. I asked how he tells the difference between a smart path and a dead end.
Your bio at Emergence says you love founders who do what might initially look like unscalable things to solve customer problems. That’s basically the FDE job description. How do you distinguish between a founder doing unscalable things as a path to product versus one who’s just building a services company that won’t scale?
You can’t scale what you don’t know. Early on in a company, it’s pretty natural to be doing unscalable things.
If you’re primarily serving enterprise customers, doing unscalable things is actually really good because it buys you a level of trust with users that is very hard to get otherwise. If I’m a young person selling to a large Fortune 500 company, I’d be very lucky to get my foot in the door. If during the pilot I severely constrain the set of things I want to do relative to the set of things my users want me to do, it gives me less opportunity to build trust. And with enterprises, you want trust to expand within them over time.
Of course, it’s important to productise in some shape or form. You don’t have to productise the external thing, at least not early to mid-stage. But it is good to be productising the set of primitives you see come up again and again, at least internally.
As an example at Palantir, even when I was there, Foundry was relatively nascent. FDEs would build custom front-ends to support very specific workflows and applications. In maybe a year and a half to two years, a lot of what FDEs had built across deployments provided learnings into what a more generic application builder could look like. One that actually works well, because there were a ton of other application builders in the market that couldn’t do very specific things, like allowing users to configure complex business logic beyond simple SQL queries. That kind of stuff could not have come without the “unscalable” work.
Today, with AI coding tools, the road you can travel doing unscalable things can go a lot further. If you want to build custom applications, custom React front-ends, you can do them a lot quicker with tools like Claude Code. That can incentivise founders to keep the services journey going very long.
But it’s still important to try and productise, because every moment you spend building or supporting something customer-bespoke distracts you from building the thing that’s eventually going to be your product. At a minimum, internally, founders should be productising the set of primitives they see over time.
This naturally led us to a question about defensibility in a world where building is getting easier by the day.
If it’s easier than ever to build things, what counts as a moat?
Brand and trust. That as a moat has not changed. You tend to look for whether there’s a lot of customer love. Even if it’s easy to build things, not every product will have tons of customer love. Are users going to be super sad if this product was ripped out? If it became 5x more expensive?
You do see a real bifurcation. Today, there are a bunch of coding tools. But people are still spending thousands of dollars every month on Claude Code, on those really expensive tokens, even though there might be cheaper tools out there.
Where you have to be careful is investing in companies that are very thin layers over the model. You have to look for what level of depth they’ve actually gotten within an industry or a workflow.
Towards the end, Kabir brought up a topic I hadn’t planned to ask about. Historically, VCs have avoided services businesses because of thin margins and slow growth. He’s seeing that change.
You mentioned AI-enabled services businesses as a real opportunity. What’s shifted?
The thing most people point to about services businesses is that the gross margin profile is not there. Most services businesses tend to be 25 to 35% gross margin, whereas software has historically been 70 to 80%.
I would push most founders to think about that, because you can probably get to the 60s or even 70s. There are startups in the Valley that have been able to get to 70-plus percent gross margins offering purely a service.
The trade-off between product and services doesn’t actually have to be as explicit as we historically believed. For a lot of industries, like accounting or healthcare, the cost of mistakes is so high that customers want a human in the loop. There is still an opportunity to build a true venture-scale services business that is more enabled by AI. There are already examples, including some companies in our portfolio like Strala, that are taking this approach where they’re not selling product, they’re selling a service.
Founders should not shy away from that.
I had one last question. Many FDEs eventually start their own companies or move into product. Kabir has done both. I asked what he’d tell FDEs thinking about what comes next.
You’ve been an FDE, a PM, and now an investor. What advice would you give to people entering the FDE role, or FDEs thinking about their next step?
It’s probably the most exciting time to be an FDE because there’s so much more you can actually do for more customers with the tools being built today.
From a core advice perspective, the job of an FDE is evolving. A lot of companies outside of Palantir would structure this role historically as someone who does configurations and integrations. Every FDE should be thinking hard about how they can shape the product. They are the people providing the most direct signal and feedback. A key thing that sometimes gets missed about the FDE model is that the reason you have deployed teams is not just because the product doesn’t work. It’s about finding more use cases to tackle, more users to enable.
For people thinking about what’s next, FDE is becoming more of an independent function. You can be a true head of deployments at your company. If that’s not the direction, starting a company is a great option. Product is a natural progression too, but honestly those roles are converging. A lot of what you’re already doing is spending time with customers. You are already shaping product and doing product-style work.
I’d even say that going into core product engineering is a strong path. That used to be the most common move at Palantir. People who’d been there a long time would build stuff in the field, then build a more generic version of it that would be used across the fleet of customers. Pretty much all the best engineers at Palantir across the years were former FDEs.
Kabir Sial is an Investor at Emergence Capital.