Forty percent (nearly half!) of the companies I spoke with went through at least one failed idea before discovering something that worked. Some went through 10. As Christina Cacioppo eloquently put it, “Our first couple of ideas were just total crap.” Many shared the same sentiment. Here’s how some of today’s biggest B2B startups began:
Retool started as Venmo for the U.K.
Amplitude started as a voice recognition application that allowed you to send and receive text messages by talking to your phone
Segment started as a university classroom lecture tool
Vanta started as B2B Alexa
Notion started as a no-code website builder
Loom started as a marketplace for companies to hire subject-matter experts
Slack started as a game called Glitch
Box started off as a “box” to put photos and content in on Facebook
The question we’ll be tackling in today’s post is this: Once you have your startup idea, how do you know if it’s a big idea or . . . total crap? Below, I’ll share:
How the best founders validated their idea
What specifically convinced them to go all-in
How many people they spoke to before committing to the idea
What true pull looks like
Which companies pivoted and which had the right idea from the start
Some of my biggest takeaways and surprises from this phase:
Founders spoke to a median of 30 potential customers before feeling like their idea was solid.
Outbound sales is consistently the best signal for validating your idea (versus friends using your product, incubator batch-mates, or investor leads).
Only about a third worked with design partners.
There are four ways to validate your startup idea—and it’s fairly clear which path you should take depending on your product and your experience in the problem space.
There are four signs your idea has legs:
People pay you money: Several people start to pay for your product, ideally people you don’t have a direct connection to
Continued usage: People continue to use your prototype product, even if it’s hacky
Strong emotion: You’re hearing hatred for the incumbents (i.e. pain) or a deep and strong emotional reaction to your idea (i.e. pull)
Cold inbound interest: You’re seeing cold inbound interest in your product
Every prosumer collaboration product, including Figma, Notion, Coda, Airtable, Miro, and Slack, spent three to four years wandering in the dark until they stumbled on something that clicked. I’ll share these stories below.
As I mentioned, about 40% of startups pivoted at least once before landing on their winning idea—oftentimes more than once. This rate is a lot higher than in B2C, where it’s closer to 20%.
Four strategies for validating your B2B startup idea
Across two dozen interviews, I noticed four distinct paths to effectively validating a startup idea:
The do-it-manually path: Don’t build anything—solve the problem manually first, for a small number of companies
The listening path: First talk to tons of potential users, and then start building
The prototype path: Start building a prototype and then co-create it with a small number of design partners
Just launch and see how it goes
If you look closely, all four paths are just different ways to validate the same things we focused on in part 1—pull and pain—with varying degrees of up-front investment. Here’s what pain and pull look like in practice:
People pay you money: Several people start to (or offer to) pay for your early product, ideally people you don’t have a direct connection to.
Strong emotion: You’re hearing hatred for the incumbents (i.e. pain) or a deep and strong emotional reaction to your idea (i.e. pull).
Cold inbound interest: You’re seeing cold inbound interest in your product.
Continued usage: If you’ve got a prototype running, people continue to use your product even if it’s bad.
1. The do-it-manually path: Solve the problem manually for a small number of companies
This path is a great choice for founders who are unclear whether the problem they are going after is important, or even solvable. Though it was the least common path, when done right, it can unlock huge lessons with very low up-front investment.
In the case of Vanta,Christina Cacioppo sensed there was a big opportunity in the compliance/security space but wasn’t confident the pain was that bad. So she manually created compliance reports for a few companies and noticed (surprisingly) that they all found them very valuable:
“There was about a six-month process before we started coding where we talked to about two dozen companies.Initially I simply answered security questionnaires for a company myself. They sent me their old questionnaires and they would send me new ones, and I would manually do the copy and paste.
At the time, no one really got SOC 2 certifications, and we didn’t know anything about them. I went and read two dozen SOC 2s and then went to a company and did a readiness assessment for them. We made them a SOC 2 report card in a spreadsheet, interviewed all their people, and wrote out, ‘Here’s all the stuff you have to do for a SOC 2.’ And the test there, honestly, was: one, would they spend time with us, and two, would they believe us? Would they think the spreadsheet was useful?
We did this first with Segment, and they really liked it. We were like, ‘Wait, really? Are you serious?’ Then we went and took our spreadsheet to Front, and we basically gave it to Front. We did a find-and-replace in the doc from ‘Segment’ to ‘Front.’ And that was a test of whether that’s useful to Front. Can we standardize this? And that actually was useful to Front.
And then we got an email from an old Dropbox colleague who was like, ‘I hear you guys have become SOC 2 consultants. That’s super-weird. I thought you were going to do other things with your life. But also, can you come do this for my company?’ And that’s when it was like, no, but I’ll start writing code. That was the validation process for us.”
The founders of Ramp did the same thing with savings reports:
“We came at it with this theory of: We’re experts in savings, and we’re really interested in this idea of a credit card that would save your business money. We think we can save you money, but we want to prove it to you.
So we did these things we called ‘Savings reports,’ where we would ask founders for the last 90 days of their credit card purchases or ACHs and—manually, but they didn’t know it was manual—come back to them with ideas to save their business money.
One of the early aha moments there was a company that was legitimately spending money on seven different project management tools. They were growing so fast that they had forgotten to cancel the subscriptions. They had adopted Basecamp and Trello and Asana and Smartsheet, and all these things that they later abandoned. I think it was a hundred grand on software they weren’t using. We came back and were like, ‘There’s $200,000 in savings. You don’t have to use us, just go and enjoy this tip. But by the way, this is what our software does, and we can do this for you ongoing and automatically.’”
2. The listening path: First talk to tons of potential users and then start building
This path should be your default, unless you have a clear sense of what you need to build. Go this route with the goal of speaking with around 30 potential customers, looking for pain and pull (see above what that means).
The founders of Zip spoke with 75 potential users before committing to their idea:
“We did a lot of interviews with CFOs, heads of procurement, heads of finance (I think the exact number is around 75), and over the span of two to three weeks. It really helped refine that idea. We had like 110 pages of notes or something in those two or three-ish weeks. Turns out the response rate is pretty good on LinkedIn when you just want advice.
We would be like, ‘All right, we had these three ideas. These two suck, but maybe we should tweak this idea because of what these two or three people said.’ And so we’d keep honing it down, honing it down, honing it down, iterating every day.
We also had a very stringent list of, I think, 16 criteria for the idea we were going to work on. And this idea actually met all of them.
Zip’s actual 16-point checklist
But we were very honest with ourselves. We worked on a bunch of terrible ideas before, and if there’s anything we had learned, it’s that today will be the easiest day to kill the idea and do something better. It’ll always be harder tomorrow because you’ll have more customers if you’re fortunate (or unfortunate). You’ll be more emotionally attached to it; you’ll have more sunk cost.”
The founders of Stytch spoke with about 30 people and noticed there was universal hatred (i.e. pain) for the existing solution. Then they started building, and launched quickly, per the advice of their lead investor:
“We talked to about 30 people over the course of a few months, mostly fintech developers, but also friends that weren’t in the fintech space that know how to build authentication. We asked them what they used for authentication and what they thought of it. For most of them, it was either Auth0, Google Firebase, AWS Cognito, or in-house. And pretty universally, everyone hated whatever they were using. It turned into a snowball of momentum, where at a certain point it just seemed inevitable that we were going to do this.
We specifically didn’t go the design partner route, and instead focused on getting a self-serve product out as soon as possible, specifically an email magic links product.
Chetan (our lead investor at Benchmark) gave us advice that selling authentication to large companies would take a long time, since they’d need a lot of features. The advice we had gotten was if they really want just this one product, that’s great. Let them be a design partner and partner with you. More likely, they’re probably going to keep asking for things that aren’t in your ability to serve them right now. So see what you can do to serve that broader long tail of the internet with your wedge and see if you can get that going. If really we had built for only one of those, we probably would’ve waited another year to launch.”
The founders of Gusto had an extremely similar experience, both in terms of finding real hatred for the existing solution and also talking to exactly 30 potential customers:
“I had 30 people I talked to about the original idea. This is before we wrote a single line of code and before we actually committed to the payroll idea. We had a list of 30 people that Josh [Reeves, co-founder] and Eddie [Kim, co-founder] and I knew one way or another—some from Stanford, some from other networks—and I asked them for the names of friends who had small businesses. And for every call we did, we asked them, ‘Who are your friends who have small businesses?’ I literally was calling people out of Yelp.
Over time, if you look at the first call transcript and compare that to the 30th call transcript, it’s a very different call. In the beginning, you’re very open, exploratory, lots of different ideas and options. In the end, it was really mostly validating what you’re seeing.
The thing I was looking for in retrospect is emotional reaction. When you talk with a customer and you’re like, ‘Hey, here’s a new type of mint. The reason why it’s different is because it’s organic and it’s local,’ and then the person says, ‘Oh yeah, that’s cool.’ You say, ‘Would you buy it?’ They’re like, ‘Yeah, yeah, I may buy it.’ That’s not the feedback you’re after. That basically means that, no, they’re not going to buy it. They’re just being nice.
What you’re looking for is really, really deep emotion. So, what I heard from people was extreme frustration with their current payroll providers. The moment you just asked them the simple question of ‘What do you feel about your current payroll provider, your payroll system?’ they started cursing, literally. More than half of people just started cursing and being really upset. When you hear that strong emotion, then you know you have something.”
Guy Podjarny, the co-founder of Snyk,spent time talking to dozens of potential users before building anything, not so much to validate the problem (it was obvious) but to make sure that if he built the solution, companies would embrace it:
“The value in getting security built into the development process was already well recognized, so I didn’t need to validate the idea. What I needed to firm up was whether if I built the solution, developers would actually embrace it. Therefore, my early conversations were not with security people but rather with developers and entrepreneurs, especially founders of companies in the DevOps space.
I had several dozen such conversations in the opening days, and focused not on finding potential customers but rather on deeply understanding what it means to build a dev tooling company, and how it differs from a cybersecurity one.
DevOps founders were quite supportive of the idea, and agreed with both the need and the opportunity. They’ve all seen or run companies that disrupted incumbents by embracing a DevOps approach. The few security people I spoke to were skeptical, agreeing it’d be valuable but not believing it possible. This firmed up my conviction that this was the right problem to tackle. I thought, ‘It’s hard, but if I pull it off, it’ll be big.’”
The founders of Ramp spoke to more than 100 potential users before jumping in and building anything (even before building their manual solution):
“Before we shipped a single card, we talked to over 100 finance and founder teams. We’d reach out to old YC batch-mates, or old friends who left companies and went to other companies; also the founders in the New York tech ecosystem.”
You may think you’ve talked to enough people, but don’t stop until you’re seeing evidence of real pull (e.g. money, usage, strong emotion, cold inbound). Spenser Skates, the founder of Amplitude, stopped at 30 conversations and later realized he should have talked to more:
“We did not talk to nearly enough. We talked to 30 different companies within a month. I should have aimed higher, like 50 companies in a month. But we talked to 30 in a month before building anything at all just to see, ‘Hey, is this something potentially interesting?’
And out of that group, there were probably 10 folks that we identified that could potentially use this, and then five that had so much of a need they might pay money. Out of that group of 30, how many ended up being paid customers? A grand total of zero. We knew there was a need, but we made the mistake after that month of going straight to building, because we were like, ‘Well, instead of having all these speculative conversations, we actually want to have something to show people.’
Some of them used it, but were they interested in paying money? Hell, no. I think in retrospect, I should have continued dedicating half of my time to going out and talking to customers. But that’s in retrospect. In the end, though, it worked out.”
