– English Lyrics

Lyrics & Translation

[English]

With AI agents, there is no incumbent

product. And so that I think is why

you're seeing the FTE model taking off

because there's so much product

discovery to do. You want to drive the

contract size up. So you're doing more

and more valuable work for this customer

and also for future customers. The FD

model effectively is doing things that

don't scale at scale.

[Music]

Hello and welcome back to another

episode of the light comb. Gary wasn't

feeling great today and couldn't be

here, but we're thrilled to be joined by

Bob Mcgru. Bob was an early engineer at

PayPal, an early executive at Palanteer,

and was recently chief research officer

at OpenAI, where he led the development

of chat GBT, GPT4, and the 01 reasoning

model. Now, he's exploring the future of

AI and has an exciting new role with the

US Army that we'll get to in a bit. Bob,

thanks so much for being here. It's

>> great to be here.

>> So, Bob, I've been particularly excited

to sit down with you to talk about the

Ford deployed engineer model because

this is a topic that keeps coming up in

our lives. It is a really hot topic in

Silicon Valley right now and especially

among the AI agent companies that we've

talked about on this podcast a lot. You

were in the room when it all got started

and so you know like you're exactly the

right person to explain it. You were

actually telling me a a funny story. uh

you were at an AI conference that YC

organized a few months ago and you

expected that all the founders would

come up to you to talk to you about you

know inventing chat GPT and instead what

all of these AI startup founders wanted

to talk to you about was the Palunteer 4

deployed engineer model

>> well and it it's really true it hasn't

hasn't just been that one conference uh

as I've been advising startups this last

year I would say that a lot of them are

pretty much exclusively trying to learn

how the FD strategy works

>> yeah so there's is this intense topic a

fascination and it's super timely

because it's actually become I think the

dominant way that the AI agent startups

are organizing themselves. I was looking

earlier today and if you look at the YC

job board there's over a 100 YC startups

that are hiring for a job with the title

for deployed engineer and up from

basically zero 3 years ago. Perhaps

before we get really into it for anybody

who doesn't already understand, can you

just explain what a forward deployed

engineer is and how it's relevant today?

So a forward deployed engineer is

someone typically technical and engineer

who sits at the customer site and fills

the gap between what the product does

and what the customer needs.

>> And how does this play out in practice?

>> You'll have a product and you go to a

new customer. you you start working with

a new customer and you the the problem

that they want you to solve is not a

problem that you've ever solved before

but you believe that it's one that with

a little bit of work maybe a lot of work

you can solve for this particular

customer and you'd be making a huge

impact for them you'd be delivering an

outcome to them that would be extremely

valuable for them so you take the

product that you have and the FTE with

help from the product team figures out

how to deliver that outcome how to build

that use case how to you deliver the

piece of software that you've built in a

way that actually works for the

customer.

>> To go all the way back to the beginning,

you were there at Palunteer when this

whole model that is now like exploding

in Silicon Valley was invented. Can you

talk about how it all got started?

>> The interesting way to think about the

beginning of Palunteer is that uh when

we got started, the focus of our company

was to build software for the

intelligence community, specifically

software for spies. And so one of the

challenges in building software for

spies is that I don't know any spies.

You probably don't know any spies

either.

>> Nope.

>> And uh if you happen to find a spy and

you go and ask them, "So, what is it

exactly that you do?"

>> Um they're not usually going to tell

you.

>> And so um we had to take an approach

that was sort of very unusual at the

time, but effectively we started by

building a demo and we took that demo to

potential customers in the intelligence

community. And uh you know Stefan Cohen

very famously did this, one of the

founders of Palunteer. And he showed

them the demo and he said you know well

what do you what do you think? And they

said well this is terrible. This isn't

related to what we do at all. And he

said oh well how would you like it to be

different? And then you know they would

say oh well could you make this change

and this change? He's like sitting there

writing all of this down. So far this

story feels very much like you would the

standard advice you would give to

founders today, right? that you have to

go you have to make something people

want. You have to get out of the

building. You have to go talk to

customers. I think we were we were doing

this back in the in like the mid 2000s.

And so, you know, there's a little bit

of that meme where like I spent years

mastering this technique and Paul Graham

just tweeted it out for everybody. Mhm.

>> But the thing that changes uh and that

really causes the FD strategy is that

what you expect and the the standard

thing that you expect is that you spend

a lot of time early on, you know, doing

things that don't scale, going out and

visiting customers, getting very close

to the customers and then you discover

product market fit. And once you

discover product market fit, you know,

if you and this is class, you know, if

you read Crossing the Chasm or any of

these books, once you discover product

market fit, you do something entirely

different. So, you know, instead of

going, you know, staying deep with the

customers, doing as much as you can to

really understand the customer, instead

you want to embrace distance from your

customer and all you want to focus on is

scaling. How do you sell more? How do

you treat all customers exactly the

same? And you know, I I I think I want

to say that if you're in a business

where this is working for you, that's

great. Don't do the FDU strategy. You

have been given an amazing gift. Uh if

you have the opportunity to just scale,

treat all the customers the same, go

ahead and do that. Um but it didn't work

for us and I think this is where uh Sham

Sankar who's very early employee you

know now I think the president and CTO

of Palunteer he really invented the FDA

strategy and the the basic thing we

found was that the customers that we had

the product that they needed was

slightly different at every place and so

we moved from one customer building a

product for them we went to the next

customer we saw they had something was

slightly different And instead of sort

of building two products or building the

exact right feature for each of them at

each at each site, we built something

that was more a platform than a product

that had the a lot of a lot of ability

to be customized at each site. So when

you do that, well, okay, you need to

bring someone to the site to understand

