– English Lyrics

Lyrics & Translation

[English]

[Music]

At YC, we work with a ton of founders

who are navigating the B2B sales process

for the very first time. And I often

notice some very common and easily

avoidable mistakes that I want to talk

about today. So, I'm going to describe

the typical progression that a B2B

founder goes through. normally starting

with something like a a really poorly

defined and overly long unpaid design

partnership uh all the way through to

the like the pro move which is a rapid

well-defined tightlyun sales process

that results in contractually recurring

revenue straight off the bat. In other

words, I'm going to talk about how to

close your first B2B contracts. So in

general, the goal for most early stage

companies is to progress through this

sequence as rapidly as possible so that

you're able to close new ARR every week

and grow your company. And really 90% of

the time, the vast vast majority of the

time, founders get stuck in the very

early stages. It's the the very long

unpaid design partnerships. And my job

is encouraging them to advance to the

next level as quickly as possible.

Occasionally though, really only 5% or

10% of the time, founders will try and

speedrun the entire process and leap

right to the end before their product is

mature enough or without enough social

proof, i.e. other happy customers who

will vouch for you. That's pretty rare

though. Honestly, most founders are too

slow to progress through these stages.

So, let's try to lay out the different

stages and talk through them. The first

is the design partnership we've talked

about. Maybe you're very early in your

company journey. Perhaps you've got some

Figma mock-ups or really just an idea,

barely any code written at all. Or

perhaps you're selling into an industry

like law or accounting where there's a

ton of domain knowledge and maybe you

don't have that knowledge yet. And so

founders at this stage will often pitch

uh what's sometimes called a design

partnership. They'll spend a bunch of

time with a customer, often a customer

with a big fancy logo in their office

observing how they work and kind of

co-designing this product alongside the

customer to meet their needs. It sounds

really good in theory. The issue is that

these design partnerships are often way

too long, 3 months, 6 months, and

they're poorly defined in scope and

suffer from really low engagement from

the customer as a result. Since the

customer isn't paying for your time and

frankly, they've got their own business

to run, they just don't spend that much

time with you co-designing the product.

The entire engagement is all kind of, I

don't know, like vague and meandering.

You've got this fancy logo on your

website as a design partner, which feels

like progress to you and you're pretty

proud of it. And so, you don't want to

remove it from your website, but really,

you're not getting any closer to real

revenue with this customer. It is

extremely valuable to be able to sit

next to a customer in their office and

and observe their work, you know, sit

next to their keyboard and see what

they're doing uh for a few days. When

doing so, I generally suggest founders

try to identify like narrow pieces of

work that they can automate. Maybe you

ask a customer something like, uh,

what's the part of your job you hate the

most? Or if you could wave a magic wand,

what part of your work would you get rid

of? You can even offer to do the work

yourself manually for the customer so

that you really understand what's

involved. We've seen some of the best

founders even go undercover and get

qualified to work as an auditor or a

real estate agent or an accountant and

actually go and do the work like get a

job for a couple of months so they

deeply understand the problem in the

domain space. Really, the goal of all of

this is to identify a really narrow

burning problem, and you'd be able to go

away and build a narrow wedge product in

as little as 48 hours and bring it back

to the customer and ask them to try it,

see if it solves their problem. And I'd

keep iterating over different like

problem and solution sets until you find

an initial wedge product that they

absolutely love. So, if they are happy

to pay you and use your wed product, I

then actually wouldn't build more stuff.

I try and take that wedge product and

try and sell it to another 10 similar

customers. What many founders do which

is a mistake is to try and overbuild a

really broad platform which is a mistake

at this stage of your company because

you just don't have the resources. You

can waste a lot of time without any real

signal that the customer wants what

you're building. And founders often

justify this as like trying to reach

feature par with the existing software

which because you're such a small

startup is very very difficult. instead

I just focus on doing one part of that

um of that solution really really well

like really focusing on a narrow wedge.

The problem with building something very

broad is that rather than telling you

look this sucks I wouldn't use it the

design partner instead tries to be

helpful and maybe they imagine just one

more feature that they might want that

might make it valuable and really they

just don't want to hurt your feelings by

saying no this sucks. I've also seen

customers treat founders in a design

partnership as like an unpaid dev shop.

The customer gives the founders an

extremely detailed list of software

