#93 - Peter Reinhardt

Hey, how's it going? This is Greg Cannon, and you're listening to Y Combinators Podcast. Today's episode is with Peter Reinhart, Peter's co-founder and CEO of Segment. Segment helps companies capture data from every customer touchpoint and send it to the tools where it can be used most effectively.

They are part of the YC Summer 2011 batch. You can find Peter on Twitter at RyanPK. All right, here we go. The average person probably doesn't know what Segment is, so could you explain?

For sure. So Segment helps companies give their customers a better customer experience, and we do that by helping them organize all their internal data about all their interactions with the customer. So, for example, if you go to the bank, they interact with you at the ATM, at the teller, via a phone call center, they have a web app, a mobile app, they send you emails, they're interacting with you across this huge surface area, and they need to be able to coordinate that interaction. They need to know that if you encountered an error on the ATM, the teller needs to be able to say, like, I'm so sorry, you encountered an error.

I'd love to be able to help you. And so what we do is we help sort of bridge that gap of having a single record of all those interactions with your customer. Because previously, companies would build all this in-house, or not at all, maybe. Yeah, there's sort of two worlds.

One is they would build it all in-house, exactly, and there'd be a rat's nest of data pipelines from one place to another. So the engineering team would spend all their time building these data pipelines rather than actually building things for the customer. That's one world. The other world is one where it really used to be a one-on-one relationship with a bank branch manager, for example, and they might keep the information in a CRM, right?

But if you are a similar would-be an optometrist, right? You go in, they have your passwords, et cetera, but now the world is moving much more to a Warby Parker kind of world where you're not interacting with a person. So a CRM doesn't even make sense. It's not the right technology for understanding what interactions are happening with the customer, and instead, it's all these different digital channels.

So that's where we come in. And your first customers, were they large-scale companies like banks, or who did you get in the beginning? At the very beginning, we actually launched an open-source library on Hacker News, and it took off there, blew up basically overnight. So to be fair, it was kind of like the long road.

Oh, yeah, no, no. It's not the year and a half of dark times. Yeah, yeah, we shouldn't totally go over that. But, okay, yeah.

So anyway, you blew up overnight on H&M. Once it went live on H&M, it blew up overnight. And so our first customers were really focusing on Hacker News. It was basically small companies, for the most part, founders were looking for better ways to instrument their web applications and mobile apps with this sort of analytics tracking.

And so the initial growth was, that was just completely unpaid customers, right? So they're just using open-source, whatever you put up on GitHub, right? So the strange thing about the open-source library, which is sort of this data router, so you put in one piece of data, customer did X, and then we turn around, transform it, and fan it out to all different places downstream. And what's funny about the library is, if you want to turn on a new tool, if you want to send the data to a new place, you need to recompile the library and redeploy it to your website.

So it doesn't actually, the open-source library doesn't quite actually solve the problem, which is really a marketer or a product manager wants to use a new tool. So what happens is, you really want to use the hosted version. So almost no one actually uses the open-source version. Was that by design?

No, no, it was completely accidental. Really? There's just no way to make a good open-source product around it. That's crazy.

So what did you apply to YC with? We actually applied as a classroom lecture tool. So the idea was to give students this button to push to say, I'm confused, and the professor would get this graph over time of how confused the students were. We thought it was a really cool idea.

We were college students at the time, and we had a bunch of professors who were excited about it at MIT and elsewhere. I'll never forget, in our YC interview, we were pitching this, and PG was getting pretty excited. And then he turns to Professor Miller from MIT, who we had talked to, and had given us the original idea for it, and says, hey, would you use this? And Professor Miller says, no, probably not.

And we were like, what the hell? And we just rolled with the punches and said, yeah, well, you know, we talked to like 20 other professors, and they were all excited about it. Oh, man, but then you went through YC with this, right? Yeah, we went through the whole YC with this idea, built it out, hundreds of thousands of lines of code, super complicated class on electrical product, had a presentation view, and people could ask questions.

It was very complicated. We were actually going to raise money at Demo Day with this idea about 600K. Finally, we deployed it in the classroom as the fall semester got started after Demo Day. It was just a total disaster.

All students had my laptops, and then I went straight to Facebook. So the way we discovered this is we were standing in the back of the classroom, just counting laptop screens. So we'd be looking over the shoulders of the students, you know, one, two, three. And we discovered at the beginning of the class about 60% of the students were on Facebook, and by the end, about 80% were on Facebook.

In other words, they were supposed to be using your desktop app the whole time. That's right. At the beginning of the class, they'd been like, can everyone please get out their laptops? We're going to use this new one.

All of a sudden, all these students are distracted by Facebook. So we'd accidentally sort of put in an attention bomb, if you want. Yeah, and you hadn't brought on any users during what? So you were in the summer 2011 batch.

That's right, summer 2011. And you weren't testing during the batch? We tried testing, but there's not many classrooms that are in session during the summer. Oh, okay.