what the users are are doing and you

know, build customization and

historically that's been understood as

services, right? So that's something you

want to minimize. You don't want to be

doing a lot of work per customer in

this, you know, product market fit. And

what Shawn realized was that you can

actually flip this around and make it

valuable. So what he realized we needed

was for the FTEEs to act as product

discovery. So they would go to the site,

they would take the product as it was

and they would fill the gap between what

the product did and what the users

needed. So you know the FD goes and

builds like a a gravel road to where the

product needs to go. And then the role

of my team of the the product and

engineering team was to look at that and

basically figure out how that should

generalize to the next five customers or

the next 10 customers and then turn that

you know gravel road into like a paved

superighway.

>> I feel like sales is product discovery

is a concept that's not new. It was

certainly around before Palanteer but

typically the view used to be like you

had your sales people that went out and

did like the sales and talked to the

customers and they came back and

reported to the engineers. But it seems

like at Palunteer it was like the

engineers were doing that work. Was that

like a conscious decision or how did

that come about? Especially when you're

selling into like the government and

defense like you would imagine the

natural inclination is to go hire some

like experienced salesperson who's got a

history of selling into the government

and

>> some like Don Draper like who wears a

suit and worked in the DoD for 20 years

and like takes generals out to steak

dinners and things like that. And that's

actually not what you guys did, right?

Well, I mean, there's two angles. This

one is, uh, we talked to a lot of those

people early on and they said, "Why the

hell would I work with a Silicon Valley

company when I could work with, you

know, a big five defense prime?" Uh, and

then even when we talked to people who,

you know, seemed like they might be

successful in this role, it was just

very clear to us that they wouldn't mesh

with our culture and they wouldn't

actually be successful. And when we

tried doing something like this, it

almost never worked. And so, what we

found was very different. And and I

think the difference between salesled

product discovery and FDLE product

discovery is that salesled product

discovery you're talking to people from

the outside. And again, this is

important very early on, but it's not as

effective as the FDLE product discovery

where you're solving these problems from

the inside. So, you know, the scope of a

of a traditional implementation might be

you start with something that's pretty

close to what the product does, but you

want to be solving one of the key

problems that leadership has identified.

If you're not solving one of the top

five priorities for the CEO, it's

probably not going to work. They

probably won't have the energy to

persist through the much more

challenging route of getting effectively

a new piece of the product built in a

way that worked for them. Then once

you've solved that first problem, then

the FTEES can, you know, identify other

key problems in the enterprise,

sometimes much more valuable problems

than the ones that you were first

targeting that maybe it's not obvious

that Palunteer could have solved those

problems or that your company could

solve those problems, but once you're

there, you can see through product

insight that you can actually do this.

And then you go and solve those

problems. And so it switches from, you

know, how do I sell the same thing to

each customer to how do I land and

expand?

>> Bob, can you lay out sort of exactly how

the FDU bottle works at Palunteer? Like

if you were giving people almost like an

an instruction manual like like here's

how we did it.

>> Yeah. So I think a starting point is to

think about how the team was structured.

Um, and of course there's many different

iterations, but I think this is this is

the the key thing that remains constant

is that the two key roles are those of

what we call the echo team and the delta

team. The echo team were embedded

analysts. So they would go to the

customer site, they would speak to the

users, they would uh try to figure out

what demo or what use case uh really

made sense for the users at this site.

What was the key problem that could be

solved? And they would also be the

account managers. So they would also be

the people managing the relationships at

the customer site. And the delta team uh

the deployed engineers were effectively

software engineers typically very good

at writing code extremely quickly eating

a lot of pain as we put it.

>> And they would be the ones who sort of

took those ideas and brought them into

the real world and built a solution, a

prototype, but something that could

actually work. and then deploy that uh

for the customer. And all of this would

come in a very short period of time. So,

you know, you go in with an idea for

what you're going to work on. You set

up, you know, a few months in that

you're going to, you know, have a

presentation with leadership to show

them your progress. And then if that

presentation goes well, then you're

going to actually deploy and go, you

know, organizationwide. The interesting

thing about these two roles is very

different kinds of people and profile.

How would you even go about finding the

right person to be in these roles?

Because it's not just a regular engineer

that could fit FD. They needed to have

more of that talking to users or the

echo team also have to be more

technical. It wasn't just an account

manager. How do you Palanteer build this

early team?

>> Yeah. So the echo team, you know, a

classic profile for someone to join your

echo team would be someone from the

domain you're working in. So, you know,

possibly a former army officer or

someone who worked deeply in healthcare.

So, they have deep domain knowledge, but

and this is really important, they need

to be rebels

>> or Sean would probably call them

heretics. They need to be someone who

understands how things are done right

now and recognizes that it's

insufficient, that it doesn't work.

Because if if their perspective is, you

know, they come from this world, it's

great, then they're never going to be

able to figure out the step function

change that the new software has to be

able to make because if you can't make

some sort of, you know, 3x or 10x change

within that organization, then, you

know, there was no reason to go through

all the effort of doing this. Um, you

might as well have sold some sort of

like very simple piece of software. So

that's that's the key profile for the

echo. And then for your deltas, um, you

want someone who's really good at

prototyping. So the wrong profile for a

delta would be someone who's a

craftsman, who really loves, you know,

making sure the abstractions are exactly

right, that, you know, they're building

software that's going to be maintainable

for, you know, a dozen years, right?

Because that's not the role. That's not

the job. And what you want is someone

who can go in, you know, figure out,

write some rough and ready code.

Sometimes that code is beautiful if you

get the right person, right? But usually

not that again that's not the key

portion of the job but someone who can

who can go actually deliver that outcome