requirements that's only really relevant

to their business and the list keeps

growing. The founders understandably

want to make their first customer

really, really happy, but they're too

meek to ask for money. So, they do all

this bespoke work for free and it ends

up kind of seeming like an abusive

relationship. I'm not saying that all

design partnerships are a waste of time,

just most of them. Generally speaking,

more and more features are not the

answer. Instead, try to pick an initial

wedge product and sell it aggressively

for a couple of weeks. And if it doesn't

work, pick a different wedge. So, bad

design partnerships is the most common

problem I see with B2B startups coming

into YC and and doing sales for the

first time. Founders cling to these

long, poorly defined design

partnerships. they're just going

nowhere. They get stuck in low bandwidth

communication with a disengaged partner

and can't figure out how to move

forwards. So once founders figure out

that design partnerships can be a waste

of time, then they move on to free

trials, pilots, or proof of concepts.

These are really all the same kind of

thing, honestly. Maybe you have an

initial product built or at least an a

narrow wedge product that people can

use, but maybe you don't have the social

proof from other customers that this

thing really works yet. And so

naturally, uh, your early customers want

to try the thing out before they make a

financial commitment. These are normally

called pilots or proof of concepts. One

founder recently told me that a

customer, I think they were in France,

even asked them for a pre-proof concept,

which seems very low commitment. I I

really don't know what that is at all.

The most common problem for these free

trials is again they're too long, maybe

two or three months, and they suffer

from the same low commitment problems as

a design partnership. There's no target

or end goal, and the customer isn't

really committed uh to engaging with the

product or the design process. So, if

you're doing a proof of concept, you

need to understand what are you trying

to prove? What are the agreed success

metrics you're aiming for? If you've

seen my B2B pricing video, I talk about

defining the value equation with the

customer. So, for example, that's uh

what percentage saving or revenue uplift

are you going to deliver that makes your

product a good return on investment? For

example, if you're selling a customer

service AI, you might claim your product

might solve 20% of inbound customer

queries. The customer will be able to

reduce their customer service team from

a 100 people to 80 people, saving

perhaps a million dollars in salaries

every year. That's the value you claim

to be delivering. And in return, you

might charge $200,000 for that software.

And so, a well-designed pilot or proof

of concept is an ideal way to prove that

value. Maybe the customer doesn't really

believe you can actually solve 20% of

their queries. So you say give us a

sample of a thousand queries and let's

measure how many we can actually solve

for you. Is it really 20%, or is it 15

or is it 25% even? Once you've done

that, your internal champion can now

take the value equation that you've

defined with them and this proof that

you can actually deliver that value to

their CFO or the CEO and explain why

it's um a really good investment for

their firm. If they pay you $200,000,

they're going to get a million dollars

of benefit. It's a win-win. So, pilots

can be a way to convince cautious buyers

and overcome objections. Uh there are

different techniques. You might offer

back testing on historical data or even

sidebyside uh trials with their existing

process. So, for example, your customer

service product will be producing

answers alongside human agents and you

can compare the answers at the end. the

answers that your agent's providing

isn't really going to go to the

customers, but they're compared side by

side for a realistic um evaluation. Or

you might offer to take on just 1% of

their total customer service volume,

which is low risk. Or you could pick a a

smaller geography that they roll you out

in before rolling you out across larger

geographies. Again, this is a chance to

show that your product works in a lower

risk environment, so your champion is

not going to get fired if it all goes

wrong. But the problem with these free

pilots often is they still risk

suffering from low engagement from the

customers and founders are often very

afraid to have a willingness to pay

conversation. They feel like if they

bring a dollar amount up, it might scare

the customer off. But honestly, that's

almost always not true. It's so so

important to have the the conversation

with the customer. If I can solve this

problem for you and deliver these

metrics we've talked about, how much

would that be worth to you? you really

need to disqualify customers who just

aren't ready, able, or willing to buy

your product. So, after the free trial,

founders normally move to paid trials.

We've talked about design partnerships

and and free trials that go on forever.

When founders really get into the groove

and start ramping up their sales, they

figure out they need to make these

pilots much shorter and get a paid

commitment upfront. Getting a financial

commitment from the customer is going to

make them take your pilot much, much

more seriously. They're now paying for

your time and hopefully won't want to

waste their money. As well as the cost