The school year starts in September. So we had data tested in a few summer computer science classes at Stanford and Berkeley. Yeah. But there was always technical difficulties and other things to start from getting a real sense of what was happening.

Oftentimes, it was pretty YOLO. I don't know. We didn't really get tests rolling until the fall. Okay.

And so what was the come-to-Jesus moment where you realized you had to change the product? Standing in the back of a BU classroom, an anthropology class. And I remember arriving at the 60% and the 80%. And we went up and apologized to the professor.

And so at that point, you're just like, okay, we've got to kind of shut this down or figure out what to do with the money. That's right. We had just gotten wires for these checks for literally a week before. So we called back all the investors.

And we're like, well, it turns out this is a terrible idea. So what do you want us to do with the money? And almost all of them said, well, we invested for the team. So go find something else.

So we decided, hey, let's build an analytics tool. Let's build a better web analytics, mobile app analytics tool to compete with Mixpanel and Google Analytics. The idea was to give really advanced segmentation because we also wanted to understand how some computer science classrooms that MIT were using differently than anthropology classes at BU, etc. And we couldn't do that analysis in the tools we had.

So that was the idea was to build an analytics tool. We spent about a year building the infrastructure necessary to do that analytics. And really, we're not succeeding in getting any customers during that time frame. So you had, I mean, did you have a whole onboarding process?

Was it like a landing page? What did it look like? Oh, yeah. We had a landing page.

I was going on a little sales trip. So I was meeting with people. Oh, so you were trying. Oh, yeah.

Yeah, we were trying. But it was not going well. Basically, what would happen is people would say, well, I already have this other analytics tool installed. So like, I'm just not that interested.

You definitely, at the time, you were not 10x better than Google. No, no. Yeah. Were you at parity?

We were at parity in certain dimensions. And we were exceeded in other dimensions, but they just weren't the dimensions that mattered, apparently. Right, okay. So you just kind of like blow up overnight with our news.

And that like, this is, well, so positive. This is just the analytics tool, which we realized in December 2012 was failed. So we're like well over a year into the analytics tool. We're now trying to ideas.

Both have failed. Neither is clearly going to work at all. So we realized that we're screwing up. So we decided to have all stars with YC again.

We come back, walk around a little cold attack by YC with BG. We started to come and see a stop and say, just to be clear, you spent half a million dollars and you're nothing to show for it. So I'm going to be a gulping moment. Yeah, yeah, I guess that's true.

And it was a good sort of come to Jesus moment, though. And you got to pause there and then rewind all the way back to the first week of YC. And it was in that first week that we'd been like, oh, which tools on our cost of metric tool. So we Googled analytics.

We found Google analytics, mixed analytics, mixed analytics. And we're looking at them, we're like, we don't know which one of these things we should use. They're kind of all similar, but Google analytics is a little more marketing-y, because metrics is a little more revenue-y, mixed analytics is a little more product-y in terms of the sorts of insights they can give you. And at the end of the day, they all collect the same data.

They all collect basically who is the customer and what are they doing. So we decided to write this little tiny abstraction that could send data to all three. It was like 50 lines of code among the hundreds of thousands for this class of metric tool. And then we decided we'll just send data to all three, we'll look at all the tools, and we'll just pick the one that we need.

So it'll give us a lot of optionality basically for free. And then we forgot about it for like four months. Four months later, we clean it up a little bit more. Four months later, it cleans up a little bit more.

As I mentioned, now we're struggling, at that point we're struggling with this question of, well, I already have mixed panel installed, so I don't really want to use your analytics tool. So my co-founder, Ilya, has this idea. It's like, remember that little library you read that sort of abstracted away the differences between these tools and what to send data to all three? What if we added ourselves as the fourth service that we can send data to?

And then every time someone has that objection, we hit them back to the open source library that they can use to send to us and them. That seems like a clever growth hack that gets us around this problem. So we did that, cleaned it up, open sourced it, and people started replying, like, oh, this library's great, we'd love to use it. A couple weeks later, we'd follow up and be like, hey, well, we saw you're using the open source library, but all you have to do is copy-paste our API key so that you can use our analytics tool.

Could you just copy-paste the API key? And they're like, eh. So we started just feeling like there's some traction on this little routing library, which is maybe up to, like, 25 stars on GitHub or something like that, like, not much. But some people are issuing pull requests, and it's the first time we've ever felt a poll.

We weren't just pushing a poll gap hill. It's a little different, but subtle. We had this conversation with Paul Graham. The next day, we sat down.

It was our second time with this. We're like, okay, we have 100K left in the bank. What's our final shot? And I go find Ian.

It's like, you know what? I think there's a big business behind analytics.js, which is this routing library. Like, that is literally the worst idea I've ever heard. Like, it's 500 lines of code.

It's 500 lines of code, and it's already open source. I have no idea how you build a business around that. And so we fought about it all day long. It was four of us.

I was the most skeptical, I think. It was literally brutal fighting. I went home, and I was trying to figure out how to kill the idea. So I wake half the night, finally figured it out.