in the form of software on a timeline

and then it may be the case that the

first version they write has to be

thrown away and maybe they write a

complete second version maybe someone

else writes a second version depending

on that person but those are those are

the key sets of skills.

>> It does sound a lot like a founding

team.

>> Yes.

>> It sounds a lot like a founder. Yeah.

Would you hire former startup founders

and turn them into these roles or did it

go mostly the other way? I mean, I think

it's no coincidence that Palunteer has

spun off like an incredible number of

startups because this FD training, this

is like exactly the training to become a

startup founder, you're learning all all

the startup founder skills, right? But

did you go in the other direction too?

You know, back in the day when we were

getting this started, uh there was not a

huge supply of founders for us to pull

from. Uh I I think, you know, maybe they

maybe that's the opposite now, but but I

think it's I I think you're actually

quite right. what you're doing uh you

know in each of these new environments

at each of these customer sites is a

little bit like being a startup founder

but you're a startup founder where you

have access to some very powerful piece

of product leverage that makes your job

easier. This is I think great training

and like you said this is why you see so

many startups from Palunteer founders.

So the the common knock that you hear on

this from people who don't really know

what they're talking about is like oh

it's just consulting dressed up with

fancy marketing speak. Why is that

wrong? I think before I say I don't want

to tell you glibly why that's wrong

because I think there's actually a real

risk that it's right. Right. And I think

you know if you if you go back to 2015

and you talk to people about Palunteer

maybe you would hear two things. One

that Palanteer is evil. Um but the

second thing you hear is that it's a

consulting business that is never going

to scale. you know that it's actually

like a bad business. It's not a software

business. And we spent a lot of time

trying to understand whether that was a

correct characterization or not. From a

business model perspective, one of the

key things that you will see that you

should see is that it may be the case

that your when you go into you do a new

deployment at a customer that you're

actually losing money early on. As the

longer you're at the customer, first

thing is your product because of the

product discovery gets better suited to

what the customer does. And so you no

longer need a large team of people at

the customer site figuring out what the

customer is doing, you know, paving, you

know, writing that code. The second

thing is that you should be earning the

right, as Sean would put it, to have

access to more important problems at the

customer site. And so you should see

basically that your cost per value of

the outcome you're delivering is going

down. And so your profit margins start

off negative but then ultimately become

positive after some period of time,

maybe a year, maybe multiple years at

the customer site. And if you look at it

from that perspective, you can see that

you're actually delivering, you know,

real repeatable value.

>> I guess one fascinating piece to make

this work and drive the cost down is

really the product team.

>> Yes.

>> So how does the product team fit in and

work with uh with FDE team? I think on

the engineering side uh it actually you

know it it feels my my job on the as an

engineer was actually not so bad because

early on in the early days of Palunteer

you know we were you know doing this

founder led discovery and we were you

know building new products and later on

at the later days of Palunteer we were

still doing that we were still building

new products this felt great right um

but the roles that were really different

are um the the FD team but then also the

product management team and so um the

product that you're building instead of

being highly verticalized

And you know this is one flow that

millions of people are going to be going

through like if you're building Airbnb

right instead the role of the product

team is is really to hold the product

vision

and so you have to think when I see this

new problem that we're seeing at a

customer site what is the generalizable

version of this that applies to the next

10 customers because if you you know

there's a a classic failure mode here

where you know the FD implement

something for one customer and you say

great well that's how you should do it

and you bring it directly into the

product and it turns out if you do that

you're building something that's over

specialized for one customer and so the

part of the magic here is being able to

build the kind of product and with the

the kind of product people they can look

at that and sort of guess the correct

problem that you're solving which is

always a little bit more general than

the problem that the customer is coming

in with

>> so there was some wisdom um to figure

out which bucket it fil fit. Is this

just for this vertical or it could be

generalized? So could you give us like

an example of what that looked like in

terms of the products and verticals and

what fit in one bucket versus the other

one?

>> Yeah, I mean probably the the sort of

like most basic example here is is sort

of the invention of the Palenter

ontology itself. And so when we first

started talking about working with, you

know, the US government and specifically

working intelligence, you know, should

we have a database table for people and

a different database table for money and

a different database table for this? And

this is super obvious, I think, at this

point. If you if you go down that route

and you try to deploy to multiple

people, your your database doesn't make

any sense. And so, you know, the the

change here was say, well, we need to

pull this up to a higher level of

generalization. And instead of thinking

about specific types of objects um we

should allow that to be defined per

customer by the forward deployed

engineering team. And so that's the sort

of origin story of where Palen Palunteer

famously got its ontology.

>> So how does that work today? Is there

like a base database schema that has

common reusable objects like people and

money that then gets customized per

site?

>> Well just I mean the database scheme is

extremely general. there's just this

notion of objects, properties, media,

and links between objects. And in here,

I'm talking about Palanteer's government

uh product, um which was our first

product. But the ontology is what

encodes all of the specialized

information that's per customer. And you

know, that says, oh, well, this is, you

know, a person, this is a ship, this is

a money flow. And again, this is this is

I think really the very most basic

example, but you know, if you build

something for just one customer, then

you're going to be thinking in, you

know, the description that applies to

that customer. But instead of saying,

"Okay, well, for people we do this," you

want to be able to pull it up a level

and say, "Okay, well, there's this

common operation that we want to apply

to things that have this property." Like

people have this property, but maybe

also ships have this property, but let's

be honest, money payments do not have

this property. And so, you have to think

at a higher level of abstraction. We

didn't hire product managers for a long

time. And when it did come time for me

to hire product managers, I would

interview people who were amazing

product managers at, you know, other

companies. And I would ask them to to

think at this level of abstraction. And