of the pilot, I'd also ask upfront about

their willingness to pay for the full

product. You know, what's the annual fee

going to be and the price point. It's

better to know early if they just aren't

going to pay you any money whatsoever to

solve this problem. If it helps you

avoid going through a full procurement

process or having to talk to finance or

the CFO, you can ask your champion for

the amount that they can personally

approve. Maybe it's a $10,000 or $20,000

charge on their corporate credit card.

I'd often take less money if it allows

you to shortcut a long long approval

process. You might also ask for other

kind of commitments from the customer to

ensure that the pilot is successful

beyond simply a financial commitment.

Say you're doing work for an auditor or

an accountant. Perhaps you should wait

until there's a live project kicking off

that's suitable for you to test your

product on. So you say, "Let's not start

this month. Let's wait until the first

of next month because I know you've got

this important new project with a new

client. That would be a perfect test

case for our software." You might insist

there's client data ready to go or a

person or even a whole team that's

dedicated on the client side to testing

your product. I'd strongly advise you

also schedule check-ins every couple of

days with these people. So, if they find

any bugs or niggles with your software,

you can fix it overnight and bring it

back to them, which will really impress

an enterprise customer. All of that

might mean you delay the pilot starting

by a few weeks until there's a suitable

project. But then from the start date,

you can insist on a really high

engagement from the customer. I'd also

keep the time frame as short as

possible. really just long enough that

they can use your software and

experience the full benefit. Maybe

that's seven or 14 days if you've got

the product dialed in uh really well.

And remember, because your product is so

early, you're never really selling a

complete bug-free experience. You're

actually selling the founders and the

early team. You're selling the promise

that you personally are going to solve

this problem for them. You're promising

that if anything goes wrong, they have

your personal cell phone number and

you're going to respond 24/7 to get the

problem fixed. I'd track the time to

first value like a northstar metric,

reducing it from weeks to hours, is

often the biggest single lever for

higher pilot to paid conversion. What

this actually means is doing janky stuff

to get your product live as soon as

possible. For example, I would never do

a full API integration during a pilot if

it requires any engineering time from

the customer whatsoever because that's

just going to delay you by months. If

you can work from Excel imports and

exports, for example, that can work or

ask the customer to email you the data

you need and then email back the

completed work. So, you're really trying

to get to the point where they can

experience the value of your product as

quickly as possible. I'd also insist you

book a post-pilot meeting before the

pilot even starts. That's a meeting

where you can go through the metrics at

the end of the pilot and show hard ROI

numbers. It should be really crystal

clear to the customer at the end of this

process whether they want to keep using

your software. Now, this is all pretty

good, but the downside of a paid pilot

is you still need to go and negotiate

the full contract afterwards. It's like

a whole second sales process just when

you thought you had a customer who was

ready to buy. And this can be very, very

frustrating. So to get around this,

really sophisticated founders move on

from paid pilots to recurring revenue

contracts with an opt- out period. So

this is typically a monthly or annually

recurring contract with a 30 or 60-day

money back guarantee or opt- out period

at the very start. But by default, if

the customer does nothing and is happy

with your product, it's going to turn

into a full recurring contract after

that opt- out period with no additional

sales process needed. That's the pro

move. It's like magic. It's one sales

process that turns into a recurring

revenue contract. And it can be very

persuasive to be in a sales meeting and

confidently say, "Well, this is how

customers buy our product. Typically, we

offer annual contracts with a 30-day

grace period or an opt- out and customer

X, Y, and Z all signed on these terms."

It can be hard as a an early stage

founder to leap straight to this step

when you're just starting out. Maybe

your sales process isn't good enough.

Maybe you don't have the social proof or

maybe simply your product isn't ready

yet. So starting with an earlier step,

perhaps a free pilot for the first one

or two customers and then moving onwards

can be an option. Of course, you can't

run before you can walk. But don't be

stuck crawling on all fours for too long

either. And for me, that's the overly

long design partnership with no

financial commitment. As a side note

here, be careful what you report to

investors as MR or ARR, especially if

customers are still in that opt- out

period. Just be super clear with

investors when you're reporting these

numbers where the customers sit. I think

the tactic is still absolutely spoton.

This is just a communication point with

investors. So, when you've got early

sales really dialed in, you might be

closing one of these recurring revenue

contracts every week or two. After