I came in the next day. I was like, okay, guys, here's what we're going to do. We're going to build a beautiful landing page. We're really going to pitch the value of this analytics.js open source library.

And it'll have a sign-up form at the bottom so that we can get people to start expressing interest. We'll put it on Hacker News, and we'll see what happens. I don't think it'll just totally kill it. Right.

Because nothing does well on Hacker News, right? So we build a landing page for it on Hacker News, and this is when we have this year and half in the making, overnight explosion. Yeah. And that kind of segues into your whole start of school talk, right?

About, like, basically real product market fit. Yep. And up to that point in your life, had you launched anything where the market, I mean, this is a market-recent quote, because he kind of coined the term, it pulls it out of you, right? That's right.

I think that's an app description. I think that's an app description. I had never experienced it before. And it feels very much like losing control, right?

Like, previously, you're, like, building a thing, and you're building a thing, and you're pushing it out, and all of a sudden, you, like, put a thing out there, and people start running away with it and using it in ways that you didn't necessarily expect. And you're sort of like, whoa, whoa, whoa, whoa, it's just amazing. Like, stop, stop. Like, we need to fix these other things, because otherwise, it's like this feeling of losing control, and almost, like, the market is dictating to you now what the rules of the road are and what needs to get built.

So would you differentiate that from overwhelming demand for one particular feature, versus, like, we're just going to take this and use it however we want, but there's a ton of demand there? Would you separate those two things? Not really. I think that people always want more features.

But the thing that flipped was people would previously tell us they wanted a feature, but not use it. Whereas now people were using it, and they wouldn't want a second feature. And it's a super important distinction. I think a lot of founders get caught in this sort of, like, all the desk viral user feedback, where they keep going and showing someone their product and asking them for feedback.

They give them, you know, some feedback about how they can make it better, but they don't use it. And then they bring it back with those fixes, and they ask, if this is better, and it's just like the desk viral, or it never gets anywhere. But once someone starts using it, they'll have more requests, and that just means they're going to pay you more every time. Right, yeah, I like how you put it in the lecture, where you're basically like, if you have to ask yourself, it's not product market fit.

Yeah, you really can't miss it. Yeah, and this was now six years ago? Five, six years ago? Almost six years ago, yeah.

Right, and you're still feeling the same way? Yeah, and since then we've had a few more secondary product market fit moments. Like what? About two years in, we discovered that all of our most valuable customers were sending their data to an F3 bucket, which is basically they're keeping log files of the raw data, which is a little weird, because typically people are using the data for an analytics tool, an email marketing tool, and a CRM, and a help desk, like, this is where a business person is driving value.

Log files is a little different, it's a little weird. It's unclear what the use case is. So we went on this sales trip to New York, myself and our first salesperson, Raph, and we met with five customers that were using this S3 bucket, and we just asked them, like, oh, what are you doing with the S3 bucket? The first customer was like, well, you know, we have a data engineering team that's taking the data out of the bucket and converting it into CSV files, and they're uploading it to our data warehouse, which is a redshift cluster.

So basically they're using it as the initial input into an ETL pipeline. I'm like, oh, that's interesting, but, yeah. But the next meeting, the second customer was like, well, we have a data engineering team who's taking the data out of S3, converting it to S3, and we're like, okay, drop it, and that's interesting. And then the third, fourth, and fifth ones all said exactly the same thing, and that was the point at which I started becoming conspiracy theorists.

It seemed like some pre-meeting had happened, but they were all doing exactly the same thing, so it was really obvious we just built a way to load it directly from segment into a redshift cluster. And that was a huge thing. Like, you really thought that it was product market fit again. Yeah, it was very explosive.

So we'd grown revenue from zero to two and a half million in the first year, and then we launched this redshift connector, and the next year went from two and a half to ten. But people weren't asking you for that. That's right. It was one step too far for them to realize that we could do it easily.

Their mentality, I think, was that, oh, segment is a way that I integrate marketing tools, and so a data warehouse is a marketing tool. It's a BI tool. Surely segment can integrate that. It just didn't click.

So I had to go find by asking. Interesting. And your growth, how has that happened? Has it come through developers?

Our good market model is primarily through engineers, yeah. We talk a lot about sort of the way that we've built our infrastructure over time. We obviously process a lot of data, so there's a lot of interesting infrastructure problems. I think now we're processing hundreds of thousands of user actions per second.

So there's a lot of data going through there. We read about that. That's generally interesting. So it's the Hacker News and Engineering crowd.

And, yeah, typically an engineer is the one that brings us in. Sometimes a really technical product manager, but it's someone who's like, yeah, this is going to solve this weird rat's nest data pipeline problem that I've got. And how much of it is open source, though? A good portion of it is open source, but most of the value that we deliver is actually by running the hosted version.

Right, because at the end of the day, it's not just a developer. Like, you're saving the developers' time, but it's these business people that really need it. Yeah, and most of the complexity is hidden away in how you actually operate and scale a data pipeline that is processing the data. So, you know, our JavaScript libraries are open source.