they were very they couldn't really

think at this level of abstraction. They

would say, okay, well, this is the flow.

This is what it should look like for

this customer. But that that was the

wrong thing to do here. And they needed

to to pop up a level and think at the

level of like, how does this work in the

context of the ontology? How do we

change the ontology so that you know

this specialized thing works across

customers? And of course there's many

other examples that don't have anything

to do with the

>> ontology. Does that create any sort of

cultural tension at Palinger itself? It

sounds like you're describing like the

FDES are sort of these like heretics.

They like don't want to generalize. They

want to do what's best for the customer

and um build specialized solutions. But

presumably for your own internal product

team, you do actually want to hire the

people who can think at some level of

abstraction and want to build like

maintainable code that lasts for a

while. Surely that must have created

tension somewhere where there's an FDE

who's like no I don't want to use like

the like the generalizable ontology. I

want to kind of like do it this way.

Well, I mean absolutely there was there

was always a lot of tension and I and I

I I I would not frame this so much in

terms of like the skills that different

people had because it was also very you

know I think it's a lot about the

environment what people do in the

environment they're placed in. It was

also very common for FTEEs to work in

the field for a long time and then say,

"Hey, I can I can really fix these

products and then come in and do an

amazing job, you know, on the product

side and think at that level of

abstraction." But when you're at the

customer site, you were faced with one

very

>> The incentives are different versus the

skills are different.

>> The incentives are different. And so,

you know, you're solving one very

particular problem and it makes a lot of

sense to just take the simplest approach

to solve that problem. Um, and and that

is in fact what the FD should do. That's

what the gravel road looks like. And

then the paved road though, you know,

has to has to go by not just this one

customer, but like a bunch of other

customers that are further down the

road. So the paved road often looks a

little bit different. But the flip side

of this though is, you know, imagine you

said, well, clearly this FD approach is

just wrong. Like the FD is building the

wrong thing. What if the product team

just thinks really hard about what to

build and then they go build that?

They're absolutely going to build the

wrong thing. In fact, the the way that

we would often build features early on

is that, you know, first the FD team

would build something, they'd see

something at one customer, we'd bring it

back to the product team in PaloAlto and

we would say, "Okay, what's the right

generalized versions?" And that those

FDEs would participate in those

discussions,

>> right? That was incredibly important.

>> And then we'd identify several other

customers. Well, if it worked for this

customer, we think it could work for

this other customer. So let's bring the

FDS from those customers in as well and

help them design and they they can help

us design this feature so that when we

build something we know it'll work for

you know the customer it was initially

prototyped and we know it will work for

these others and then of course you know

if you're once you've built that context

where everybody can say here are three

different workflows that are subtly

different then suddenly you're not

having this argument about like well you

know we think it should be general and

we think it should be specific but

everybody is solving the same problem

and then I think that that really melds

the incentives.

>> Do you feel like it requires a lot of

organizational discipline to keep this

model from devolving into pure

consulting where the FTE teams are just

off building like whatever product the

customer needs?

>> Yes. Uh you absolutely have to focus on

this. Um and I I think one of the other

failures by the way it's even prior to

that and and more the the easier failure

to become a consulting firm. It's where

you build the product in the field that

the customers are asking for

>> rather than the one that's actually

valuable to them.

>> Because it's often the case that the

customer, right, you don't actually

customer is like a whole organization.

You don't talk to the customer. You talk

to maybe the CIO, right? Or you talk to

one sponsor, usually a couple levels

down from the CEO who you only get to

see every once in a while. And it's

often the case that they would rather

just have you solve some problem that's

easy for them to have you solve rather

than one that's really impactful and

improves the business.

>> Going back to the opening from Jared,

what's going on with all these AI

companies really now ramping up and

hiring tons of FDES? What has what had

caused them to really adopt this model

which was not the case for the previous

generation of companies with SAS? What

happened? Especially because I feel like

even as Palanteer became successful and

the FD model became more known, it was

still seen as well, you that's a one-off

thing because Palanteer is a unique

company and selling to the government.

Yeah. Like like a like a like a really

weird thing.

>> Yeah. But you wouldn't don't try this at

home

mindset, right? Like now everyone's sort

of it's become like Diana said, it's

become very common place. Has that one

has that surprised you? And then two,

like why do you think that's happened?

This was absolutely a surprise to me

that you know my first, second, and

third pieces of advice to people who are

thinking about trying an FD strategy is

like don't don't do this at home. If you

can avoid it, like it's it's probably

bad for you. Probably you're going to

end up doing services and then only if

you really try hard not to do it and

fail then well then maybe actually it's

a moat for you if it's the only thing

that can possibly work in your market.

So what's special about this market,

right? Why does the AI agents market uh

work this way? Maybe the the starting

place is why did Palunteer have to adopt

this? The Palunteer market is not one

coherent market, right? So, we were

working with national intelligence

agencies, with national law enforcement,

with the military. All of these

organizations had some similar projects,

right? But even, you know, the

difference between a counterp

proliferation workflow and a

counterterrorism workflow. one you're

trying to figure out, you know, who's

building bombs and the other one, well,

who's building nuclear bombs and who's

building IEDs and those are actually

quite different in terms of how they

work. And so there's this incredible

heterogeneity and the market, you should

really think of the market as different

segments inside each segment. You can

build something and you know the

crossing chasm story a little bit

applies. So you know you're you're

starting off you know nothing seems to

work suddenly you find product market

fit in the segment you know you can

deploy the people that are doing this

kind of workflow and then you know at

the next customer you find the same

people doing a similar workflow and you

can deploy with very little

customization but then there's a natural

limit to that and so now you want to go

