Two Archetypes: A Conversation with Kanav Bhatnagar

Senior Forward Deployed Engineer at Rippling

Kanav Bhatnagar spent almost three years as a software engineer at Amazon before moving into forward deployed work. He was one of the early FDEs at Actively AI, an AI-native sales platform, where he ran enterprise deployments with a 100% pilot-to-paid conversion rate. He’s now on the founding FDE team at Rippling, helping build out the function from the ground up. We talked about the two very different shapes the FDE role takes depending on whether you’re at an AI-native startup or a mature SaaS company going AI-forward, how to scope a pilot that actually converts, and why the role feels like a founder bootcamp.

You’ve now worked as an FDE at two quite different companies. How do the roles compare?

There are a lot of differences, and part of it boils down to the fact that Actively is an AI-native company that started as AI-native. Rippling is a SaaS company that’s existed for a while and is moving to be AI-forward. It is very much AI-forward now, but the archetypes are very different.

You see a lot of AI-native companies that are smaller, younger, newer, that emerged in the past two or three years and employ FDEs. And then there are these SaaS giants that have pivoted to be more AI-forward over the last couple of years. Rippling is an example. Ramp, Salesforce, Databricks and Snowflake all have FDEs now. These are companies that existed for years before AI adoption was the thing.

The role differs quite a bit between the two. At a smaller AI-native company the day-to-day work is heavily agentic, heavily focused on building the AI product itself. At a larger company it’s AI-focused too, but you’re also building custom code on top of a mature platform for a particular customer. The platform is more mature, so you can.

At a younger company you also do a lot more pre-sales POC work, because the company is still trying to find its footing. At Rippling there isn’t really time for that. There are already so many customers and a robust sales motion that handles winning the deal. Your job becomes filling in gaps in the product for a given customer, rather than putting time and effort into convincing someone to sign.

At Actively you had a 100% pilot-to-paid conversion rate. What does it actually take to get a pilot to convert?

The main purpose of a pilot is to prove out ROI. And with AI that can be tricky. You can talk about boosting productivity, or boosting revenue, or moving some other metric. But at the end of the day it needs to tie back to the P&L. You’re paying us X, we’re netting you Y, and Y needs to be much greater than X for you to be convinced to buy.

The customer is usually evaluating other tools in the space at the same time. So the path you take as an FDE is not just implementing the thing. Before you even implement it, you decide on the metrics with the customer. If we can prove out this percentage increase on this productivity or revenue metric, that is the success criterion for this POC.

It’s hard to measure AI workflows. You can’t just run the pilot for a month and at the end say, here are the reports. It has to be something you track from the beginning. Some metrics are genuinely impossible to track, but as much as you can, you need to be forthcoming with the numbers. It’s less of a technical problem than it is about managing customer expectations and building trust in the fact that you’re both looking at the same metrics.

On the POC itself, do you prefer to go narrow and end-to-end, or wide with a big magical moment?

Narrow and end-to-end, almost always. You prove out one part of the product that truly works, with measured metrics against it. You acknowledge there are other parts of the product that will have tangible or intangible benefits over time, but you have one clear thing to measure against.

The risk with going wide is that you don’t actually end up proving ROI, because that isn’t how the product will be used in practice. You can also build something so bespoke to one person’s workflow that it just doesn’t generalise. Starting narrow also sets up the next conversation. If you delivered something concrete in a week, it’s easier to make the case for what five weeks would look like.

How do you handle context gathering? No FDE I’ve spoken to has managed to collect everything up front.

I don’t think the answer is getting 100% of the information you want up front, and I don’t think it’s unique to being an FDE. This is a customer success problem that’s existed for as long as companies have been working with each other.

It does become easier in the age of AI. If the customer is already using AI tools, or has a bunch of documents scattered everywhere, you can ingest it, build a vector database, index it, and get somewhere. But the business end of it is never a technically hard problem. It’s that they don’t know what to send over, and we don’t know what they have unless we ask for it.

The approach I like is separating it into high-level and low-level. You have an initial high-level discussion to determine feasibility, scope the work, and agree on an architecture. Once you have that, you have enough confidence to move into implementation, where the nitty-gritty details surface.

A common one is approval processes. A lot of them are very unique to a business. It’s not even based on roles, it’s “Samantha is the approver here.” And what happens if Samantha leaves? Who knows. That kind of data isn’t something you can scope up front. You just have to know, going in, that someone is approving this, and build to that shape. You figure out who the someones are later. By asking the big questions you get 80% of the way there. The last 20% is what’s painful, and it just sits in the tail of the project.

When is a project actually done? How do you close the loop without endless scope creep?

This was something we had to figure out at Actively, because we would never stop. At Rippling we realised we needed a harder boundary, otherwise the model doesn’t scale.