Okay, and so right before you guys launched on HN, or this, like, small, tiny micro launch, whatever it might be, were there other avenues that you were considering pursuing? Like, in that debate, in the day before, were you thinking about other stuff? I think the debate was whether to build out the full product and then test the product market fit by trying to sell it to people versus the super, super lightweight MVP landing page that we would put on Hacker News to see if there was interest in the concept. And what drove us towards the super, super lightweight test was actually the fact that there was a skeptical divide among the founders.

And since the founders couldn't agree, the only way to answer the question was to go to customers ASAP and get an answer. Okay, it's tough. Like, the launching early thing is always a challenge because I think there have been instances where people are like, eh, we'll just launch this early, but because they're, like, 10% off of what that product ought to be or they're not very good at communicating it, they never really get the feedback that they need, right? Like, how do you kind of balance that out?

Like, oh, this is kind of, like, fully formed enough or we're communicating it clearly enough that we can launch it. Like, how do you determine that? Usually that test is so cheap to run that it's worth running, even if you decide that it was inconclusive and you should go a step deeper. But I also think that the way you frame it is actually an excuse that a lot of founders use for not doing the cheap early test, actually, in fact, they should.

Yeah, I get the same questions, like, almost every single podcast, and I'm trying to be a little bit of a devil's advocate here, but, yeah, these are kind of, like, strongman arguments. Yeah, I think the really big product market fit moments for every company are pretty unmistakable. Like, the Dropbox founders have called this out of my mind. I really don't think you can mistake it.

It really happens in a way that you lose control. It's very obvious. Every metric goes haywire. People are talking about it a lot.

It's not mistakable. Or, like, oh, you know, this person said that it looked valuable and it was really exciting, and blah, blah, blah, blah. If they're not using it, like, it's not there. Yeah, okay.

Okay, so there's a question from Twitter. It's clear that a bunch of people have watched your lecture. So this is the first one from Evan Farrell. He asked, you mentioned in the Startup School lecture that you had to pivot to analytics.js to find product market fit.

Is it possible to purely iterate on something like that to find product market fit, or should it be clear from the outset if a new idea is something people want? There's two versions of this. I would say the Airbnb version of Product Market Fit is much more iterative. They struggled for years and years and made slight iterations and iterations and finally caught on and obviously they're runaway success.

My feeling is that that's extremely rare and that, again, this is a really dangerous place to be because you can stay in this iterative mode for years and it is unlikely that the iterations are going to get you to a good place. So I remember very clearly early on being really inspired by the Airbnb story and it being a logical reason why we should keep plugging away at a bad idea. And I think we have used the Airbnb story to just keep stringing ourselves along on a bad idea. So I would be very, very careful of following the Airbnb example.

I don't know many other companies that hit Product Market Fit that way. Right, and so how long do you give an idea at this point? I actually don't think that it's quite the right frame to think about it in terms of how long to give an idea. I think what you want is someone, either yourself or someone else on the founding team who's a skeptic.

So someone who is going to have enough context with whatever the specific idea is and whatever the regime or market you're in. Someone who's skeptical who will question and push for the fastest reasonable test. So in other words, if you have an optimist and a skeptic and they both agree on what a valid test is, then I think you actually will know what a good test. But if you have three optimists in the room who all agree on what a good test is, I don't believe that that's a good test.

They don't have skeptics, but yeah. Have you recruited skeptics or did you just kind of luck into that? I think we lucked into it the first time. I think we have some folks on the team at Segment, some early folks who are skeptics, actually, about future product market fit moments that we've had.

I think it's been enormously helpful. That's really interesting. How do you test for that in an interview scenario? We didn't test for it.

We just got lucky again. Yeah, okay, so not even just with co-founders, just with early employees as well. That's right. How interesting.

How hurtful can it be if someone is like, well, I really think you haven't thought this through. There's these three things that you should really test ASAP because I don't really believe that you have product market fit here. Right. That's what you want.

You want someone who's going to be pushing it and you're like, well, yeah, how would we? And then who's willing to collaborate with you on how you should reasonably test whether those things are the case. So the sorts of tests that we have run, for example, with this mindset recently, even in the past year, were should we switch from a technical buyer to a marketing buyer? Unclear how to test that.

Well, so this early skeptic, who's amazing, she was like, well, I'm just going to go to a conference with marketers and we're pitching a bunch of marketers just flew to Florida and pitched a bunch of marketers. Came back, she's like, nope, not a good idea. And I ran my own set of tests. So the hacky ways to test these things are very valuable and it comes from having skeptics who are in different perspectives with people wanting to test those things.

Okay. And so I imagine these tests from skeptics occur on a maybe daily, but probably like at least a monthly basis, right, in terms of you guys working on your product. Yeah, I'd say maybe more on like a per-idea basis. Like if we're going to launch a new product, then it's really helpful to have a skeptical perspective of like here's why this might not actually be the idea.

