The Sales Playbook For Founders | Startup School
Tom Blomfield, co-founder of Monzo and GoCardless, offers a comprehensive guide to B2B sales, emphasizing a streamlined process for achieving recurring revenue. He outlines essential steps, including pilots, contract strategies, and customer engagement, while highlighting common pitfalls and success metrics to effectively prove value and close deals.
Part of Y Combinator Collection
Startup Wisdom
Explore 500+ transcripts from Y Combinator's startup accelerator program, featuring insights from successful entrepreneurs and industry leaders.
Browse Full CollectionConvert your Audio Video Files to Text
Speaker Separated Transcription98% Accurate
Free for files under 30 minutes
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 really poorly defined and overly long unpaid design partnership, all the way through to the like the pro move, which is a rapid, well-defined, tightly run 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 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 speed run 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 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. Three months, six 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 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 observe their work, sit next to their keyboard and see what they're doing, for a few days. When doing so, I generally suggest founders try to identify narrow pieces of work that they can automate.
Maybe you ask a customer something like, 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 wedge 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. Founders often justify this as trying to reach feature parity 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 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. 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 doing sales for the first time. Founders cling to these long, poorly defined design partnerships that are 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 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, 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 of concept, which seems very low commitment. 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 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 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 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 yet 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 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. There are different techniques. You might offer back-testing on historical data or even side-by-side 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 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 smaller geography that they roll you out in before rolling out across larger geographies. Again, this is a chance to show that your product works in a lower risk environment, so your champion's 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 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 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, 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 the 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 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 North Star 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-up 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 MRR 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 spot on. 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'd 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 SOC 2 started as soon as possible, as well as any other security certifications.
It might be HIPAA, ISO 27001. 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 Vanta 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 organisation. 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 touchpoint 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 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'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 six 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.