The way you solve it is the way any SaaS product tends to solve it. Contracts and guidelines that outline the scope. This is what we are going to deliver. Once we deliver it, your problem should be solved. The initial scope becomes a document both parties sign and are beholden to. It works the other way too. If we don’t implement what we said we were going to, you can hold us accountable.

Whether the scope document is pre-commercial or post-commercial doesn’t really matter. I’ve talked to FDEs at other SaaS companies and it varies a lot. There is a difference in how much leverage you have in that conversation depending on the stage of the company. A larger, more established player can push back on scope in a way that a seed-stage company doing forward deployed work simply can’t, because they don’t yet have the leverage.

The FDE job description tends to read like a unicorn spec. Kanav spent almost three years at Amazon before moving into the role.

What was the hardest part of that transition, coming from a core software engineering background?

Two things stood out. The first was context switching. Whatever size of company you’re at, as a core software engineer you have layers of separation from the customer. PMs, sales, customer success, sometimes your own manager. That shielding lets you dive into your technical environment, and that’s what it was for me at Amazon.

As an FDE you might be on one customer call right now, another half an hour from now, and you have that half an hour in between to code something. You never get to truly lock in. That’s a hard skill to master, and I don’t think you fully can. Humans have a context window, like agents do. You try to minimise context switching where you can, but you also have to build the muscle of doing both parts of the job.

The second thing was interfacing with customers directly. You think there’s always a layer of separation, where you have to be professional because you’re representing the company. But true discovery happens when you’re fully comfortable with the customer and they’re fully comfortable with you. Being able to embed in their process, learn their business immediately, pick up the nuances of it, and ask the right questions to get them to open up. That’s a muscle I had to build over time.

On the depth question, Palantir is famous for sending FDEs to embed with one customer for months at a time. That’s obviously not feasible at most AI companies. How do you think about depth versus breadth?

Unfortunately, it isn’t really something you get to decide as a company or as an individual. It’s decided by account size, by ACV, by ARR. It becomes a question of economics. Whether you can afford to embed a whole FDE into one customer’s workflow.

Palantir is one of one. As you move to AI companies, or AI-forward companies, the FDE almost always has to manage multiple implementations in parallel. With the Palantir model, you have the advantage of learning one business really deeply. With the multi-customer model, you want depth but you also need breadth. Over time breadth becomes more important, as does the ability to pick up new things about new businesses quickly.

If you’re dealing with a large enterprise tech customer versus a big restaurant chain versus a retail store, their workflows differ drastically. You have to be able to pick it up and embed in all of them at once. You probably won’t reach the same depth as someone working on a single project. But that isn’t within the control of an individual. It’s dictated by the economics of the situation.

We’re software engineers by training and we tend to aim for close to perfection, but the role doesn’t always allow it.

It’s something you have to get used to while using AI products anyway. A lot of traditional software is deterministic. AI products mostly aren’t. You can make parts more strongly typed, you can build strict guardrails around certain components, but as a whole, software is moving in a non-deterministic, directionally correct direction. That has to be good enough. Even if most of your end-to-end solution is deterministic, one probabilistic link makes the whole solution probabilistic.

You’ve described the FDE role as a kind of founder bootcamp. Why?

I’ll call on what one of the co-founders at Actively used to say. There are really only two things that make money if you think about it abstractly. Building things and selling things. Engineering and sales. The FDE role sits right in the middle of that.

A founder goes through a process where they’re building a product and also doing customer discovery. Who wants this, what are their pain points, what would help them do things faster, or eliminate manual work. You figure that out in the customer discovery part, but you also have to immediately tie it back and build it. That’s what I feel like I do every day, whether it was at Actively or now at Rippling.

At both companies I’ve had the benefit of a sales team and a core product team supporting me. My job is to create the link between them. Because of that link I’ve learned a huge amount about the sales process that I never would have as a core software engineer, and a lot about building things I wouldn’t have picked up in sales. And it isn’t only sales. It’s marketing, customer success, RevOps. All these teams I converse with and learn from, whose workflows I end up observing. The same thing on the engineering side. It isn’t just building. It’s making product management decisions, small ones, but real ones, to build the software correctly.

You do a little bit of everything. And as such, it helps you build the skills to run your own company one day.

Anything you’d want other FDEs to keep in mind?

The role is still rapidly changing. If you discount Palantir and look only at the AI world, the oldest FDEs at AI companies are maybe a year in. Everyone is still figuring out processes. Part of the job is understanding that this is a role filling a gap that exists right now. AI makes it easier to build software and easier to talk to customers, so I think the role is here to stay. But what the FDE role looks like now versus a year from now could be very different. The core products we use and the industry we’re in are changing that fast.

Kanav Bhatnagar is a Senior Forward Deployed Engineer at Rippling, where he’s on the founding FDE team building out the function from the ground up. He was previously an FDE at Actively AI and a software engineer at Amazon.