And do you rely more heavily on data or actual customer interaction? In the early product development process, it's all qualitative. It's all talking with customers. Okay.

Because this is the thing that bugs me more is like when people are just like putting up landing pages left and right and like thinking that they can like kind of, I forget what it's, I will call it. If you have the conversation in the right way, you'll learn a thousand times more from that conversation than you will from putting up a landing page. And I think ultimately we learned a lot more from talking to our customers after the Hacker News landing page than we did the landing page itself. Yeah, totally.

So what are your tactics when you're talking to customers? Yeah, I'd say the main thing is most founders are not familiar with how a sales process is actually run. And you basically want to run a sales process. So the sort of typical founder motion with running a sales process is they come in and they say, okay, we'll give you a demo and they're just like really shiny, polished pitch.

And then the customer decides at the end of that pitch whether they're interested or not. That's not actually how good sales works at all. The way good sales works is you do qualification up front. The segment is one called MEDIC, M-E-D-D-I-C.

It's literally just a list of sales qualification criteria. And this is what sales reps do. If the sales reps comes back and they're like, we're going to close this deal, the sales manager says, okay, well, let's go through metrics. What are the metrics by which this company is going to judge whether or not the product works for them?

If the sales reps can't answer, metrics, economic buyer, decision maker, decision process, the identified pain, and doesn't have a champion, they can't have all six of those things. There's no deal. And so when you're searching for product market fit, you can just go through all those things by asking the customer questions and you can grade whether or not you're actually going to build a product that will solve the problem. Right.

Well, this is, it kind of ties into this like skeptic versus like optimist idea, right? You have someone who's like a champion of the product. And in many ways, I mean, maybe this is like the optimist who just sees the world and they see the future and it looks awesome. It's amazing.

But you need that skeptic who sees the world as it really is. That's right. And a sales qualification criteria is a way of almost putting the skeptic out as a structured process that enforces some level of skepticism. Yeah.

I think it's so dangerous when you're the optimist. Because I fall into this camp for the most part. Like when you get good at sales, you can kind of sell many people on almost anything. But if that product doesn't exist yet, it's very easy to just kind of mold it in the way when you're reading someone.

You're like, oh, I can tell they kind of want it to be like this. So I'm going to kind of go down this path. But then when you actually show them the product and they're like, like you said, they won't even install it. Then you see the world that it really is.

Yep. And that's the thing. And so you guys are just like going on. Are you still having these conversations with people personally?

Sometimes, yeah. For sure. Yeah. Yeah.

Because this is one of the things that like people, I think in large part, because they're influenced by your starters will talk. They have so many questions about it. So Benjamin Liam asked, like, you know, how do you even, how do you find that you have the right messaging around explaining your product? Oh man, this is super hard.

I'm not even the right person to ask about this. I should have done it before in RPP Marketing, Holly, are the two who have really refined our messaging over the years. And we're always trying to refine it. So I don't know how you know that you have the right messaging.

You know that whatever messaging, you can sort of test whether alternate messaging is going to work. And you can do that qualitatively in interviews with customers. You can try explaining it one way and stick their eyes light up. You can try explaining it another way and sort of see what resonates.

I think a really talented early salesperson will also have this sort of pattern in their habit of how they pitch that they'll always be testing different ways of explaining the product. That's definitely true for the first salesperson we hired. He was fabulous. Just like constantly experimenting with different ways of doing it.

You never know if you have the best messaging, but you are constantly searching and testing for different ways of explaining it. Okay. But again, if it's about really finding a good product market fit, do you think that these minor changes in how you communicate something will make a difference? I don't think minor changes will make a difference.

Once you have product market fit, then you can optimize the messaging. Okay. So then we should talk about idea generation because that seems more important than these minor deviations. Yep.

Where do you begin? Yeah. I think the best ideas that we've had come... So there's a big difference between the first idea and the sort of follow-on ideas.

And the reason... So the first idea being like the core product and then the individual features. That's right. And not just individual features.

You might have entirely new products that stick them along. But those are much easier, right? The problem with the first product and product market fit is that you can move the product and you can move the market because it's fit between these two things. And so it's unclear and they move in some crazy multidimensional space.

And so the issue is that to get them to both match up, you can always move either one. And in different conversations, in one conversation you might shift the product and in a different conversation you might realize you need to shift the market. So that's super tricky. I don't think there's a repeatable way to do that.

I think you just have to go very, very deep into a particular market and understand the problems that people have in that market. So do you have a particular process for idea generation? Or you just get into something and you're like, man, it's super deep. For that first idea, you just have to go super deep.

You just have to understand the market and the ecosystem and the customers upside down backwards better than they do themselves. Okay. So if you were booted from segment today, do you know where you'd start? You'd have to start with something that was interesting to you personally and then you'd go dig in a deep direction.

I think that it becomes more repeatable when you are finding a second product. So at that point, you've mostly locked the market side, right? Because you already have a buyer, you already have a good market notion, you already have an area of interest, which for us is data pipelines and data infrastructure, customer data infrastructure. Then it's much easier because you know exactly who you need to go to and you know roughly the type of questions that you need to ask.