tackle a different market segment and

you have to you know develop a new piece

of technology and then that can be

referenced in in other market segments.

And like like I'm sort of saying here a

segment is not the same as a customer

necessarily. Um especially in an

enterprise or a very large enterprise

like the government where a customer is

you know tens of thousands of users

potentially in that case that's where

you know the FD strategy matters because

you're doing you know it's like you're

doing things that don't scale but you're

doing it scalably over and over again

for every market segment that you enter.

Why do we see this with AI agents? I

think the other thing that's unique

about Palunteer is that we were building

a completely new type of product. The

product that the users saw well you know

they were used to basically you know

tracking doing their analysis and

tracking people in a tool that looked

like PowerPoint and they would

collaborate by sending these files back

and forth with each other. But the

product we built was tied basically

said, "Hey, when you're, you know,

drawing out that link diagram, you're

not just editing a file. You're actually

changing a database and everybody has

the same database." And so, while to the

user, it looked like an a small change

on top of the the work they were doing.

To the enterprise, to the organization

we were selling to, it was a completely

different market category. And that I

think is what's happening with AI agents

where you know this is a completely new

market category. If you are implementing

you know a standard SAS product and

you're replacing one way of paying bills

with a different way of paying bills

everybody understands what that market

is. And so you know the the segment you

know there's not all this little

segmentation. There's not a lot of

there's not the same kind of product

discovery. you can then you know make a

product that's better than the incumbent

product and scale by replacing that

product with AI agents there is no

incumbent product and so um also I would

say what it is to build AI agents is

actually probably a lot of different

things and we don't know what those are

yet we've got to figure them out

probably in five years we'll look back

we'll be like well AI agents it wasn't

even a thing at all right we were

actually doing all these different

things and so that I think is why you're

seeing the FTE model taking off because

there's so much product discovery to do

and you can only do it from inside the

enterprise.

>> Okay. How does this relate to um some of

the classic YC advice which is do things

that don't scale?

>> Well, that's the advice that you give to

an early stage founder and the FD model

effectively is doing things that don't

scale at scale.

>> YC's next batch is now taking

applications. Got a startup in you?

Apply at y combinator.com/apply.

It's never too early and filling out the

app will level up your idea. Okay, back

to the video.

>> Since you see a lot of people trying to

apply the FTE model now to their new

startups, including a lot of people who

didn't work at Palunteer and are sort of

doing it like second or third hand, what

are ways you see people getting it wrong

or misconceptions that you'd like to

dispel? Maybe I will start by saying as

I've advised a few different startups

who are doing this. I think the startups

the most successful startups doing the

FD model have people from Palunteer

running the FD model. The startups that

are that I've talked to who are

switching to the FD model gained a lot

of benefit by bringing on someone from

Palunteer in, you know, one of the core

roles. As I said, the engineering team

is often fairly similar, you know, but

maybe, you know, continues to be fun for

a long time. uh but the actual mechanics

of how the FDS work, how you build these

accounts, how you find the outcomes,

those are those are actually quite

different from a standard software uh

firm. And so one of the the key

differences uh and and something that I

think is actually quite difficult for

people to understand is uh how you

choose a problem and then how you price

that problem. And fundamentally what

you're selling with the FD model is that

you're not selling the installation of

software. You're selling an outcome. As

Sean would say, you're selling that you

have solved a problem. The next question

then is if you've now solved a problem

that is valuing, you know, delivering

some value to the users, how do you

price that? That's a very common

question we get from all these AI

startups because

>> in the age of SAS you would do it based

on usage or subscription or seats

>> and this is completely different is

outcomes. How do you even price it? How

should all these AI founders price their

solution?

>> Yeah. And I think one of the the the

really important things that is

differentiated between the FD model and

your sort of standard SAS model is that

with the FD model with a SAS model and

you know product market fit you're going

towards you know very simple repeatable

contracts very simple repeatable pricing

that makes sense across all of your

customers and you know often you're

you're going to be quite comfortable

with small contracts because the cost

the marginal cost to deploy is very low

with the FD model you're going to get

pushed towards larger and larger

contracts. Um, like we talked about,

you're going to be growing contracts per

customer over time. The contracts

because they're complex are going to be

more flexible.

>> I think this is what the AI startups

that we work with discover on their own.

I have this company called Castle that

does uh AI voice agent for mortgage

servicing. So they work with very large

banks and the way they actually been

able to go live with large banks is

exactly that model of ramping up is the

number of successful calls that were

handling all these mortgage requests.

Then they had like stipulations when it

goes to scale it would be this much and

that and they kind of figured out on

their own and other startups as well uh

like Happy Robot is another YC company

as well doing AI voice agents for

logistics. They're working with large

companies like DHL similar thing.

There's an asymmetry here between you,

the startup, and the business that

you're selling to, which is typically

when you're selling to a large

enterprise, they don't believe they can

actually accomplish anything. And that's

because often times they've had many

large projects that have failed. They

also don't believe you can accomplish

anything, right? Because they think that

you, the startup, are just like them.

You, on the other hand, know that you

can actually execute, right? And if you

can't, well, you should go into a

different line of business anyway,

right? And so early on it makes sense

for the startup to just take on all the

risk and say we're going to just believe

in our own execution

and you know we're going to take on the

risk and you pay us if it works or you

pay us when you know we're actually able

to expand. The one place this can go

wrong is that particularly if you're

doing a something that needs to be

deployed into the enterprise uh you know

on premise

>> uh or any piece of it needs to be on

premise rather than in the cloud you do

have to fight the IT team.

>> Yeah, actually seeing that too.

>> Yeah,

>> with some of these companies

>> and more generally who needs to say yes

