Hey there, everybody. I'm here as I said with Mike Bernal from a tiny little VC firm kind of unheard of. It's called Sequoia. I don't know if you guys know. Um, and as I said, Mike is partner at Sequoia he actually graduated from Harvard, he was VP of engineering a product at Facebook for like eight years spent Sequoia for five has a bunch of amazing portfolio companies, we're very lucky to be joined by him today. I want to friendly remind you that audience q&a is open, and I'm sure you guys are gonna have a lot of questions for Mike, go ahead, start putting them in now put them in as you as you think of them. And we're gonna get to as many of them as possible after Mike is done presenting. And with that, Mike, I'm just going to hand hand things over to you take it away.
Thank you so much. I'm really thrilled to be here today. So thank you for having me. At Sequoia we partner with companies all around the world, at every stage from seed to venture to growth to post IPO. But our favorite stage by far is seed pre product market fit. And many of the greatest companies we've been lucky to and lucky enough to work with over time, whether that's stripe, or Airbnb, or iOS, or Apple or more. We're the sort of proverbial two founders in an idea. When we first met them, they were definitely pre product market fit. Now, the the journey to product market fit is often non deterministic, which is basically a fancy word for random. You can have plans and theories, but you don't really know what's going to happen until the rubber hits the road. And so that's why I'm excited to talk about one of the key things that we look for in early stage teams, I think one of the most important ingredients to finding product market fit, which is tempo. So what is tempo? To me, tempo is two things, its speed, and its consistency. It's not just about going faster, slow. It's about going faster, slow at a consistent pace. Why should you care? I think it's consistently one of the very top attributes of the best founders and the best companies we need. And I don't think we're alone. I actually think one of the very best compliments an angel considered bestow on a founding team and Angel can include an introduction is they're just really fast. Or she's a machine. What does that mean? It means it doesn't mean fast in the kind of uncontrolled reckless crashing rewald sense. It means fast in a sort of consistent maniacal get a little bit better each day kind of way. And it's actually one of the top things that we look for, at least when evaluating a team, how consistently faster they move. Let me give an example I was a couple years ago, I was reading a book about Google's use of okrs. It mentioned that they were on their 75th quarterly OKR or something like that. And actually, I love this I love the fact that you could actually trace the entire company's history through 75 distinct chapters 75 distinct okrs. I wondered what q2 okrs look like or q 10. I think sometime in like 2006, Google acquired YouTube. So I imagine there was a set of okrs at some point about just integrating YouTube. But now Google is it became it. I'm not sure formal okrs make any sense for a startup? Certainly not quarterly ones. But what I found so fascinating about this is that you could literally trace the entire story of Google through these 75 distinct chapters with clear goals each time and a clear feedback loop. That today, Google is so big, that it kind of seems like it has existed forever. But in reality, it's only about 90 quarters old. Now, that's Google's story. But what's your company's story? I tend to think any startups early life is really divided into two epochs, pre product market fit and post product market fit. And until you find product market fit, you really only have one OKR, which is to find product market fit. Now the problem is finding product market fit is not a deterministic process. Most of the time, it requires iteration. It requires constant adaptation. My mental model is that it's actually just a turn based game with an unknown number of steps, and sometimes either the clock or the money or both run out before you get to finish the game. It's kind of like a game of chess. So what is your optimal strategy? A common pattern I see is people spend a bunch of time at the very beginning of a company talking To a bunch of other people, they talk to advisors, they talk to investors, they talk to potential customers to hone their thesis. And this is great, you should definitely do this. But then they start building. And often, they will go off into a corner and end up building for 912, sometimes even longer 912 months before they go back and actually start testing your hypotheses. And it's easy to imagine why it takes a while to build a quality product, it takes time to build something valuable enough to sell. And people generally aren't going to adopt a super incomplete alpha. But it's also a super tough setup, because you don't get any feedback and that those nine to 12 months, and the market continues to evolve in the interim, your competitors continue to evolve. And if your company's story is a turn based game, spending a year on turn one is a bad strategy.
The challenge, though, is that this is the natural way to build most products, especially especially if you're coming from a larger company without resource scarcity. And if you're 100%, correct about what you need to build, if you're, you know, if your initial shot is exactly right, then this is actually probably the fastest strategy. But the problem, especially with a startup is twofold. One is you don't have infinite resources. And two, you probably aren't 100% correct about exactly what you have to build. So what is your optimal strategy? I think it's twofold. First, you need an explicit consistent tempo for the company, a cadence where you're going to come up for error, evaluate what you've built, and course correct. Second, you need to design an explicit feedback loop at every single stage. It's not enough to just have internal milestones where you're track whether you're 50% done with some feature, you need to build things in such a way that you can actually show them to customers, show those features to customers and get real feedback. This isn't new, per se. And you'll hear people talk about this in various firms. The entire idea, I think of consistent sprints in software development is sort of a manifestation of this. Or, you know, Reed Hoffman, I think famously had some advice around, you should be embarrassed about the first thing you ship. All of this is rooted in the same idea. And it all gets at the same thing, which is you need tempo. And you need feedback, not just at the software engineering level, but at the whole company level. Now, this is this sounds great in theory, but how do you actually do this in practice? I think a few tips. First, you'll sometimes hear investors talk about wedges. The idea is you want to find some small acute pain for a customer, build a simple, great solution for that pain and then expand from there. That's a great strategy, you should do that. Find the narrowest point deist wedge you can use to get started. Second, explicitly break bigger problems into smaller ones. And for each smaller problem, designed a feedback loop. Ideally, you can ship interim work to customers after every single stage and get their feedback. Even if it's a little bit awkward, like you want to the feedback loop will not come naturally you have to design it, you have to be explicit about it. If you can't do that, you can't ship the interim product to customers for some reason, at the very least, show it to them and get their feedback. be explicit and be greedy at every single step along the way about getting feedback. Now, that sounds great, but sometimes you realize you're in a hole. And this happens all the time. It happens with companies I work with all the time, you build a bunch of stuff, you refactor it something big. And suddenly you realize you've been out of market for six months, and it's gonna take another three to four months to finish it all off and sort of get it back into the hands of customers. This is a super tough spot. Because of the sunk cost fallacy. You're six months in, you see the end, you see light at the end of the tunnel, and nine times out of 10, you'd rather plow ahead, then reset. But it's also super dangerous, because you have no idea if that big rewrite is going to work. And this year, the deeper you dig, just the harder you make your problem. And so I think when you realize you're in this world, pause and try to figure out how to get back on a regular cadence, even if you're six months in pause and figure out okay, how can I ship something to customers this month or in the next few weeks. So I can validate that six months of work and sort of get back on the feedback cycle get back on the the cadence of feedback. Building in a corner without any feedback for nine months, I have found to be highly anti correlated with success. So what are some best practices here on the on the enterprise side, this is a little bit easier. You cast a net for a few development partners, folks who can work with you to deploy the product early and give you a steady stream of free, steady stream of feedback. They're often free or pay you nearly nothing. But trade is really that they're going to take alphabets and give you feedback instead of paying. The how dissatisfied would you be if this thing went away tests from superhuman, I think, is one really good metric for measuring if you're heading in the right direction here. One example of this is a company called Viva, which is a $50 billion company in the life sciences space. They initially develop their product in very, very close collaboration with just a single customer Pfizer.
Another example is a company called mid desk, which is a company that we work with here at Squire. It's a no your business solution, a Kyiv solution founded by a team out of checker from the very beginning of the company, they co develop their product with early customers like a firm and brax and rippling. on the consumer side, it's both easier and harder. After you launch, it's much easier because you can just quantitatively measure what is happening, you instrument the product, you acquire a certain number of users each day. And you can just compare and contrast sort of version of reversion if you're going in the right direction. But it's also much harder pre launch. Because you're not working with a few big businesses, you're you're just working with individuals. So what are some strategies here? I can either not to be confused with Viva. I think Sridhar, he's the CEO, they're sat down and personally on boarded, every single customer in the early days when it was in alpha, and when it was in beta, I think I sat down with him two or three times. And clubhouse famously did this in the very early days with test flight. In the very beginning, they had a very bad invite system. And they had a very fast moving test by test flight, and actively cultivated relationships with those early adopters. These are the kinds of constant daily weekly feedback loops that help you stay grounded. Now, I'm running short on time, and I want to get to questions. But I wanted to close with this when we're evaluating a company, there are usually three dominant dimensions that we look at team, product and market. And at the seed stage, you typically only have two of these team and market, often your pre product, and almost certainly your pre product market fit. So fundamentally, we're evaluating three things. Is the team good? Is the market good? And can this team find product market fit? So how do we evaluate that third question? I think it really comes down to this view of the world. First, do we like your starting point? Do we feel like you have the right entry strategy, the right wedge? To? Do we like your strategy? Do we think you have the right sequence of steps? Do we think you have the right path forward to find product market fit? Do we believe you can find product market fit? And then three? Do we think you can you have the speed, the cadence, the tempo, the consistency to actually find product market fit? We were literally we had our partner meeting on Tuesday instead of Monday this week, because a fourth of July, my partner outfit was talking about exactly this with one company, his core, one of his core questions was just do they have the cadence and consistency to sort of to go forward? So thank you, and sorry for the compress time, but I would love to dig in and take questions.
Thank you so much, Mike. That was fantastic. I hear that there are a lot of questions coming in, and we're gonna get to all but one thing that I wanted to ask you as we as we've jumped into audience questions, it's like, how does a founder prove that to you? Right, like, do you have the right strategy? Do you have the right tempo? What, what could I come and say to you that would show you, Hey, I am aware of pace, and I can move quick? Is that like a resume thing? Is that, that I plan to do this? You know, pick my head up, take a breath assess once a week or every two weeks, how do I actually express that to you?
Yeah, I think there's a few things. One, if you depends on whether you have a product and whether you have customers yet or not, if you do have a product. And if you do have early customers, we chat with customers. And we we often ask like how fast does the product move, and we love to hear that the team is the team is super fast. The CEO is incredibly responsive. She like responds to our emails incredibly quickly, and the team just iterates on sort of a weekly, weekly basis. So we definitely listen to customers for this, too, like we pay attention to how quickly does the product evolve. If it's a mobile app, you know, every time you log A new version of the mobile app, it shows up in the App Store. If it's, I mean, it's the website, you can just see sort of how quickly does this thing change. So there are definitely things that we look at to figure out how quickly this thing moves. But a lot of this, a lot of this comes down to founder references, like we at least when we first started working with someone, we tried to do our homework and talk to a lot of people that know this person to understand what they're like. And we encourage families to do the same about us. And I think for many of the best founders, you just you hear about two things, I think, one is this kind of impatience, and just get stuff done mentality. And then to it, you know, in an ideal world, you have that and you also have sort of customer obsession, you just have someone that like really, really, really wants to get better every single day and wants to serve the customer even better.
Got it. Okay, so, we have a question from Sharon, in the chat. And she asked, How do you adapt your company story and your product market fit for exogenous events, such as the pandemic, the release of innovative technologies, etc?
Wow, that's a great question. I think the I mean, the pandemic was actually an incredibly interesting exogenous event. Because, for obvious reasons, you know, we wrote a memo last year and the Black Swan, obviously, the world changed almost overnight. And you saw some companies that turned on a dime, either, you know, they had the right strategy, but they had to, you know, they didn't fundamentally change what the company did, but they changed their direction, their speed, either they invested more, they invested less, but they they sort of adapted very quickly to those exoticness events, that that I mean, we look for things like that. And that is incredibly positive sign. The second thing we saw a lot of companies do is actually just pivot their strategy. Like they, they realized that the market that they were in, was going to be fundamentally altered by something like the pandemic, and actually just completely pivoted the company. When those are both, both of those things are the kind of sort of speed and responsiveness we look we look for, I think it's generally, you know, if you put yourself back in the mindset of March or April last year, I doubt many people were doing this. But the notion of like putting your head in the sand and not believing that the world had changed, was probably not the right strategy, or the wait and see, let's see, what happens in the next couple of months is not the right strategy. The people that I think did best in the, in the pandemic, are the people who just turned on a dime and, and sort of really just went for it folks like DoorDash folks like instacart, folks like zoom and the like. Obviously, those are bigger companies.
Yeah. You talked a little bit about about cadence, right? And like making sure that you've actually explicitly stated, okay, I'm every so often we're going to assess, make sure we're taking in that feedback, and readjust our direction based on that. What are your thoughts on what that should be? Right? Is that an every other day is that, uh, every two weeks is that once a month? I'm sure it's different based on the size of the company and kind of where they're at. But how would you break that down for founders in the audience?
Yeah, um, I, I mean, I literally tend to think, like, the faster the better. Like, if you can be on a daily cadence, I mean, it's hard to be on daily cadence. I'm not this is not, don't get me wrong. But if you could literally be on a daily cadence where you're pushing out a new version of the product every day. That's, that's incredible. You know, if, if a customer This is a little bit extreme, but it's also a you know, if we share this, we we love it, you know, if a customer asks for a feature in the morning, and then suddenly they like they have the feature the next day. That's, that actually does happen. It sounds almost magical. That's That's amazing. In practice, I think daily is very hard for people to do, I think a weekly, especially if you're a mobile app, or if you can ship something through the app store is every day. But I think you need to be at least on a weekly, weekly or bi weekly cadence. If your mobile app, I think weekly or bi weekly shipping things to the App Store. Like that, that is the kind of speed you want to that's the kind of speed that you want to get on. Yeah, that's that'd be my quick tip. Like, if you think again, if you think about something like I gave the Sridhar Niva example. The thing that's amazing about that is if you you know, especially if it's a web product, if you make it better every week, and every week, you get to have the onboarding script be a little bit better. You see something about a place where the customer, the consumer was confused about something and you fix it. And then next week, you see that it's fixed. Like, that is the sort of the tempo that gets you to have incredible onboarding flow. And in general, sort of like, an incredible product for customers.
What about that feedback loop? I mean, we talked a lot about kind of, you need to design a feedback loop. And I understand the the example that you gave with BMI, right? Like, if you're actually onboarding those customers, or or users, then you have a relationship with them, you can hear from them, you can ping them, etc. Is there like software out and I get a lot of pitches for companies that are being built specifically for this for user feedback? And how you can collect it and the best ways to go about getting it? Is their software that you recommend? Are there ways to design feedback loops that are better than others?
Yeah, it really depends on this stage. And the scale, I think, at very small stage. I mean, at very, at the very early stage at very small scale. I think it has to be human. Like I don't know, if there are any great tools, there are great tools. Once you get bigger, there are great tools for quantitative measurement, and experimentation and the like. And I think those are incredibly important tools. They're also great tools for qualitative feedback, sort of user surveys, user tests and product experiences. But if they're very early days, when you probably have a single digit to dozens of people, nothing replaces just talking to those people all the time. I say generally, that that would be my that would be my advice. I mean, I think the this again, this is a little bit easier. It's a little bit easier on the enterprise side, because you just end up with fewer customers that are bigger. And so you know, for most SaaS companies, for most infrastructure companies, they start off with two or three development partners. Basically, they start by trying to find five to 10. And then a bunch of them drop off. So hopefully, you end up with this kind of kernel of two to three folks that you were talking to, at least once a week, if not more often. I mean, you're talking to you as quickly as you can turn around software, but you're just constantly talking to you to get to make this better and better. And I think on the consumer side, you can create a similar dynamic, I think people do this less today. But I think people are starting to do it more where you literally build, you ship something in a test flight, you have a few 100 users, you build a pretty close relationship with the early customers, not friendlies that want you to succeed, but people that are the target market for your for your product. And you just constantly talk to them to figure out if something is getting better or worse.
So Thomas, in the in the audience had a question as well. He said, um, he's said, How do you evaluate the pace of development if it's a deep tech startup? So you know, when you're doing something brand new, maybe you're building brand new battery technology or or something in biotech, that, you know, it can't necessarily be measured? The same way that kind of the startups and software startups that we're used to seeing are? How do you think about pace differently? And maybe how do investors think about pace differently? Is there more of a cushion there?
Yeah, it's a great question. Um, I think this is one of those things that this is one of the reasons that deep tech startups are harder, frankly, is you don't I mean, there are two different types of deep tech startups. There's one, which is there's deep, you know, we sometimes talk about one thing about a company, is this company more R or D? Are you this company more research? Or is it more development? I think it's more research. That can often just be candidly a harder fit for the venture model. Because either there's some fundamental, hard, unknown science problem to solve before you can actually commercialize that product. And so for those I, I don't know how to rush the science or the innovation, I will sort of defer to others on that. I think if the deep tech startup where the science is known, but it's just going to take a long time to build hardware can be a good example of this. Sometimes you I mean, sometimes you just have to roll with it. I think hardware hits or while I do think there are ways as you build. I think there are ways as you sort of iterate on the hardware to incrementally de risk things. I mean, I'm not a not a hardware expert, though. I work with some companies that do hardware, and obviously there's kind of a chain of DVT EBT PVT where you sort of incrementally get a Closer and closer to final harbor releases to sort of prove out a lot of to sort of prove out your final manufacturing. But even in the interim, there's a lot of stuff you can do with sort of like big, bulky bread boxes and, and the like to just sort of get something even if it's super clunky, in the hands of customers really early. So
I was hoping to that we could maybe go go back to that digging, don't keep digging slide. And maybe you could, you could dive a little bit deeper on that bit, because it feels like the one that that's like the real big trap for a lot of startups, right? You've spent so much time building something, you release it to a few users, and then you kind of like, aren't really sure, do I spend three or four more months? Can you talk about like what it actually looks like from a founder to say like, here's how I know which way we're going to turn. And what that kind of reassessment moment looks like, and communicating it to the team, it just feels like a very stressful situation where I would assume most founders will keep going in the direction that they were on just because of exactly what you said, we just did this, you know, like, we got to just, what does that actually look like in practice, and more specifically?
Yeah, I'll give you let me give two examples at different stages of this as to try to hit on this point. The I can go, let me try to go back to the slide quickly. So what often happens. So I think what will often happen is you'll build, I'm thinking of concrete examples, but I'm gonna abstract them a little bit. I don't talk about individual companies. But what sometimes happens is, you build a first version of your product, you take it to a bunch of customers, you observe how those customers use it. And there's, there are a bunch of positive attributes. But as you as you sort of study their pattern, you feel like you realize, there's like one flaw and how the system works. And that flaw is not, it's not a simple fix, it's not a growth hack. To try to get that fixed, you kind of have to like redesign some automated system. And usually that redesigning is, is one structural, like it touches a whole bunch of parts of the system. And then to you're not in, like, you have an intuition for what it should look like. But it's not super well defined. It's it's an I mean, in some senses, it's like a whole new or different product. That is like a cousin of your first product. But it is not just like an evolution of your product. And so I think what often happens is you kind of go off and fork your product, to really flesh out that idea and figure out like, what is like, I think I think we can fix the problem by changing a bunch of these things. You build this new thing, you iterate on it a whole bunch, and you're finally like, Okay, this is it. I like this is the right thing. And but now this, like, first cousin of your initial product looks nothing like your first product. And this is I mean, it's tough for two reasons. One is it's tough. Like, what do you do at that point? Do you give up on your first product, switch to your second product? And then try to migrate your customers over? Do you try to merge your second product back into your first product? It is a it is a tough setup? I think the end? It depends like the answer is if you're if your second product is clearly so much better than your first product, then you should probably just get your first product and and go ahead with the second and extreme versions of this are like, you know, the famous slack they started as a mobile game, they built slack on the side, that's not a perfect example. But that's one example. What I think happens much more often is you're then like, okay, you solve this problem you have to solve Now, how do you get it back into the first product, and then suddenly, you're stuck because you have, it's gonna take you like two or three months to sort of merge those things back in. And so I, I would generally suggest two things there first, I think it's very risky. This is super tactical, but I think it's very risky to ever fork your product and sort of start two different code bases. Like you are just, it is expedient at the time, but it creates a huge amount of pain down the road. So I think if you fork something, you should realize that either you're going to have to like throw away your first thing or you're going to have an incredibly painful merge. And then to when you are in that situation, I think what you want to do is like decompose that second thing into the smallest possible pieces and sort of incrementally merge them back into the first product versus just trying to do this sort of like mother of all merges. I realize it's a little bit abstract, but that's like a pattern I've seen Probably a half dozen times in my career. And it's that is the sort of like building. That is how very well intentioned people end up building sort of in a corner for a year.
Right? Yeah, no, I think that was super useful. Um, I did want to make a note, because I forgot to say this. Thomas, you asked a question about deep tech, we actually do have a session later in the day, that's focused specifically on how deep tech founders can get investment because it is a tough category. So you should check that out. We have a great question here from Solomon, which is, how do you deal with the tension and FinTech fatigue between taking credit risk slowly adding features quickly? Is that something you've seen? Like?
Um, that's a good question. Let me think about that. Um,
I think the
I don't know if I have a super good answer. For this, I will say a couple of things. But I probably need to think about it some more. I think it depends a little bit on the stage of the company and your credit line, and a whole bunch of specifics about the company. But I think there's, for lots of things, you can basically set a budget for, like $1 budget for how much you're willing to experiment with something or use for something, this happens a lot in marketing, like you will pick a channel and you'll just set a budget. Like if you want to figure out how to do growth, marketing, or paid marketing, maybe you set a $10,000 a month, or $30,000 a month budget to just sort of figure out how to be good at paid marketing. I think similarly, in FinTech, if you're building a new feature that has real credit risk, where the risk is monetary, it's not like, you know, it's not worse than monetary, then I think you can sort of build a product with a very small number of people, maybe like 10s of people, 10s of 10s of early customers, and sort of just prove out the product mechanics before you take real monetary risk. So that's probably how I think about it.
Yeah, and kudos to Solomon for something, Mike, I don't think that that happens very often. Um, Daniel had a good question, how much should you try and protect your innovations? If you're first to market? I think I know, you're gonna say my two software patents actually work?
I a guy. I mean, I don't know. I think sometimes people will put sly putting their slides that they got a patent for something, and I kind of ignore it. I think the the challenge, the challenge of software patents, as I'm sure most of you know, is they may take a very long time to issue, they can be quite fragile. You, you don't really know whether you have a patent like issuing being issued a patent is not a great test as to whether that patent is defensible. Like you only really know if the button is defensible, if it gets litigated and litigating a patent takes years and years and years and lots and lots of money. So I think, like if you're if the defensibility of your company is predicated on software patents, that's, that's generally not good. Like they're fine. It's like a fine belt and suspenders approach, but like your company should be defensible, intrinsically, for some reason, not because of patents in the legal system. So
that's not a question from Nisha, who asks, How do you know when you're ready to reach out to investors for funding this or some kind of list? For example, if you're a solo founder, and you have an MVP, but not a customer ready product?
Um, well, I will say I'll say a couple of things here. First, I think one mistake. One mistake that I think founders make is waiting to waiting for perfection in terms of a pitch. And I think the, I think this cuts, I think there's two aspects to this. First is like, waiting for your formal pitch to first tell the story of your company. And then sometimes, you kind of save. You try to compress everything down into a very short window, and you sort of put the higher pressure meetings towards the end. And so suddenly, you sort of you show up with a pitch and you you're like, I want to make a decision in the next week or the next couple of days. And now, like if necessary, we and I'm sure other firms can move back quickly, but I really don't think that's like the right setup to start what is a very long, often a long lasting relationship. I often think like the the I think the better strategy is some mix of like, fine. Some folks that you respect ideally, not necessarily. But ideally, you have some relationship with them already. It could be angels, it could be folks at venture firms have a like and sort of iterate, iterate with them in the early days about the idea. And then I think about that is when you get a bunch of feedback around your idea, but to sort of incepted that idea, and other people as well. So they sort of think about it in the background. And then, like, do that many weeks or months ahead of actually formally raising, because then when you're getting ready to raise, you're not one you're not starting the relationship relationship from scratch, and then to the person on the other side has already been thinking about has already is already already knows you already knows your company has already been thinking about the idea has maybe seen other things so they can connect the dots, etc. So I think like, start early, don't wait for the formal pitch, try to build the relationship early. And then treat the pitch as kind of like the end of the beginning instead of the beginning of the beginning. So
yeah, I've heard that expression from a lot of VCs, Mike that, like, it's kind of never too early, like you, at least you're getting on the radar, at least even if you're getting like no, no, no, you're getting some sort of feedback. Normally, at least if they're good VCs there, they should be giving you some sort of feedback, and kind of learn from that and continue the relationship and that soft circle way. So that eventually, when it comes time, they know what's going on, they have an idea of kind of what, what they want. We have time for maybe one more question. Um, I was hoping that you would talk a little bit about product team fit, because it's something that we're hearing more and more in the marketplace. And from our audiences, you know, investors are not only looking for product market fit, but they're looking to make sure that the team and the product makes sense together. Is that something that you think about a lot when you're evaluating startups? Is that something that Sequoia thinks about a lot? And how does a founder kind of express that to you? Yeah,
well, there's two, there's, there's kind of like team, this is maybe subtle, or like semantic, but there's team market fit. And then there's team product for fit. And they're very related. They're a little bit in my mind, they're a little bit different team market fit to me is like, is this the right team to go attack this market? And then team product is like, is this the right team to build this product? I think we focus a lot more on the first which is team market fit. And the way that I think about it is we really look for authenticity and some unique insight from someone in, in building that company. Like we almost every pitch at Sequoia, I think it's sometimes those founders off is like the, you know, we will will will come into a meeting, we will introduce ourselves. And then our first few questions before you get to any slides or first questions are like, tell us a little bit about yourself, and like why this company? Like why did you decide to start this company? And the reason we ask that question is we want to understand what is this person's relationship to this company and sometimes make the best possible cases, I was doing something else. And this thing annoyed me for five years, I couldn't understand why this thing work this way. I talked to a bunch of other people, they all had the same pain. I kept trying to find a better solution in the market. I couldn't find anything. And finally I decided, Okay, I should just go build it. That is like an A plus we love that answer. What people don't usually say this, but the the other common case is, I really like I wanted to start a company, I was sick of working at my big tech job. I like created a spreadsheet, I had 30 different ideas. I scored them on like five dimensions, and this was the highest score. And so you end up with someone who has no, you know, no real domain expertise. Maybe like a few months of conversations attacking a market. There are people who've been incredibly successful and the former models, I'm not saying it doesn't work, but we really look for the former, we really look for someone with sort of a deep lived experience. And we're almost reluctant founders who are kind of starting the company because they couldn't believe they felt this pain and they couldn't believe no one had solved it yet. So
okay, Mike, I know that we are out of time. But there's one question that's come up, it's slightly off topic, but it's come up several times in the chat. I was hoping you could briefly answer it, which is what's the best way to pitch a firm if you don't have a network for a warm introduction?
Um, yeah, I think we try to so I think two things first is cold email does work like I I may get some answers and there may take me a while to respond. But I do read all of the cold emails that I get, and I try to respond to all of them and I go through the deck. I think people sometimes write novels in this quote That's really tough. I think the shorter the pithier the company, the shorter the pickier, the intro, I think is incredibly valuable. And don't try to cram everything in like the, I think it comes down to like, what are you doing? Like, what is the company and people probably have some calibration on that. And then a couple of supporting facts around why you either why you are the right person to build this company and any traction you have. Those three things can work pretty well in, in a cold email. So,
yeah, I think that's true probably throughout the entire pitching process, which is that you're trying to get questions. You're not trying to answer them preemptively and predict them. You want an investor to have questions and and want to learn more. So that's really the goal. Mike, even amazing. Thank you so much for taking the time. We have a break. Going down right now on stage one on stage to Lisa Wu, from Norwest is going to talk about how to think like a VC if you want to head over there. Thanks again, my appreciate your time. Thank you all