And then you can run a process which is a much deeper x-ray of the customer than you might be comfortable with. At least, it was much deeper than I was comfortable with when we first got started. As an example, we recently were testing product market for a product that we announced at our user conference in September. And that's now in beta and it's doing really well.

But the initial way that we were sort of testing fit there, we would go in and say, oh, hey, do you have a problem with data cleanliness? And the person would be like, oh, yeah, yeah, totally. That's one of our big problems. Very cool, cool, cool.

Data cleanliness. And we might ask two or three more questions, but that was sort of the depth. But the actual level of question needs to be like, okay, well, what do you mean, how do you currently invest in data cleanliness at all? They're like, oh, well, yeah, we actually, you know, we have a team of like six people who do data QA all the time.

I'm like, oh, well, those data QA people, like, where are they based? Are they based in LA? Oh, interesting. So they have like real salaries and not just like overseas like real US salaries.

Like, yeah, yeah, okay, so what, like 80K a year, 100K a year? Yeah, that's about right. It's like, okay, so you're spending, you know, like 750K a year for this data QA team. And like, tell me more about their process.

Like, what are they QAing exactly? Oh, well, they're clicking this button in the app. And they're like, well, which button? And then are they, like, what do they do when they find a bug?

And so we would ask like literally 45 minutes of questions like this. And now we actually understand their problem. We understand what they're doing. We understand where the cost centers are.

We understand how they're thinking. And then we're like, oh, well, what if we did a product that did X? Yeah. Which is exactly what they just explained to us for the previous 45 minutes.

And they're like, that would be amazing. So they're like, okay, now we, now this is, that was both sales qualification and discovery. Yeah. Which is a standard sales process, but now it's being used for product development.

And that's such a good learning because people aren't going to tell you no. Like, I think a lot of people just get scared to like ask these questions. And the customers will tell you. Yeah.

Especially if you, if you take the champion part of Medic, the last one, the C, and you just start by asking like, what's your vision for X thing that you do? And they'll tell you like, oh, we, our mission is similar. That's why you got the meeting in the first place. That person is instantly aligned with you.

They'll talk for 45 minutes about their problems before you have to tell them anything. Yeah. I think that's one of the things that most people don't realize. Like many of the best sales people don't talk that much.

The best sales people at segment ask why, to the point of uncomfortableness from everyone else on the team, including myself. Yeah. Interesting. Yeah.

I wonder what the correlation is between sales and skepticism. It's probably pretty high. People who are questioning things and they can see the angle. Yep.

All right. Next question. So Danny Prohl, first of all, he says, go Peter. And his question is about culture.

So he says, what values and standards do you have in place for your team at segment? And how do you actively build that culture into your company? Yes. We have four values at segment that we're quite dedicated to.

The first is karma, which is we want to have a positive impact on the world. And that manifests itself in a bunch of ways. One of those ways is we really care about the customer having, sort of getting value out of our entire process. So you'll notice that all our marketing materials, for example, are often like highly educational.

We have a really high bar for what an educational piece of educational material looks like. Even in the sales process, we want to be helpful. If we're not the right fit, we'll tell you and sort of like refer you to the right places. Separately, we really care about doing the right thing by the end user.

And that's from like a data privacy perspective. So we're very interested in helping companies understand all of their own first-party data. So all of their interactions with their own customers within their four walls. We're super uninterested in helping companies data broker data between different companies.

We call it data gossip. It's gross. We don't want anything to do with it. There are plenty of other companies out there that do stuff like that.

It's going to go away and die eventually. So that's karma. We care a lot about that. The second one is tribe, which is we're all there to support each other, we're all there to accomplish the same thing.

And so what we expect is that and what we value is that people really support each other both when they may be struggling with something, but also giving them credit. So really try to reward folks who are willing to go the aftermath of the credit when it may be hard. It could be giving credit across teams or at several levels or whatever. That's really something we value.

The third is drive. We like to get shit done. We value people who are getting shit done. And the fourth is focus, which is not just sort of the ability to sit down and get stuff done or power through something, but actually thinking carefully about prioritization.

We've done a lot of research around how to make the office an environment where you can actually focus. So we've written about sort of sound decibel levels around the office and how we've mitigated That's pretty well. That piece did pretty well, right? Yeah, and it was a surprising result for us to discover the different parts of the office had very different sound levels that were not correlated with people talking, but were just correlated with the sort of acoustic shape of the office.

And so just moving people around to different places helped a lot depending on how much noise they were willing to tolerate and sort of needed in their role. So anyway, those are the four values. They are literally the things we value. And so we push them into all the places where you would expect what you value to have an impact.

So it's who gets highlighted at all hands. We have a Citrus Prize, which is someone who's living all the values. Promotions, hiring. We have a strict interview.

In the hiring process, we have performance reviews. We have a strict interview. Sorry, we have a culture interview where we literally have these four values and specific ways that we're going to test for them. When we run performance reviews, the performance review is literally four values.