inside the organization you're deploying

into in order for you to succeed because

those people do not think like startups.

they are not aligned with the end user.

And so you're going to have to figure

out a way past them. And you know, this

is part of why it matters that you're

working on one of the CEO's top five

problems because you need to be able to

bring in someone from the top to say,

"Yes, give them authority to operate.

Give them, you know, the ability to use,

yes, you use this particular type of

database. They need to use a different

type of database. they you know you have

all these spec very specific

organizational things that are meant to

apply to your IT staff who are building

things in house but they don't apply to

the startup let them do what they need

to do

>> how do Palenter get that executive buy

in I think this is sort of what

happening with all these AI startups

that taking off and going from zero to

seven eight figures in revenue within a

year they figure out the executive buyin

but it's all very haphazard I would say

from all the stories I know of.

>> That's how it felt early on, too.

>> Okay.

>> Right. Um, it's a discipline. It's a

skill. You know, you need really amazing

leadership on the FDA team to be able to

have that kind of discipline and, you

know, to share what works, you know, and

just get the practice of doing it at one

customer. I mean, I think it's not

surpris.

That's that's why, you know, the c the

companies I've seen that have done this

the best have sort of pulled that from

people who've done it before. Um, but it

can be learned. We learned it.

>> Jared point out earlier that the I think

this the palenteer forward deployed

engineer model is not that different to

sort of like classic YC advice around

doing things that don't scale. Um, we

have this concept of like the Collison

install, which is essentially we boil it

down to don't wait for people to turn up

to your website, like go to them and get

them to like install the software

>> and like physically go to them, like go

to their office and like sit next to

them.

>> And I feel like um it's always been a

great starting strategy, but most

startups aren't getting big contracts

off the bat. So actually the the reason

they have to stop doing sort of like

this sort of manual hight touch process

is you just can't get the growth rates

to sustain without at some point having

a product that scales. And it's kind of

like what we were talking about earlier

like at some point you hopefully you

build a product that's so good that

people can figure it out themselves and

then all of your problems are just

scaling it. With AI what's different is

because these contracts are so big now

you can actually go quite far by doing

like the hightouch thing. And maybe

something you could help us out with

actually is like probably a common

office hour question I get is like how

far can I keep pushing this? And my

advice is largely like well like it's

okay to be doing custom work per

customer. You just want to get less

custom per every customer. Maybe you

could give like more specific like

higher resolution advice. It's like how

do you know if it's okay to like keep

adding new customers in this sort of

like hightouch like I'm doing lots of

custom work way versus oh no actually I

need to be like abstracting out um and

building like an actual product here.

Yeah. And I and I think this this is

actually really encapsulates the the key

difference between you know the the

product market fit strategy and the FD

strategy. In the product market fit

strategy you want to be doing less work

for every customer. You want to be

driving down costs. You want to keep the

contract size the same. Yep. In the FDA

strategy, you want to drive the contract

size up. So, you're doing more and more

valuable work for this customer and also

for future customers. And because you're

doing more valuable work, it's okay. You

can leave the amount of customization

you do per customer the same.

>> So, the KPI or the internal metric is

like contract size, not necessarily like

how much custom work they're doing per

customer.

>> There's two useful things here. So, one,

the thing you can measure, yes, contract

size. Um, I would even be a little bit

more general than that and say the value

of the outcome you're delivering

>> because that's that's actually the true

thing, you know, and do you yet have the

muscle in order to be able to monetize

that and price that and capture that?

Maybe not. But if you're able to deliver

more and more valuable outcomes to the

customer, then you know you're you're

doing something right. The second piece

that we haven't we didn't talk about yet

is uh the value of the product. And so

the other thing you want to measure is

are you getting more and more product

leverage against that outcome. This is

all extremely counterintuitive when

you're in it. It's very hard if you're

an FTE or if you're leading an FTE team.

There's a lot of things you have to do

that that seem very counterintuitive.

You have to, you know, build for the

customer things they're not asking for

but that they actually want. On the

product side, you often think to

yourself, how do I make a product that's

just really easy for every customer to

use? It's very easy. And and look, I I I

struggled with this myself quite a bit

leading product early on like you want

to focus on on the user experience and

you have to do that, but you also have

to remember your other key customer is

the FTE. Your product should be, you

know, ultimately delivering a good thing

to the user after FTE customization, but

it should be delivering leverage to the

FTE who's delivering that outcome at the

customer site. And that that amount of

product leverage should be going up over

time. like they should be able to use

your product to deliver more value to

the customer without them having to go

and like pull in three more engineers in

order to do it.

>> That's right. If you know the first

customer you deploy at takes a lot of

work. If you want to then go sell that

same outcome to a different customer,

then that should be a lot easier at the

second customer and it should get easier

still as you go customer by customer.

But then if you if you really get it to

work, remember that you're building a

platform. So you're doing more than

just, you know, a stack of vertical use

cases on top of each other. If you've

correctly abstracted away what the core

concept is that you're really building,

then you should also have an easier

time. You should have more product

leverage even when you're not doing that

use case, when you're doing something

that's sort of similar. Or you will find

that your FTEEs, if it's a really if

it's really good, you'll find your FDES

can figure out some new way to use that

technique you built to solve something

completely different. There's almost

like an internal market dynamic going on

where like if you've built it really

well then the FD should like choose to

use it and you should see demand from

the FD to use your sort of like

abstracted product versus just like

hacking a one-off solution themselves.

>> Yes. Um although I will just note this

is a very painful process for everyone

involved. Uh I probably can't use the

word pain often enough uh in the FDE.

You know there are many times where I

built something I thought it was amazing

and I thought it was beautiful. Not not

