Episode 209 ·

Peter Bailis - CEO at Sisu Data

Today we are talking to Peter, the CEO and Co-Founder of Sisu Data. And we discuss the process of going through product market fit, creating an open environment that promotes individual creativity, and how even bad products can gain traction if the problem is big enough.

All of this, right here, right now, on the Modern CTO Podcast!

About Jon:

Peter Bailis is the founder and CEO of Sisu, the fastest and most comprehensive diagnostic analytics platform. Peter is also an assistant professor of Computer Science at Stanford University, where he co-leads Stanford DAWN, a research project focused on making it dramatically easier to build machine learning enabled applications. He received his Ph.D. from UC Berkeley in 2015, for which he was awarded the ACM SIGMOD Jim Gray Doctoral Dissertation Award, and holds an A.B. from Harvard College in 2011, both in Computer Science.

About Sisu:

We’re building a new kind of software that empowers people to make better decisions with data. Sisu's continuous analytics platform helps you understand every factor driving your business metrics using all of your data, in real time.

Transcript

(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to Peter, the CEO and co-founder of Sisu. And we discussed the process of going through product-market fit, creating an open environment that promotes individual creativity, and how even bad products can gain traction if the problem is big enough. All of this right here, right now on the Modern CTO Podcast. Here we go.

(Joel Beasley at 00:00:23) This is the Modern CTO Podcast. Hello. Hey, how's it going? Excellent.

(Joel Beasley at 00:00:38) Boom. Look at that background. Sisu Data.

(Peter at 00:00:42) Yeah, yeah. Our designers went kind of wild with it, so happy to rep.

(Joel Beasley at 00:00:47) Yeah. You've got good designers, too, by the way. I really enjoyed the website.

(Peter at 00:00:52) Oh, nice. Thank you. Yeah, it's a little different than what everyone else is doing. So that was the goal.

(Joel Beasley at 00:00:57) Yeah. It was simple. It was easy to understand. I liked it. So we're just gonna hang out and talk.

(Joel Beasley at 00:01:03) So recording now, we just do whatever we do. Jake and the team, they edit it up, make us sound amazing. Is that cool with you?

(Peter at 00:01:10) That's great.

(Joel Beasley at 00:01:12) Awesome. My favorite part of your website is you list your values on there as a company. I think that's amazing. And you go into each one of them and you explain the value. And to me, that's just very different. Most websites don't do that.

(Peter at 00:01:29) Nice. Well, yeah, I appreciate that. I think one of the things I've learned a lot from working with Ben Horowitz has been a lot of values are kind of what you—it's a lot about what you do, not what you say you do. And we've taken a pretty deliberate approach to figuring out, you know, who we aspire to be through what we do, as opposed to just, you know, being customer-obsessed like everyone says. Right? We talk about, you know, what does it really mean? What does success look like for our customers? Right? So actually really wowing them. Right? So living in those moments like, holy cow, I can't believe I can do that. And so instead of saying we're customer-obsessed, saying, hey, we're into delivering the wow to our customers. That's a more authentic perspective on who we are. And so many of the—the idea of iterating towards greatness. Right? It's like being, moving fast and breaking things. That's actually a pretty good one because it's polarizing, but I like to say iteration. And it's not just towards greatness. It's like you're not there yet. You're never great, but you keep going there. So I appreciate you picked it up because it's something we spend a lot of time on internally. It's something we kind of hold each other accountable on that. A lot of times, values are just aspirational or, alternatively, kind of milquetoast statements, and we try to take ones that were authentically us and kind of reflect the way we like to work and do things as a team.

(Joel Beasley at 00:02:40) How does it play out on a day-to-day basis? Do you acknowledge team members for delivering wow or taking ownership? How do you get that to happen?

(Peter at 00:02:49) We do a lot, actually, with this. I think part of it is these are kind of values that come up in day-to-day communication. Right? So if there's, say, something we ship that someone conceived of as an idea that started off as kind of just a, "Hey, wouldn't it be crazy if you could do X for a customer?" And they go and ship it and spec it and deliver it, and say, "Hey, you know, kudos to Charles for taking ownership of our outcome. It's really driving the scene to completion." Or similarly, you know, if we screw up, which is common, you know, in a startup—you're constantly learning—it's not, "Oh man, we really screwed up." It's, "Okay, we're iterating towards this bigger picture." Right? "We're iterating towards greatness here." Right? The goal is to figure out how to provide the best result quality here. We saw we had a regression. Was it part of the iteration? Key part of iteration is that you learn. Right? So it's like, what do we learn from that? And so kind of calling it out on a day-to-day basis is important. And also, we every week have a company all-hands. We all get together and people actually, you know, call each other out. It's anonymous, and then someone acts as kind of the radio announcer, which especially in remote with COVID is pretty fun because you test out your radio voice. So you can say, you know, "Michi delivered an amazing customer research session with this user. Really delivered wow in terms of synthesizing the results for informing the future waterfall visualization, yada yada. Congratulations to Michi for—" and people kind of go over the top with the voices. It's kind of a process that feeds on itself, which is a lot of fun.

(Joel Beasley at 00:04:17) Yeah. It sounds like an internal fun thing that you guys do, and a collection of those creates your culture.

(Peter at 00:04:23) Exactly. And I think a big part of this, too, is, you know, we're in a space where, you know, there's a lot of—the blueprints aren't just laid out in front of us. It's not like we're just saying, "Hey, we're gonna build a faster database." We need to build a SQL compiler and parser and compiler and query planner and so on. There's a lot of iterations from what Sisu is in terms of the product category that we're building out and functionality and so on. It's pretty multidisciplinary. So I think it's really important—one of the most important ones for me is the idea of kind of expressing yourself where you have to have this environment where people feel comfortable going out on a limb and kind of being a little bit wacky. Because at the end of the day, some of the crazy ideas end up being some of the most valuable ones. And, you know, you're not gonna feel comfortable speaking up unless you know that it'll be okay to, you know, say something that's wrong some part of the time. And also, just kind of by expressing yourself and not being afraid to be a little goofy, it really does kind of open up space to be a little more creative in terms of everything from the website design to, you know, product design to branding to all the stuff that makes a company actually work. And that for me is one of the most satisfying parts of actually being part of a rocket ship like Sisu.

(Joel Beasley at 00:05:37) How did you learn that these things were important?

(Peter at 00:05:40) Yeah. I think part of this—so, you know, I'm an academic by training. I think in the lab, in research, the whole goal is to basically, you know, make mistakes and take big swings. Right? I always joke that, you know, if you know that research should be successful before doing it, it's not really research. Right? And I think from a company perspective, I wouldn't have left the lab for anything other than, you know, a big swing, a big audacious swing. And so it's kind of maybe clear to me or at least it's clear in retrospect that to take a big swing, you have to have an environment where people feel supported and nevertheless challenged to be ambitious in the same way that a lab expects that. And, you know, for me, I view a company as a way to take bigger swings by, in some sense, taking smaller steps that are grounded in practice, but it's all about keeping that bigger picture in mind. And I think the challenge is if you end up with a super kind of just hierarchical or top-down or even just kind of super well-defined, non-malleable kind of culture or perspective on who's doing what and when—like, you have to get stuff done. It can't be a giant holacracy. But if you kind of stifle that individual creativity and spirit and drive, one, you end up suppressing a lot of diversity that makes companies stronger. It makes Sisu stronger. And then two, you're just making less valuable steps on a near-term basis towards these bigger objectives. So I think it's just kind of an extension of the lab model. And, you know, in research, your greatest strength is your greatest weakness. You're not accountable to anyone, really. You know, you have to file some reports with the National Science Foundation, but they're basically—you can't fail a report other than not handing it in. A company obviously has a lot more accountability, but you can take some of these ideas around, you know, product development and thinking big and working collaboratively and taking big swings. And it turns out it scales pretty well as long as you make it clear what the metrics for success look like.

(Joel Beasley at 00:07:43) So you mentioned bigger picture. What's the ultimate vision for Sisu?

(Peter at 00:07:47) Yeah. I mean, great question. For me, the ultimate biggest picture is organizations today and, you know, for the foreseeable future, have access to more data than ever before in the history of humanity. And yet the tooling for making use of this data on a day-to-day basis in terms of, you know, taking the right decision, making the right action—whether or not I'm in IT or marketing or sales or product. Right? I'm still making all these some gut feel. Right? And I'm increasingly evaluated on KPIs. You know, if I'm product, I'm gonna look at, you know, engagement, utilization. If I'm marketing, I'm looking at converted leads and reactivation and churn, sales, revenue, so on. I have these KPIs, but there's this huge disconnect between measuring the KPI and then the actions I actually take every day. And so, you know, the opportunity is you already have an org chart that's hierarchical with KPIs laddering up into profit and loss. And the question is, how do you use software to help bridge the gap so you can take advantage of all that data, prioritize where people look and understand what's going on in their businesses based on that data, and ultimately be more comfortable making the right decisions. And so if you see Sisu, you know, in the ten to twenty year range as this kind of technology that allows people to be better at whatever they're doing today on a day-to-day basis in their jobs by making maximal use of this insane amount of data, not just in terms of volume but also the amount of granularity of this data, to make maximally informed, kind of optimal decisions on a day-to-day basis—not by removing the human from the loop. Because people are—I generally believe people are creative. It's the kind of individual intellect and ingenuity that makes companies great, but really augments that ingenuity by taking a lot of the burden of knowing what's going on, why it's going on, what the set of options in front of you look like at any point in time, and letting the humans kind of steer the ship, but not have to worry about, you know, the speeds and feeds of the engine, you know, at every twist and turn.

(Joel Beasley at 00:09:51) Yeah. No, that's—I was looking through the website trying to build a visual model or a mental model of what you guys do and how it helps. And it looks like you just connect into a number of data sources and then automatically generate these pretty interesting insights. Is that accurate or no?

(Peter at 00:10:11) Yeah, yeah. So kind of going out from the twenty-year horizon or, you know, five to twenty-year, zooming up to what we do today. I mean, you have people trying to run their businesses constantly—very dynamic market conditions, actually today with what's going on in the macro environment. And they already have KPIs. So concrete example, Samsung's a public customer. They spend about a billion dollars a month on marketing, and they're constantly trying to figure out who's upgrading phones. Right? Who's buying new phones and new devices and so on? They have a KPI, which is conversion rate for their new devices that are released into the market. And what Sisu does for Samsung is it doesn't replace their marketing team or even their analyst team, but it helps, you know, their marketing team and their analyst team understand every week and every day and every sale, you know, what's driving conversion rate. Any number of tools, you know, they've got a data warehouse and visualization and dashboard tools. They can tell them what's going on. You know, conversion rate is flat or it's up by 1% or down by 1%. What we've built Sisu to really excel at is to understand why these metrics are changing. Is it a given carrier and a demographic? Is it demographic in a given region? Is it a region and a carrier? Is it a coupon code, a discount code? There's all these different possibilities. And, you know, historically, you just have, "Hey, this is how many units of phones that I sold." But today when I've got hundreds of individual factors attached to every sale and, you know, hundreds of millions of possible answers to the question, "Why did conversion rate change?" Sisu basically is an accelerator that helps the analyst understand, "Okay, what's really driving this change?" And then the beautiful thing about metrics is they're defined by the business, you know, once a quarter, more likely once a year. But the data is constantly changing. And so Sisu is sort of this filter that sits on top of all of this data that's already being collected and notifies users not only when their metrics are changing, but when their metrics change in a way that's actionable, that can actually be acted upon to, for example, change conversion rate or, you know, maybe you wanna change your campaign or your targeting or so on. Right? So it's really this super tool that tells you why things are changing and helps you understand what to do about it.

(Joel Beasley at 00:12:24) Interesting. It sounds like—I think before, what would happen would be the analyst would maybe have a feeling or an insight or an idea, and they would go check, are these things correlated? But there's so many thousands of data points to check if they're correlated, and some are correlated but aren't meaningful. Some are correlated and are meaningful. And so it sounds like it just finds these meaningful correlations in these vast datasets and then orders the insights by the ones that are most actionable?

(Peter at 00:12:54) Yeah, exactly. Actionable and then also, yeah, meaningful. Right? And there's all these different—there's a whole field of what's called causal inference where, you know, there's no substitute for running an A/B test. Right? So if I truly believe that, you know, changing my messaging is gonna improve conversion rate, for example, I can create a campaign and show that campaign to a set of users, and I can go and measure the difference in lift between the old campaign and the new campaign. That's the gold standard. But the reality is—and that's kind of what people do all day anyway. If they don't have data, they're like, "I'm gonna try this new campaign. I'm gonna try this—" it's based on a lot of intuition and gut and a little bit of reading of the metrics. There's no substitute for actually taking—running experiments or taking an action. But the reality is if you're already gonna be going and changing your campaigns and targeting and spend, or if you're in product, changing the way you push users to feature A versus feature B or you prioritize your roadmap—there are experiments that occur already on a macro scale. There's hundreds to thousands of these going on within every business unit, within every large-scale organization every day anyway. You know, our goal is if we can help nudge the direction which those experiments go to identify the most promising kind of levers to pull in the business by taking advantage of all the data that's being collected and is increasingly collected, you know, in centralized repositories like these cloud warehouses, then you can really move the needle in a huge way that goes beyond just, say, increasing conversion rate, but ultimately gets us a little closer to this vision of informing decisions with data.

(Peter at 00:14:21) Which is something people talk about a lot, but actually doing it is super hard because, as you kinda point out, the status quo today is I hire a bunch of analysts. They end up spending their time on their most valuable metrics, which are often the lagging indicators as both in the leading indicators. And even inside of the most well-funded Silicon Valley organizations, it's not like every line of business operator has an analyst team dedicated to them. Right? It's typically the C-level or the leadership team will, then everyone else is like, "Oh, just go slice and dice yourself."

(Peter at 00:14:49) And so our observation is not that you can ever compete with these teams if you were to have enough analysts and enough time to go and dig in. But again, that's not gonna be feasible. So you can plug 80% of that gap and deliver net new capabilities when it's just not cost-effective at all today. Again, not automating the process, say, writing ad copy or figuring out what products to run or running the A/B test themselves, but kind of informing the processes and workflows that people are already doing today throughout the business using the data they already have access to. Just there's this gap in the tools that's just so apparent once you go and talk to enough of these folks.

(Joel Beasley at 00:15:27) I love it. It's gonna be a big company, man, and it's growing. I'm excited for you.

(Peter at 00:15:33) Yeah. That's the bet. That's what got me out of the ivory tower. I mean, we've worked with a couple, and we're fortunately sponsored by a bunch of relatively large and advanced tech companies like Facebook and Google and Microsoft and collaborate with these folks. We're able to kinda—I like to view as you get to see the future when you work with someone like Google. But for me, the excitement was, look, there's a whole bunch of people who have, perhaps, surprisingly, massive amounts of data. You don't have to be Facebook or Google today to have enough data to do interesting things around, say, causal inference or in terms of customer analytics. And, you know, look, the reason why we're all working productive or relatively productive, let's say, in a lot of environments during COVID and this shelter-in-place scenario is all this work is being done in SaaS tools anyway. Right? And these things are recording more and more of business processes and workflows.

(Peter at 00:16:23) And for me, it's like you just feel like there's something wrong in the world when there's all this exhaust being generated within these tools. It's all being—it's all landing inside of these warehouses. They're super cheap to store the data now. But it's like, wait, why are there not better tools for using all of this? And that's what got me excited—this idea that, you know, yeah, Google has tons of ads data. Right? And there's a ton of information on each ad campaign and so on. But there's also a ton of information about mobile device upgrades and about direct-to-consumer subscriptions and about mobile product engagement where you don't have to be a giant tech company to have this data. And in some sense, the giant tech companies just solve the easiest ML problems. They have all this data in the first place. Right? They have billions of people clicking on search results all day. In contrast, if you have a thousand analysts spending their time looking at a BI tool and they have clicks and scrolls and shares and saves, like, how do you use all of that data? Because you've got a lot of underlying data. You don't have as many clicks. Well, that's for me the hardest problem in data—ranking and relevance for private data.

(Joel Beasley at 00:17:26) So what was the day like when you decided to found this company? Had you just finished an academic paper and you're like, "This is brilliant. Let's commercialize it." Or how did it go down?

(Peter at 00:17:36) Yeah. It's a good question. I mean, for me, commercialization is a means to an end in the sense that I like to view it—every company and almost, I'd say to some extent, it's true of research as well—there are these huge trends that are bigger than any individual and bigger than any individual project or even company. And so for me, I've always been excited about data and tech and that it's this almost way to nudge the future in these giant waves that are bigger. And I think over the last, I don't know, five years where I spent my time initially starting as assistant professor at Stanford was looking at this giant wave, which is it's just super cheap to store data. It's not free, but especially when you look at human-scale data. There's only 6 billion-odd people on the planet. You can store a lot of data per person in a non-creepy, non-PII way with not a lot of—it's very, very cheap. Right? You know, terabytes of storage for dollars per month. Right? So the big question is, what do we do with all of this stuff? And for me, that was the big swing, iterating towards greatness. I was, literally 2015, the question was, if storage is free and compute was free, what would you build?

(Peter at 00:18:45) That's a pretty vague question. It's especially vague for an academic where academics are very precise and rigorous and so on. But basically, I started building up systems that were solving problems that I saw, you know, friends and folks who were funding us and also just folks who picked up some of the prototypes we were building struggle with when they had a business metric, had a ton of private data, and were trying to figure out what the heck's going on with this metric. And it was kinda funny because we had little professorware. I had written our UI and some of the v0 prototypes behind this project as part of this umbrella called Stanford Dawn, which is machine learning for usable analytics.

(Peter at 00:19:24) And what happened is I'd seen people pick up the prototypes. We had written a bunch of papers making stuff scale and making it faster and faster. You know, we have this paper where we process a day's worth of mobile engagement data at Facebook, which is just an enormous dataset. And I kind of saw the writing on the wall where I can keep being pretty successful working with students who I love, also building up some of these prototypes and throwing them over the wall to these big tech companies. But there's this bigger opportunity that kept me up at night, which is like, what if we don't need to make things run faster, but if we wanna make them more usable? And what if it's not just, again, the Facebooks of the world that have this data, but it's everyone who has a Snowflake cluster, who's bought Redshift? If data's free or increasingly close to free to store, then it's not just gonna be the big tech companies that have these types of problems. How do you make this accessible to everyone else? And after seeing the last ten years of big data systems where people just copied Google and then they started rebuilding an entire data system from the ground up, I was like, well, what if you—what can I do to accelerate the future? Sort of get people to the point where I think there's a better way to use all of this data. But rather than having to wait for things to trickle down from Google and from research and so on, we could actually—I could put my time and energy and resources, and by the way, do it with an amazing team who's better than me at all of these different disciplines—design to engineering, to product, and marketing. That was really exciting for me where I kind of realized there's a there there, and it's not just a there for the elites. It's for everyone who has access to this type of data.

(Peter at 00:21:00) And I always—I am a big believer in the Bezos regret minimization principle. It's like when you're 70 years old and looking back on your life, like, what do you wanna say you did? And, you know, although getting tenure at Stanford is obviously a pretty cool thing to go and do, and there's some really great people on the faculty, you know, I got a long time to live, I think. So this was the thing that I felt was the biggest contribution I could make to kind of nudge the tides of history and technology, at least in what I view as a positive direction.

(Joel Beasley at 00:21:30) I love how you, like, academicized my understanding of Bezos's regret principle. I can't even think of other words now than what you said. That's hilarious. I'm a big fan. Is his book still up there on the wall?

(Joel Beasley at 00:21:42) Yeah. There it is. The Everything Store.

(Peter at 00:21:44) Yeah. It's amazing. He's—I think he's just—it's phenomenal to see Amazon as such a product-driven company, right, and see how they continue to reinvent themselves. There's a lot of tech companies. I spent a summer working with the Google Cloud team before I started Sisu, trying to scratch the itch of, like, hey, how do I have this type of product impact? And it's amazing to see folks like Bezos, who's actually not a technologist, you know, develop product after product after product that's successful in market. And I see folks with this great technology, you know, fail to build product two or product three or product four. And, you know, Bezos and Elon Musk and so on, they get a lot of—I mean, everyone has their flaws, but I just have massive respect for the guy because, look, he's just unafraid to continue asking, "Can we do better?"

(Joel Beasley at 00:22:29) No. I'm a huge fan of Bezos and the Muskisms, and I've actually, you know, read both of their life stories and was super impressed trying to understand how they think and see the world. And then earlier when you were talking about the culture and everything and then the success and scale of Amazon, I was actually thinking last week about this. And I was saying the way that he's got the rocket company, he's got all the different companies, all different organizations, and he's not even in there. And I heard him in an interview—sorry, I'll put my mic back. I heard him in an interview talk about how he lives ten years in the future. And I was like, the only way you could do that is if you somehow, at the beginning, created such a solid foundation with such a strong culture, which I'm a fan of their culture. I've read their books and know some of their executives. And that is the connecting thread that allows all of that to be possible. It's like it's inevitable that they're going to go as far as they could possibly go before they're gonna get broken up by government entities. Right?

(Peter at 00:23:33) Yeah. Well, I think the thing is too, they're willing to say, "Hey. We might be wrong." Right? It's not clinging to the success that they had and say, "Hey. You know what? We're just a retail business." Right? As well as saying, "Hey. Because we have this really deep competency in running data centers now, we can externalize that." Or even things like Alexa. I don't think they were a natural language processing shop in the first place. They're like, "Hey. You know what? We're gonna go and put the resource behind this." And so we want to invest in all the time, which makes sense. But to actually say, "Hey. You know what? I'm gonna put my money where my mouth is. I'm gonna hire some of the best natural language processing people and it's gonna cost me—I don't know, it should cost me a billion dollars, you know, to build out this team. And I'm gonna put my money right out there and hire amazing talent and go from scratch, make that level of investment and commitment." And not just say, "Hey. It's a one-time, one-year thing," but, "We're gonna pour, I don't know, $5 billion, $10 billion into something, and we might be wrong." It's like there's some fire that I think fuels a lot of decisions, but you do that over and over and over. I think it's more than just an impulsive type of thing. Right? And obviously, there's some success begets success and so on. And if all they had were flops like the Fire Phone, then maybe at some point it would peter out. But I think that the degree to which both Elon Musk and Jeff Bezos go full throttle on, "Hey. We're gonna go and try and do something huge, and it might screw up, and that's why it's worth doing." I think that's a really powerful perspective. And toward your comments around the monopoly or getting broken up, I mean, I think that is the positive side of these massive tech conglomerates—you can afford to take way bigger bets. And it's interesting to ask the question, you know, you look at the coffers that Apple has and that Google has and then Amazon has. It's interesting to understand why is it that Amazon is so much more successful introducing more products to market. You know, why is Google still third or fourth depending on your count in cloud? And I think that it has to be a cultural element because it's certainly not a capital question.

(Joel Beasley at 00:25:39) Yes. And, you know, so to hit off of something Musk says, he talks a lot in his interviews about reducing the probability of failure when he goes into something. And I just love how he states it so systematically and simply. But one of the questions that I've had for you in the back of my mind this whole interview is, you know, how did you meet the person that would help you on the business side of these things? You're extraordinary on the technical side of things. I read your papers. I love it when I don't understand the things I'm reading because that's how I know people are smart. And I get the concepts. My background's software engineering, so I know it from the software engineering perspective. I don't know it from the academic machine learning perspective. But I'm curious, at what point in this endeavor did you meet the individual that would help you on the business, uh, sales growth side of things?

(Peter at 00:26:36) Yeah. No. It's a great question. I mean, I think there's kind of two answers. On the one hand, I've been really fortunate to have an amazing network of advisors in my career. So, you know, back in undergrad, Margo Seltzer was my first—mentored my first research project I ever did. She did Sleepycat Software and Berkeley DB. In grad school, had Ali Ghodsi and Ion Stoica, both founders of Databricks, as co-advisors, as well as Joe Hellerstein, cofounder and founding CEO at Trifacta. So I had this DNA of people in my network who were both super smart academics, but also gone to the commercial side. I think Ali at Databricks is probably one of the most successful crossover folks in recent history in that, you know, he really scaled that company from a successful open source project to basically this, you know, close to $10 billion juggernaut over at Databricks. And it's not because Ali is—I think Ali does have an MBA, but it's not because Ali has an MBA. It's because he's also got a PhD. It's because he's just a super sharp, you know, high IQ and high EQ individual who takes this systems thinking about historically distributed systems and applies it to the market and applies it to their products and is super involved in both the technology and the product development and the sales and marketing. And I think what I learned from Ali is and ultimately, you know, we work—ended up working with Ben via Ali's recommendation—is that a lot of the challenges in terms of giving this idea of product-market fit, which is—product-market fit's funny because no one can really define it. And if you could measure it, venture capital would be an entirely less profitable investment category.

(Joel Beasley at 00:28:24) So it's becoming so true. That's the trend, by the way, or at least what I'm seeing. Have you seen financing options that exist now? How they're doing it? I just did this the other day.

(Joel Beasley at 00:28:34) I actually plug in my Stripe, and then they'll give you, you pay a percent for the money. But it's basically you can get capital that's non-dilutive, and then you just pay a really small fee and it's automated and easy.

(Peter at 00:28:50) We'll talk about data. Yeah. The Stripe payments system is amazing because they have this data about an individual business, and they can make better informed financing than any conventional—you don't have to go with your binder and show it to the bank and say, "Here's my financials." They're like, "No, we know your financials."

(Peter at 00:29:11) Right? So that's the type of acceleration that I think is possible with data. And there's some venture capital firms that are trying to differentiate on data. It's hard in enterprise when product market fit is not this discrete event where you wake up one morning and your app is the number two thing on the App Store and everyone's inviting their friend. It's like you get to three customers, then you get to ten customers, then you get to thirty, then a hundred. It's just this weird, non-discrete kind of step.

(Peter at 00:29:39) But the net of it is, I think that process of getting to product market fit—it's a lot of the discipline, and it's kind of the second part of my answer—it's similar to what we deal with on the systems side of computer science all the time. In systems, in computer systems, there's never a unilateral winner. In algorithm stuff, in theory, you can say this algorithm is way better. Don't use bubble sort. Always use quick sort.

(Peter at 00:30:01) Right? You can use asymptotic evaluation. There's no asymptotics in most computer systems. Which is the best scheduler to use? I—

(Joel Beasley at 00:30:07) I don't know that word. Can you tell me what that word means?

(Peter at 00:30:10) Yeah. Yeah. So asymptotic means, as the input gets really, really big, which algorithm is faster.

(Peter at 00:30:19) Right? You can prove in certain cases that certain algorithms are better than others. So for example, a way to do sorting that's just really slow but technically correct is I will just randomly permute a list of elements, and I can check if it's sorted. And in expectation, eventually, I'll come up with a sorted list. In contrast, if I actually go and run any sorting algorithm, that's probably going to be more efficient, at least in expectation, than randomly flipping the order of elements in my list.

(Peter at 00:30:48) Right? So asymptotically, I can make firm statements in theory that this algorithm is provably better than this algorithm. It's faster, it's cheaper, and so on. But in computer systems, which scheduler should you use? Do you use the BSD scheduler or the Linux scheduler, both of which have different properties? Right? It's going to depend on the workload. It's going to depend on the constraints. Do you have low latency tasks? Do you have long-running tasks? Do you have a mix of these? Whenever a system—I said peer reviewer, and someone who used to write papers for a living—if a systems paper about databases or operating systems or distributions ever claims, "This is unilaterally better than another system," chances are it's a BS claim. Right? Because you should always have this qualifier: under these conditions, this is when it's better. Right? And so I think that same thinking is actually very applicable to bringing a product to market. Because product market fit on the business side is super cool because you're building this product out while you're having people use it or buying it. And you're charting this course between what do people want? What is the addressable market? What is technically feasible? And what can you get done in the limited amount of time you've got? And so you can make statements like, "Well, of course, it'd be better if we built feature A and B," but you have these constraints. You only have so many people. You only have a certain budget or so on. And so for me, the intellectually challenging part about helping build a company has been actually on the product and marketing side much more than the tech side because it's a lot of the same constraints. It's just you have less information than you do when you're running an operating system scheduler because the whole OS knows everything about what's going on, whereas here, you have to go and get data from the customers. But it's very—humans.

(Joel Beasley at 00:32:25) Yeah. Yeah. Exactly. It's hard to debug a human because you can't see through everything. Yeah.

(Peter at 00:32:30) Exactly. And you're like, "Hey. So why didn't you buy? What was—" So for us, you know, it's kind of funny. For the time being, when we don't do a deal, it's not like someone else does exactly what we do and we lose it. It's more like people are like, "I'm just going to keep doing, you know, keep working in dashboards. I won't do anything." Right? But even getting that information—like, "Hey. So why? What was it that turned you off? Is this the pricing and packaging?" Because we can probably be flexible on that. "Is this not that there's not a pain point? Is it organizational priorities in IT?" There's this huge constellation of things that have to go right for people to consume software.

(Peter at 00:33:03) And the thing I love the most about the business side of this is, you know, when someone pays for our software, they could be buying lunches for their team. They could buy t-shirts. Money is very fun. In academia, you just have to start with fiat. You're like, "This is an important problem." You've read some of these papers. Every paper starts with, "This is an important problem." You cite a few news articles. I'm going to say it's important and then we're going to say, "Okay. Great. Given that we established important in the first two paragraphs, we'll go and solve some technical problem." Whereas, it's the inverse in a tech-enabled company like SISU where we have to make sure the problem is important. And teasing that apart, when things don't go well, it's critical to figure out, "Okay, where's the bottle?" You don't have information. Similarly, when things do go well, you're like, "Well, great. You know, you want to make sure there's true value there. You don't want to be like, "Hey. They liked the salesperson or they liked the demo or whatever." You want to show there's actually something there. And so when I think about product market fit, there's no good books on this stuff. There's very few good business books in my opinion. I think the best things, like you've kind of talked about, are biographies or even Ben's books, like The Hard Thing About Hard Things. It's basically a biography. Because there's—you can't describe it, but that's the same type of systems that you need, at least in academia. What's kind of the name of the game, except a lot of times it's kind of brushed under the rug and you say, "Well, this is an important problem. I'm therefore going to move on to what I consider the fun parts or what academics do, the fun parts."

(Joel Beasley at 00:34:26) No. And I like how you're describing it because we just went through it, and I would say right now we have product market fit. But the path there over the past three years, you know, three years ago, people were asking us about product market fit and we're like, "Yeah, of course, we have it." You know, because it's the thing you have to have. But then you go through the experience and you understand it and you get the nuance of it and you see enough customers and you have enough conversations that you start to—if yourself or an AI algorithm—you start to have a large enough dataset to make meaningful insights on.

(Joel Beasley at 00:34:58) And so for me, what I've kind of differentiated is the step before product market fit, if you're taking product literally, is problem market fit. You have to find the problem that people respond to because you have to find that pressure or that pain point that they're willing to spend. And I call it "spending time," in a very literal way, like it's currency.

(Peter at 00:35:20) Yep.

(Joel Beasley at 00:35:20) If they're not willing to spend time with you on the bait that you're hanging out there and dangling in front of them, to even explore if what you have behind the curtain is useful, then you won't have enough pressure even if you have the best product in the world. You need pressure in the marketplace. You need people to be having a pain point when they're waking up every day, like, "How can I—I've got seventy-five analysts, and I want to optimize their time, and I want to get more work done?" You know, whatever that pain point is. So you first have to get that problem out there, then you get this—I always like to say my visualization, at least internally at the company, is we need a stream of water flowing to even begin to manipulate it or redirect it or do anything with it or grow a crop.

(Joel Beasley at 00:36:03) And so that stream of water is the people coming into the door from the pain point. They're responding to our emails, setting meetings. And then once we have that, now we can start putting the product in front of them, get the presentation right, figure out, you know, do the win-loss conversations, like you described, where we figure out what exactly is the driver behind their need to purchase for people who do and don't. And then you can sort of shape it. It's a malleable product. And then you end up in a market segment because before you swore there was no competitors, completely. Now you realize you're fighting for this piece of pie on a budgetary level because people always were asking you, "Oh, you know, who are your competitors?" I'm like, "Well, there's nobody that does the exact technology that we do, but from a budget—"

(Peter at 00:36:47) Yeah.

(Joel Beasley at 00:36:48) "—level, we compete on budget against these other budgets." And so I actually found that with some of the more amateur investors, they actually didn't like that or understand that. And I was like, "Well, this is how it's happening in practice."

(Peter at 00:37:00) Right. Right. Well, I think you're totally right about this idea that it's problem first. Right? And I think the challenge with technologists is that so often it's, "I've got this hammer. What nails am I nailing?" And I think there's some classes of products where if you're an order of magnitude, ten x, a hundred x faster or better or cheaper in some dimension, there's probably something to do with that tech. Right? If I give you a processor that's a hundred x faster than current processors, you'd probably do something with it even though we don't need a faster processor to run Zoom more effectively. Right? But, you know, maybe you sell it to high-frequency trading or whatever.

(Peter at 00:37:38) But, yeah, I think that for technologists in particular, there's this tendency to go for the hammer as opposed to the nail. And I think with a great problem, you know, you can get away with a pretty crappy product if the problem is big enough. And I think that in some sense, that's where a lot of quick companies start. Expense tracking, for example. I don't think Expensify is the slickest product I've ever used, but it's way better than anything I had to use back at Stanford with, you know, whatever Oracle or SAP software people had and just a huge pain to get reimbursed and so on. And, you know, is that great tech? I think it's certainly improved over the years, but it's ultimately a problem worth solving. And I think, you know, as a technologist and as someone with this kind of engineering background like you, I always struggle with this problem, which is, "How do I apply my unique advantage to solve these problems? And what are problems that are real problems, but ones in which I can materially make that impact?" Where I know there are certain problems I'd love to work on, some of the stuff going on in genomics. It's super interesting. Right? There's just amazing what people can do with high-throughput DNA sequencing and so on. But also I realized a lot of the problems in terms of mining, as I understand from a naive perspective, when I talk to folks in the med school, you know, the problems have to do more with, "We don't have enough genome sequences." And once we do have enough genome sequences, we could go figure out what are the things that correlate with cancer, and then we go and solve these problems. And in the meantime, it's like, "Well, I have one hammer that I know really well, which is making things fast." So let me find things where the problem has to do with speed or comprehensiveness or so on. But there's a real problem there, and I can make that difference. And that's what I think is—when you talk about what how did I learn the business side? I think it really comes down to what you talked about, which is just identifying the problem really well. And then rather than having an experienced business operator sitting at my side and saying, "Hey. We need to do, you know, X, Y, or Z," just having kind of the self-awareness to keep asking at every stage and being kind of intellectually honest, "Is this a real pain point for someone? And if it's not, then what other pain points can we solve? And is this in the narrowly defined wedge of where we want to live in the universe of all things data or not?" And if it's not, then just having the discipline to say no.

(Joel Beasley at 00:39:48) So is Ben a part of the company directly or just like an advisor? Or—

(Peter at 00:39:53) Yes. So Ben Horowitz led our Series A, and he's on the board. And my goal for that was to, again, be intellectually honest about where I was coming from as a CEO where, you know, I had scaled an org, maybe fifteen people in my lab at Stanford, but I had never built a company, had worked at companies. Never built a company from scratch. And Ben's kind of the one really experienced, let's say, top five, ten, you know, Midas List investor who's actually built and scaled a company on his own. And I figured from the earliest days, I could work with someone like that who had been in the hot seat of running a company and building it out and dealing with the hard things that come up and seeing what success and failure looks like. That would be an unfair advantage to be able to partner with them at the earliest date. You know? So, like, literally back in May 2018, SISU was me and Ben. And he's been super helpful along the way. He's a super busy guy. Obviously, picky about where he spends his time. But he's just been—it's really great because everything from, "Hey. How should I think about this? Teams, engineering is growing really fast. How should we think about structuring our teams and making sure people are balancing velocity with feeling like they get to continue to grow? And how do you manage an environment where people can continue to grow their technical skills and they're shipping stuff?" all the way to, "Hey. There's a big fundraise coming up. How do we think about this?" So we're like, "Hey. Here's our revenue numbers. How do these look to you? Where am I missing? What's my blind spot?" So it's just helpful to have someone who's done it. And then also from—I think one of the things Ben says in his book is really true. One of the hardest parts of, I found, of doing the company is it's an emotional thing as well.

(Peter at 00:41:34) Keeping yourself in check where you're like, okay, how do I stay long-term greedy? Keeping your sights on what the important things are in the long term and not getting too hung up over whatever's going on in the short term, both good and bad, and kind of just charting that course while also realizing that it's a lot bigger than just you. It's about the team and the people who are along for the ride and are ultimately the ones who are moving the thing forward way more than yourself.

(Joel Beasley at 00:42:02) Yeah. I like that long-term concept because at first, you're focused on cash. Cash, you have to be—stay alive, and so you're just doing whatever you can do to survive. It's like trying not to drown. Right?

(Peter at 00:42:14) You're just

(Joel Beasley at 00:42:15) kind of going crazy. But then the moment you get over that and you're like, okay, I have a business that's long term going to provide me, at a minimum, a steady paycheck so I can live and exist and continue to attempt new tries at growing this thing. Right? And so you get to that point.

(Joel Beasley at 00:42:28) And all of a sudden, who you're spending your time with, the style of people and how they think becomes way more important because you're like, this is going to take a long time. I'm going to be in this for ten years, and I want to be surrounded every day by these people, and I want to live in this type of culture. And all of a sudden, those things become very important.

(Peter at 00:42:46) I think it's huge. Yeah. I mean, one of the things we talk about a lot at the company is the idea that, you know, if you stack rank these things, it's the people are the most important part of the company. Right? It's great people.

(Peter at 00:42:57) You empower them. You give them latitude and an environment where they can be creative and inspired and run as fast as they want to run and continue to grow. People are the most important part of this. The people ultimately will build the right product for the market. And that's the process just appears. You know? It's the collaborative hard work of so many different people going into this from different disciplines, and I love working with people who are—it's so funny. I feel like I've learned more in the last four years or, sorry, time flies—two years of the company than I have in the last, I don't know, five years of my career, even in academia, just because I've learned so much from the people around me about what actually goes into building a product and building the team and so on.

(Peter at 00:43:38) But it's people first, then the product, and then the profits follow from there. Because I think you could probably say people incorporates what you said earlier. It's people, problem, product, profits. Right? Because if you get the people right and you find the right problem and you build the right product, then the profits will come from there.

(Peter at 00:43:53) And the beautiful thing about—I love about AWS, for example—is it is truly this utility. We were able to spin up this business in two years. We've never bought a server. Right? We can change the unit economics many different ways based on what instance types we get and how we process and how we write our code and so on.

(Peter at 00:44:11) Such that there's so many different ways to scale up a business model in a SaaS-based business today. You see the investors kind of flocking back over to SaaS after realizing subsidizing brick-and-mortar goods is a very hard way to actually achieve escape velocity in retail and transportation and all these companies. But in a SaaS environment, you can figure out the profits a bunch of different ways, and there's a lot of innovation to be had on the business model front as well. So it really is get the best people, make sure you're solving the right problem, then build a product that solves that problem, then kind of go. And I know it's overly simplified, and I'm talking from a position of a lot of privilege and have had a lot of great advisers along the way, but I do think that at least in its purest sense, although Silicon Valley is not a perfect meritocracy compared to many other systems I've been a part of, it's very true in that regard that you can get a smart, dedicated, creative group of people together and build something really, really awesome here in an unbelievable short amount of time and figure out how to build a business around that that pays people—not only puts food on the table, but changes technology.

(Joel Beasley at 00:45:15) I love it. My friend, we did it. It is 2:00. You had a hard stop at two, so I don't want to—I'm just trying to help keep you on time. I'm not trying to rush you off.

(Peter at 00:45:24) This is great. Yeah. I'm sorry. I got back-to-back on this. We were doing this thing for GDC, actually, which is kind of cool.

(Joel Beasley at 00:45:32) Oh, nice.

(Peter at 00:45:33) Which is—I've not done stuff with gaming, but that's another fun—that's the fun part of being in this thing too. It's, you know, anyone who has a direct consumer presence has data, and you can work with game companies, which is awesome. But no. I really enjoyed the conversation, and I appreciate you having me on. This is a really fun conversation. So I'm excited to see how it all edits out and so on. Yeah. Thanks for having me on. And look, sounds like things are going really well with the Stripe credit and growth. So, you know, if I can be helpful at all, let me know. But I'm just super excited and appreciate you having me on. It's a really awesome show. You've got a really impressive group of people who've been on. I was looking at some of the old episodes and I'm kind of honored to be included in the bunch. So thank you so much.

(Joel Beasley at 00:46:12) Awesome. Talk to you soon.

(Peter at 00:46:12) Talk to you soon. Yeah. Thanks, bud.

(Joel Beasley at 00:46:23) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.