How are you talking about? This is what we value and therefore it's what we test and measure by. And I think ultimately it's that cycle of giving feedback and measure by that is what drives culture to stick. And has this been something that came naturally to you, like building culture?

Or do you have to learn it? I don't think so. I think we learned it. We got to about 25 people before we realized there was something that we should write down.

And we went off-site, four founders on off-site, and we tried to synthesize the values out of what it was that we really liked that was already happening and what it was that we didn't like that we had seen already happening. And not just on the team, but amongst ourselves, too. Like, what were we not proud of that we had done and what were we proud of that we had? And that ultimately was what got synthesized into those four values.

And so those were just interactions with other people or like literally product building? No, interactions with other people and interactions with partners and customers and things that we were proud of that we wanted to see more of. Right on. So next question.

Ashman Doak asks, how has GDPR impacted segments business model? So GDPR, for those who don't know, is a new EU regulation, which basically gives end users a lot of rights about the data that's collected about them. And first off, I think it's an awesome regulation, both as a consumer, but also wearing a segment hat. It's interesting in that it impacts the entire globe, because if you are storing data about an EU citizen, it doesn't matter what jurisdiction you run your company in, you're so responsible to do that for an EU citizen.

The biggest impact broadly on the overall ecosystem is it really negatively impacts third-party data and third-party data brokers, because they have no real consent path to the user for sharing and buying and selling the data. Because we help companies purely with their first-party data, it's not like an existential threat to us in any way. And in fact, it's something that we're really sort of aligned with for another reason as well, which is because we're routing the data out to all the different places we're using it. So we're routing it out to an analytics tool, to an email marketing tool, to a data warehouse, to a CRM, to a help desk, to add conversion pixels.

If that user shows up and says, hey, I want you to delete me from your system, well, it's actually like 20 systems for most companies, and we're already plugged into those 20 systems. So it's actually now a feature of Segment that we can go to those 20 systems and delete whatever user is requesting it and clean up that record across all those different systems. So for us, GDPR, one is aligned with our values philosophically. Two is actually an exciting feature and a sort of requirement that we can support and a sort of value that we can provide to our customers.

So we're huge fans. Nice. That was a perfect answer. But people can stress out about it.

My friend makes instant paper, and they have a big issue with it. It's a big problem publishing where they're relying on their part of the data. Yeah, especially these little tiny products that are parts of really big companies, and they didn't necessarily know, and yeah, not everywhere. Cool.

All right, so next question. Andrew Pakul asks, any advice that you have on asking for more money than you're comfortable asking for? This is part of your start of school lecture, where I guess one of your sales reps was forcing you to ask for more? A lot more?

Yeah, we had a sales advisor who was, well, I got back a little bit. We were initially selling. our product for $10 a month and $120 a year and we brought on a sales advisor and his first advice was, well, you have to ask for $120,000 a year. I was like, that's $1,000, that's crazy.

So we're going to the first sales meeting, me and him, and this is a company called Xamarin, and I've since told him that story, which he found me, but now he's the CEO of Xamarin, and as we're walking up, our sales advisor says, okay, you have to ask for $120,000 in this meeting, and I was like, that's the most ridiculous thing I've ever heard I'm not doing it. And he's like, well, if you don't do it, then I quit as your sales advisor. I was like, all right, I guess I'm asking for $120,000, so we go in, we have this demo and everything, and he says, okay, what's the price? I said, $120,000, and I turned beet red, and he says, we'll have a $12,000 a year.

I said, okay, we'll have a $18,000, and he's like, okay, fine. So from his perspective, he got 85% off, from my perspective, I got $150,000, and it was a successful negotiation. I think it's really hard to offend people with price, at least if you're sitting in the same room or on the phone. It's probably not a good idea to share pricing information via email.

If you do that, then it's really easy for them to hang up, but if you're on a phone call or in person, there's a bit of a social contract, so continue engaging, particularly in person, you can recover. So I would encourage you to not be scared of offending someone with a high price, but maybe just start in person, which is probably the most uncomfortable place to do it, but gives you the most opportunity to recover. Right, and the thing is, if it actually matters for your business, then that's just what it costs. Yeah, you're going to have to, well, and you have no other way of assessing the value.

Yeah, yeah. And in fact, what will happen is when they say, that's crazy, then you say, why? And then they'll explain to you how they actually value the product, and then you say, okay, and then you value it according to their logic, and then you ask for that price. And how long did it take you?

Well, are you charging them $120 now? For sure, yeah, we have customers that get way more value than that. Yeah, exactly. And so how many customers did it take you to reach that six-figure amount?

A dozen, almost. Yeah, so that's amazing. Yeah, cool. Juan Carlos Garza asks, how did YC help to get the segment where it is right now?

YC was super helpful. The most impactful thing early on is just demo day. You're not going to find a bigger concentration of investors who are excited about investing in startups, creates a compelling event, structures the timeline, it's incredibly helpful for a first round of financing that can easily get strong out and waste a lot of your time. Yeah.