there yet, right? But it would it really

would help the FTEES as soon if they

just had the the ability to see it. And

I'd be like, "Please use my product."

They'd be like, "No, it's just this is

way more work. It's like not helpful."

And I will say, uh, let's be honest,

most of the time I was probably wrong

and I was building the wrong product for

them. And, you know, I should see that.

But sometimes also I was on the right

track, but you know, I I hadn't done

enough to make it easy for the FTEEs to

use. And so, you know, I would send, you

know, the developers out into the field

to deploy th those early solutions and

get them over the line even to the point

where the FDES could use them

profitably.

>> Are the FTEs always right in that case

or is like should the founders sometimes

be just top down and say like actually I

just want you to do that do it this way.

I

>> I mean the the answer is like yes to all

all of these things. The other thing

that comes up over and over again is

just how much the right answer here is a

matter of judgment. Um, and I think I

think going back to this question about

product vision, right? Like what is the

right product that generalizes from, you

know, this customer to the next three to

the next 10, you you very literally do

not have the the information needed to

answer that when you see that first

customer. And so it's just it it becomes

a judgment call. So in the context of

how all these FTE companies price very

differently based on outcome,

how does that fit in with now the

culture doing demos? Because there's

there's this thing in at least in SAS or

I used to get this push back from my

engineers demo driven product

development. It would be sort of looked

down upon but in this case it's

different for FDES, right?

>> One of the interesting things that

happens there is because you have to go

repeatably show this to new customers,

you're forced to give these new demos.

But but actually I think demo driven

development works really well if you

have the right kind of product. So you

know in the early days of Palunteer we

actually had one demo. It was a flow

where you're you know stopping a

terrorist plot and we started this with

you know just one of our features and

every time we integrated a new feature.

We had to think to ourselves how do I

show that this new feature is actually

helpful for the analyst who's going

through this demo who's stopping this

plot. You know when we integrated a

histogram we had to say well how do we

actually use this how does that work

with the existing features that we

already had and we went this you know we

integrated a map and we had the same

question and if you think about the

world from what am I building then you

know you're thinking about your

capabilities you might think of each of

these features individually and how to

build the best best version of these

features but when you're building a demo

you're thinking about it from the

customer's perspective and a really good

demo is something where you show it to

the customer and you are creating desire

in that customer for what you're doing.

They have to see what you're doing and

just want to reach out and grab it and

bring it into their life. And if you see

that, then you know that you've

identified a real pain for the customer.

And by doing that, that also forces you

to develop a better product because not

only are you thinking, okay, do each of

these features make sense in isolation,

but how do they work together? Um, if

I'm going to be showing this demo over

and over again, even just simple things

like moving from one feature to another,

that part of the path has to be very

straightforward. And those are those are

all the kinds of product pain points

that you would often see, but only later

after you've actually deployed to the

customer. So, what the demo does is it

is it changes the locus of what you're

thinking about from thinking about what

can I build to what is it that the

customer wants and am I am I solving

that painoint for the customer. So it

sounds like it's sort of this uh you

have to keep doing the gradient ascent

in this very very highly dimensional

multi-dimensional space and you keep

changing the variables.

>> Yeah. Yeah. I I think yeah maybe maybe

that's a really key point here is that

the kind of company you have to build is

a learning company and I think everybody

wants to build a learning company but if

you're a company like Google or Meta

it's very easy not to learn because what

you're doing right now was working and

if you just keep doing it the market is

growing you know everybody wants to do

what you're doing you can you can just

sort of keep coasting on the same

strategy and it's paying off for you my

advice to people if they're thinking

about where to join a company is I tell

them to join a young company. Not

necessarily a small company,

>> right? But a young company because a

young company is still figuring things

out. It's still learning. It hasn't

succeeded yet. You know, if you're just

out of college, you want a young company

that is uh growing really fast and then

you'll be you'll see what success looks

like that positions you exactly to be a

founder of your own company later. This

is why Palenter has has birthe so many

other startups is because even as a very

large company it is still a company

where everybody all the time is learning

focused on learning and you know always

doing that same grinding motion that it

is to be a new startup because you know

yes you know new startups a lot of pain

there too right that is like probably

like the canonical part of the YC

experience is that uh it's it's not

coasting it's working really really hard

on something that you're not quite sure

if it's going to succeed obviously mean

a monster successful palunteer. They're

now a super big company, huge

organization. We heard that you're

joining another large organization, the

US Army Reserve. Maybe you could tell us

a bit about that and are there any

lessons from the Palunteer experience

you're planning to apply there?

>> Yeah, absolutely. I've recently joined

uh the US Army Reserve as part of

Detachment 2011. And so, you know, one

one thing just to get out of the way is

to say that what everything I'm talking

about here, these are my opinions. These

are not the opinions of the US Army, the

Defense Department, the US government,

but I think it's this it's been this

absolutely intense experience and it's a

really interesting story. So, we are

part of a unit that's advising the army

on technology and we are not just

civilian advisers. We are actual

officers.

>> So, you know, we took the oath. I'm a

lieutenant colonel in the US Army.

>> I heard you went through basic training,

too.

>> I I uh Yeah, we we went through the

direct commissioning course. We've been

trained by military academics uh often

at 5 in the morning because that's the

time that works for people on the east

coast and doesn't conflict with our day

jobs. We learn from officers. Uh I had

to take the army fitness test uh which

since I am not very fit uh you know was

something that I had to train for for 9

months. But it really matters because

we're not just giving advice on the

side. We have skin in the game. We are

actually part of the organization that

we're advising and the army itself the

leadership is very different from what

it felt like in the early days of

Palinger when we worked with them back