you've signed these contracts, that

takes us to the next thing you should

focus on, which is customer success. So,

after you've signed these contracts, you

may often need to dedicate as much or

even more effort to actually onboarding

the customer and making sure they're

getting value out of your product. I

spoke to a company just this week that

had signed $4 million worth of

contracts, but they implemented less

than $2 million of those contracts.

They're simply missing a customer

success function. Finally, I want to

finish up with some tips that I've

learned from YC companies over the last

years. First, get Sock 2 started as soon

as possible, as well as any other

security certifications. It might be

HIPPA, ISO 27,01.

These security certifications can delay

you by months. And so, I'd get it

started today. There are plenty of YC

companies that can help you with this,

from Vant to to newer companies. I'd

figure out who your internal champion is

and treat them almost like a co-founder

inside the company. It's someone who

sells for you when you're not in the

room and fights budget battles on your

behalf. With this person, I'd try and

set and then work towards a defined

closing date. They're going to miss it

almost every time, but it can still help

create urgency within the customer. Ask

this person to tell you about their

sales process upfront. You might say,

"Describe the last time you bought

software like this. Who internally had

to prove it? What was the process?" You

can map the organization. You might have

the economic buyer, the technical

approver, the security gatekeeper, the

legal team, the day-to-day users, and

then devise a plan to win over each

stakeholder explicitly. Once you

understand that buying process, try to

drive it forward yourself. Don't leave a

meeting without the next touch point set

up. The next tip to move a contract

along is to get on a plane and

physically visit your customer in

person. It can work wonders. You might

email your your champion and say

something like, "Hey, I'm going to be in

Houston next week. What do you say about

getting lunch?" And if they say yes, you

book your flight to Houston. Don't get

caught up in multiple rounds of

reviewing contracts or NDAs. Customer

legal teams love to do this back and

forth. Their entire job is redlining

contracts, but it's going to slow you

down incredibly, and it doesn't really

prevent much risk. So, I'd be pretty

flexible on signing, frankly, whatever

your early customers want as long as

it's not going to expose you to like

unlimited liability or container clause

that's going to transfer all the IP in

your product to your customer or

something company ending like that. So,

I' I'd really ask yourself, is this

clause like company ending or just a

slight annoyance? And frankly, put up

with anything that that's not going to

be company ending. Using scarcity can

also work. You might say something like,

"We're talking with seven or eight

potential customers, but we really only

have the capacity to work with two

enterprise customers this quarter. So,

if you're interested, we'd love to get a

commitment. Otherwise, let's talk again

in 6 months." So, this has been a pretty

exhaustive list. Hopefully, it helps you

to up your B2B sales game. But if you've

discovered other tips that work for you,

please do let us know in the comments

below. And as always, thanks for

watching.

Key Vocabulary

Vocabulary	Meanings
founder /ˈfaʊndər/ B1	noun - a person who starts a company or organization
partnership /ˈpɑːrtnərʃɪp/ B1	noun - a relationship between people or groups that work together
process /ˈprɑːses/ A2	noun - a series of actions or steps taken to achieve something
customer /ˈkʌstəmər/ A1	noun - a person who buys goods or services
product /ˈprɑːdʌkt/ A2	noun - a thing that is made or grown to be sold
pilot /ˈpaɪlət/ B2	noun - a test run of a product or program verb - to test or try out something
revenue /ˈrevənu/ B1	noun - income from business activities
contract /ˈkɑːntrækt/ B1	noun - a written agreement between two or more parties
commitment /kəˈmɪtmənt/ B2	noun - the act of showing dedication or obligation
value /ˈvælju/ A2	noun - the quality of being useful or important verb - to consider something to be important
trial /ˈtraɪəl/ B1	noun - a test of the performance of something
proof /pruːf/ B1	noun - evidence or argument establishing a fact
sell /sel/ A1	verb - to give something to someone in return for money
build /bɪld/ A1	verb - to construct something by putting parts together
close /kloʊz/ A1	verb - to shut or finish a deal
navigate /ˈnævɪgeɪt/ B2	verb - to find your way through a process
advance /ədˈvæns/ B1	verb - to move forward
focus /ˈfoʊkəs/ A2	verb - to concentrate on something noun - the center of interest or activity
prove /pruːv/ A2	verb - to show that something is true