That's the first thing. The second thing, really, is the founder network. There's not only a lot of high-profile companies now that you can learn from, or there are companies that are farther ahead that you can learn from now, but there's companies at all stages. There's almost always a group of people in your area, or in your market that you come in from and share from.

So there are tons of little groups that spring up, like a group of enterprise founders that are all between 70 and 100 people in San Francisco, and you can have dinner once every two months. And that becomes an incredible support group, and a way of learning about what's going on. Have you stayed in touch with people from your batch? A few, yeah.

Like Zach, I'm from GoodCat. Yeah, I've heard of these informal founder meetups happening quite a lot. Yeah, it seems to be great. It's a trusted network, but there's no replacement for that.

Yeah, totally. I definitely didn't get that from college. All right, Juan has another question. In the early stage, what's the thin line between ignoring a customer's suggested feature or moving a customer's requested feature to the core of your application or product?

I think what he's trying to ask is basically like, at what point do you say like, hey, this customer is requiring or asking for this feature, and we have to kind of hold the line because we don't want to become a custom dev shop. So should we integrate this or tell them to, you know, find someone else? The best defense against that is having a clear product vision for where your product is going to go long term. And if you have a clear product vision for where it's going long term, it's a very simple question of, is this thing in that picture long term or not?

And if it is in that picture long term, then you can prioritize it to be sooner or later, depending on whether a customer is going to pay for it or not. And if it's not, then it's not. You probably shouldn't build it. Right.

Yeah. I think that's like the infamous customers you don't want scenario where you just have to let them go. Yeah. So I guess the important thing is like, imagine the entire timeline of everything you're ever going to build.

Feel free to move things around. We do this all the time. We move things around based on what customers actually want because it's a reasonable signal of what's actually more important. Yeah.

But I wouldn't add major things or remove major things from it just based on one customer. So since you've done YC, and it's been several years now, what have been the biggest learnings since? Oh my gosh, so many. A huge bucket or a huge area of learning for me is finance.

I mean, I came from an aerospace engineering background and then we were doing software engineering for the first couple of years. And so you just are completely unprepared for the business side of things. So I've learned a tremendous amount about finance as we've raised money and learned to manage business with a P&L and all those things. Not that you should rush into it, but it's a huge area that can be leveraged, I think.

And you would have, if you were to do it again, hired someone earlier on who knew what they were doing on the finance side? I actually think we did a reasonably good job of that. So we hired a part-time CFO around the time they raised their series A. So we were about a million in revenue and we raised $15 million series A.

We had a bookkeeper up until that point, but we were like, I feel like we should have someone point us as to what we should be doing with money and maybe have a plan or a model or something. So that was definitely the right time to hire a part-time CFO and Jeff Arnold was super impactful over the years. What have been the other big, important hires view that have made a huge difference? Well, I've remembered the exact time.

I've heard a whole bunch of people, but advisors maybe is an interesting category. Part-time CFO, I think, is an advocate. We had an HR advisor who's really impactful. We've invested more in HR than most startups of our size and I think that was the right thing.

A lot of startups, like Uber, for example, do not end up with a thing really high prices for this. It's a challenge, right? Because if you go around and start Googling, should I hire CMO? Should I hire CFO?

Should I hire X, Y, and Z? I think you can always find someone strongly advocating for any particular role. And so, yeah, just kind of curious if there were any big turning point moments for you. It was a huge turning point around $10 million in revenue when we hired the first two sort of execs to the team.

Yeah. One was RVP Engineering and the other was RVP People. They were the first people who had previously been managers. And RVP Engineering had managed a team of 150 at Dropbox.

So we went from literally zero management experience aside from what had been picked up along the way, going from zero to 50 people, to having someone who really knew it, or two people who really knew what they were doing. That was hugely impactful. And we should have figured out a way to do that earlier. 50 people in $10 million in revenue or whatever it was was way too late.

Yeah. Cool. If you weren't working on Segment right now, do you have an idea of what you would? Oh, man.

I get to occasionally invest in YC companies. Nice. And there's a lot of cool things happening there. I'm always blown away by the breadth of things that are happening in the batch.

This batch, there's a really exciting company building an in-space rocket engine. And another day was doing industrial inspections by drone. I just can't imagine a world where we continue to have people in harnesses hanging off of wind turbines. I can't imagine that that continues for a long time.

So that seems like an obvious market opportunity. So flying things. Well, I have a background in aerospace engineering. Right on.

Cool, man. So if people want to learn more about Segment, where should they go if they want to learn more about you? Yeah, Segment. Just go to Segment.com or you can tweet at me on Twitter.

I'm at RyanPK, R-E-I-N-P-K. Okay, cool. Yeah, we'll link it up. All right, thanks, man.

Cool, thank you. All right, thanks for listening. So as always, you can find the transcript and video at blog.ycombinator.com. And if you have a second, it would be awesome to give us a rating and review wherever you find your podcast.

See you next time.