in 2005 or 2010. General uh Randy George

the chief of staff of the army secretary

of the army Driscoll um they have

articulated a plan for the

transformation of the army. They know

that the army needs to change from, you

know, the kind of from fighting the

kinds of wars we fought in Iraq and

Afghanistan to fighting the kind of wars

that are being fought today in Ukraine

or what it would look like if we face

large scale combat operations in the

Pacific. They know the army needs to

move faster. They know the army needs to

change. And we're a part of that

strategy that they're executing. As

they've brought us in, they, you know,

they have given us, they've outlined the

priorities for the army. They've given

us each an area in which we're supposed

to operate, but they've also given us

the freedom to, you know, go around,

look for problems, work directly with

the officers on the ground to solve

those problems, or if need be to

escalate that to leadership and get that

fixed. And so I think one of the things

that's that's really interesting about

it is, you know, in many ways it does

feel a lot like running the FDA

strategy, you know, on the army. We we

get to see, you know, what is the what

are the CEOs, what are the leadership's

top five priorities? Can we make

progress against those? But also in a

world where you see that there's a

disconnect between what the leadership

wants and 20 years of how things have

been implemented and it takes a long

time to change that. And so, you know,

we're helping them make that change. I'm

really eager to have the opportunity to

make a difference.

>> There's a question that we love to ask

people on on this podcast, which is what

do you think are the best opportunities

for startup founders to work on right

now? Well, you know, I think this really

goes back to exactly this question of

why is it that AI agents are pursuing

the FD strategy? And you know, if you if

you zoom out and I put on my AI research

hat uh for once in this podcast,

I think what we've seen is that that

capability improvements are actually

extremely fast. Um if you you know yes I

heard people you know after GBD5 people

feel like things are plateauing but

actually if you look at this time period

between April 2024 when the best model

you know the release of GBD40 and April

2025 and the release of 03 that's an

extremely fast rate of progress and I I

think that's just going to continue. I

think we're going to see capabilities

continue to move quickly. But what's

what's really shocking actually is that

the adoption is not anywhere near what

you would expect from the speed of these

capabilities. What the world is going to

look like over the next 5 years is that

the capabilities just race ahead and

race ahead and race ahead and somehow

the world feels increasingly benal. You

know, you're like you're in your Whimo

and you you aren't thinking, oh my god,

it's not, you know, no one's driving

this. You're like, h traffic, it's

really slow.

>> Yeah. And so, you know, just like with

the world of the FDEEs where you have,

you know, the FTE is filling the gap

between this product and what the

customers need. I think, you know, the

this is a time where there's so much

availability to fill the gap between

what the capabilities can actually do

and what the customers are able to

adopt. And in the early days of AI, if

we we sat around a table in 2018 and

talked about what it looked like when

AGI was built, people thought, oh, well,

you know, it's it's going to it's going

to maybe maybe over the weekend it's

going to come alive and it's going to

take over the world. And, you know, one

of the things that I think people missed

in that was that, you know, AI needs to

be adopted. It's something that doesn't

just happen by itself, but you need

human ingenuity and exploration and well

dealing with a lot of pain in order to

make that happen. And so I think there's

just a huge amount of opportunity out

there looking at what are the

capabilities that are there, but what

does it take to make them really

genuinely useful to people?

>> There there's an analogy that occurs to

me. This might be a little bit forced,

but it's almost like OpenAI is the home

product team and the startups are the

FTEEs out figuring out how to get

adoption of of of the like research that

Open AI is cooking up back at the home

office.

>> I I think that's not a bad analogy at

all. I think that I think that is that

is maybe the underlying truth of what's

making this whole FTE strategy exciting

again.

>> Okay, that's all we have time for here

today. Bob, thanks so much for joining

us. That was really really interesting.

And we all learned a lot and we'll see

you all here next time.

[Music]

Key Vocabulary

Vocabulary	Meanings
deploy /dɪˈplɔɪ/ B2	verb - to send troops or resources to a place for a purpose
engineer /ˌɛndʒɪˈnɪr/ B1	noun - a person who designs, builds, or maintains engines, machines, or public works verb - to design or plan something skillfully
model /ˈmɒdl/ B1	noun - a representation of a system or process verb - to create a model or representation
product /ˈprɒdʌkt/ A2	noun - an item that is made or manufactured
customer /ˈkʌstəmər/ A2	noun - a person who buys goods or services
build /bɪld/ A2	verb - to construct or make something
solve /sɒlv/ B1	verb - to find an answer to or explanation for
strategy /ˈstrætədʒi/ B2	noun - a plan of action designed to achieve a long-term goal
outcome /ˈaʊtkʌm/ B1	noun - the result or effect of an action or event
develop /dɪˈvɛləp/ B1	verb - to grow or cause to grow and become more mature
valuable /ˈvæljʊəbl/ B1	adjective - worth a lot of money or having great importance
forward /ˈfɔːwərd/ B1	adjective - directed toward the future or a goal adverb - toward the front or future
execute /ˈɛksɪkjʊt/ B2	verb - to carry out or accomplish a task
platform /ˈplætfɔːm/ B2	noun - a system or technology on which other applications or services can be built
customize /ˈkʌstəmaɪz/ B2	verb - to modify something to suit a particular individual or task
generalize /ˈdʒɛnərəlaɪz/ B2	verb - to make a general statement or rule from particular instances
abstraction /æbˈstrækʃən/ C1	noun - the process of considering something independently of its associations
leverage /ˈlɛvərɪdʒ/ C1	noun - the use of something to maximum advantage
heterogeneity /ˌhɛtərədʒɪˈniːəti/ C2	noun - the quality or state of being diverse in character or content