Ep. #3, Product-Market Fit with Segment’s Peter Reinhardt

Grant Miller: Peter, welcome.

Peter Reinhardt: Great to be here.

Grant: Cool. Let's dive in. Can you tell us a little bit about your background, and about Segment?

Peter: Sure. I studied aerospace engineering at MIT, and then I left after my junior year to start a software company with two roommates from college. Calvin and our friend Ian from Rhode Island School of Design, we got into Y Combinator in the summer of 2011 and started building a classroom lecture tool.

That idea ended up being bad. We failed at that idea and the first six months, and I'm happy to tell that story. We spent about a year trying to build an analytics tool, which was also a bad idea. About 18 months in, we're failing pretty badly and I decided to make one last shot with the seed funding that we had left. That ended up being Segment.

Grant: This is 18 months in. You've tried a bunch of things, failed a few times at different ideas, and you decided to try this last ditch effort. Talk about that part. Let's dive into there.

Peter: We had raised about $600K and by 18 months in, we had spent $500K of that. We had about $100K left in the bank and we realized that we only had one more shot with that funding. We were looking around for what would be a good idea, "What's something that we have that could be compelling as this last shot?"

There was this little open source library that we had originally built for ourselves at the beginning when we were a classroom lecture tool. And what this little library did is it would take in data points about who a customer was and what they were doing from inside of a web app. Then it would federate and fan that data out to analytics tools, so it would send it to our Google Analytics account, it would send it to our Kissmetrics analytics account and to our Mixpanel analytics account.

We built this little library because we couldn't decide which analytics tool we wanted to use, and there were many different options that all looked similar. Over time we had cleaned up the 50 lines of code and structured it better and so forth, and eventually we had open sourced it and people had started starring it on GitHub and contributing to it.

By the time we were 18 months in it had small traction on GitHub, maybe 25 stars and a few pull requests, but it was the first time that we had ever felt pull with something. People were discovering this thing on their own and starring and using it. We were never pushing it. That was the important signal of product/market fit.

But when my co-founder Ian proposed this as, "This is what we should do with our last shot," I thought, "This is the worst business idea I've ever heard. Because this open source library is already 500 lines of code, and it's already open source. I don't understand. How do we build a business around that even if it's a useful library?"

We fought all day trying to figure out whether or not we should take this as our last idea. I remember going home and racking my brain trying to figure out how to kill the idea. I came in the next day and I was like, "OK guys. Here's what we should do. Let's build a landing page, and it'll be a really beautiful landing page that will pitch the value of this library that does this data routing, and let's put it up on Hacker News. It'll have a little email signup form at the bottom and people can sign up if they're interested in using this thing, and we'll just see what happens."

I was thinking, “This will definitely kill it because nothing ever does well on Hacker News." We did that, built a landing page, put it up. To my great surprise it went straight to the top of Hacker News, got a few hundred upvotes, a few thousand email signups, a few thousand stars on GitHub. People were reaching out to us on LinkedIn demanding access to this beta product that didn't exist, where you would be able to route the data through a SaaS application rather than an open source library. So, that was the birth of the product.

Grant: It didn't even exist when you first launched it, outside of the open source. You didn't have the hosted thing. You just thought, "Let's test the demand."

Peter: That's right. Exactly. Then we hurriedly built the first actual app version over the next five days and launched that.

Grant: Over five days? That's amazing.

Peter: Yeah.

Grant: When you were doing that, it sounds like you didn't have this enterprise software background, you didn't have a lot of experience at Oracle and Red Hat. I'm guessing the other ideas you were considering were consumer apps and things that you might have more experience with. Is that right?

Peter: Yeah, that's right.

We were looking at a "friends-having-fun-together" app, or something like that. We told Paul Graham about this and he's like, "I've heard that idea three times today and it's a terrible idea."

We were mostly consumer ideas.

Grant: Did you consider Segment enterprise software when you launched it, did you think about it as just a SaaS app? How did you think about it?

Peter: We thought about it as startup software at the time, because Hacker News is mostly seemingly people from startups who care about startup stuff, and it seemed like the open source library was getting adopted and used by startups. We assumed that we were solving a problem for startups. I don't think we had a lot of sophistication around understanding whether or not it was a truly huge market where we could serve the enterprise, or whether it was a smaller market where we would only solve a problem for startups.

Frankly, at the time we were just interested in surviving, and it gave us an opportunity to survive and at least build something. I don't think we had a lot of sophistication around thinking through how large of a market it was, or whether we would be able to serve the enterprise.

By the end of that first year, though, it was becoming obvious that the problem that we were solving was much worse in the enterprise. Like, a startup has one website, one analytics tool, one email marketing tool. Something like that.

Whereas an enterprise has multiple business units, and each business unit has a website, an iOS app, an Android app and maybe a Roku setup box or something. They have maybe even several different websites, or at least different ages of websites, where one part of the website is written in one framework and another part is written in another.

The morass of all the different data pipelines moving around between different places was much worse in the enterprise, so we got a pretty good flavor in the first 9 to 12 months. What we had stumbled across was actually a deep enterprise problem, and we had maybe discovered a unique route into solving it. Then we started to have sales advisors and other folks who were pushing us towards starting to think about pricing more for larger companies, and developing the product more for larger companies.

Grant: Because you didn't charge anyone right away, did you?

Peter: That's right. It was a completely free product for the first six months, and then we nervously and tepidly tested the waters for whether or not anyone was going to be willing to pay for it.

I remember sending an almost apologetic email, and we're asking people to pay $10 a month for access to the service. We later on had a sales advisor who we were charging $120 a year, or whatever. He was advising me as we were headed into the sales meeting, and he said, "You have to ask for $120,000 a year."

And I was like, "I don't know if I can do that. That seems crazy." And he's like, "If you don't do it then I quit as your advisor." And I was like, "OK. I guess I'm asking for $120K." So we went in, we asked for $120K and I turned beet red. My counterpart said, "How about $12K a year?" And I was like, "OK. How about $18K?" And he's like, "OK. Sounds good." We signed the deal at $18K a year, which from his perspective was 85% off but from my perspective was 150x the original price. Both parties won there.

Grant: That's amazing. There are many stories of bottom-up enterprise software companies that stumble into that type of pricing, where you just have to ask for more.

Peter: And it never ends. In fact, I don't think it ever can end.

The only way that you discover the actual value that you're getting, when you ask for $5 million or $10 million or $100 million a year, is the only time when someone says, "That's crazy." And you're like, "Why?"

And they're like, "Because here's how I think about the ROI." Then they explain to you exactly how it is that they would approach valuing it, which may not be helpful for that sales conversation, but it's helpful for every sales conversation you have after that.

Grant: Talking to your users. That's an important piece of it. So, tell me a little bit about when did you start building core features that enterprises were asking for? That you didn't think that any other startup would need?

Peter: It's only recently that we've started building what I would call features of the product that are specifically for enterprise. By recently I mean in the last maybe 12 to 15 months. Prior to that, the only things that we would build for specific customers were specific integrations. Segment is a service where we pull in data from a company's websites and mobile apps and help desks and CRM and so forth. We fan that data back out to analytics tools, email marketing tools, ad conversion pixels, data warehouses, etc.

So our largest customers and our largest prospects would say, "I need to be able to send my data to ExactTarget or I need to be able to sell my data to Marketo or Adobe Analytics." That would be an indicator to us that integration was important, so as part of a deal we would agree to build a specific integration. That was where a specific source of data or a specific downstream destination data, and that was the only customization that we would do for an enterprise.

We now are starting to realize, especially as we're selling to enterprises globally, not just a single business unit but a global enterprise. They actually need another level of account structure. A common thing that a lot of enterprise companies experience, and that we certainly are now, is how do you structure permissions, access, accounts, roles, all those things, for a much larger customer? That's one of the first things that we're building now.

Grant: Interesting. I do remember when you were pricing the differentiation between the plans, was access to these more enterprise integrations. Is that right?

Peter: What we realized is that it wasn't that correlated with value. You want to align your pricing with value that the customer is getting out of it, and access to those enterprise integrations was the core value of the product but it didn't differentiate, like "Why are you paying 10x more for this integration that clearly took no additional effort as compared to other integrations?" It didn't feel good to the customer.

We ended up with a pricing model then that was around billing for API calls to the amount of data flowing through, and that has some negative effects where you disincentivize your customer from using the product fully. Because they want to always be minimizing their usage in order to bring their bill down and that's not great.

So we eventually ended up with billing for monthly tracked users in three different tiers. As you grow your business, we grow with you and we're helping you grow. Therefore we're both aligned and it slopes with the value of helping you grow the business.

Grant: Interesting. You've made some changes there, and started to add in-- I'm on your pricing page now. You have the business plan, that seems to have some what I would think about as traditional enterprise-ready features that differentiate. Things like single sign-on and SLA, and you're saying those features you only started adding on in the last 18 months or so?

Peter:

SLAs are more about the legal aspect of the agreement, for most multi-tenant services you're not actually doing much different in the product in terms of providing that SLA. That's a contractual obligation.

Single sign-on is getting the account structure, access levels, same thing. These are things that enterprises need because they have so many people in so many different roles doing different things. There are a few features here that are more enterprise, like more customization of how things work. Like being able to selectively decide where data goes, or being able to sync data faster into your data warehouse, things like that. Those are those are all pretty recent.

Grant: I saw some things like data validation, which feels like a data-loss-prevention type tool to prevent information from flowing in. When you think about building these features, how are you doing that discovery with your customers? Is all of this based on feedback from customers and push on requests for, "We need this in order to adopt," or "We would use more if we had this feature." How do you get that information from them?

Peter:

When customers tell you that they won't adopt because you're missing X small feature, I think it's an excuse, and what it really means is the value was not high enough in order to overcome a relatively small objection. It's more that the negative space there in the comment that they're making is that the value isn't there, but they don't want to tell you that.

It's easier to tell you that, "It was because of X feature," or they "Would need X feature," or whatever. But the actual message there is much more important, and it's that the value isn't there. And we've never. Aside from integrations, we don't commit to building features as part of an agreement.

With a larger customer, we'll say, for a large customer, "You should be part of our customer advisory board. We're going to be interested in your feedback. We are generally building this product to be more enterprise ready. Here's a flavor of the things that are coming."

But we're not going to be held hostage to a specific feature request. Mostly because the value should stand on its own in such a way that they can use it and are getting enough value out of it that they're willing to overlook something like that. That's always been our experience, that when the value is there enterprises are willing to overlook it.

Grant: That's interesting. Instead of going customer by customer and deal by deal, and taking those orders, you're building a customer advisory board which you utilize to get that feedback in a more group setting.

Peter: Another way of looking at it is, rather than looking at your prospects for closed loss deals, like, "They wouldn't buy it because I didn't have X feature," that's dangerous because you'll have a lot of false positives in there. You'll go build a bunch of stuff that won't matter.

But when you have a customer, they'll tell you the things that they need, and you have the opportunity to go 10x deeper in understanding why they need that. Then when you deliver it to them, as a beta feature they're already set up, and you can see immediately whether they're going to adopt that thing or not. Which then allows you to save a lot of time in terms of developing only the things that matter and only launching the things that matter.

You can prevent a lot of bloat and a lot of complexity by paying more attention as you're building out features that are specific to the enterprise, and pay more attention to what things your existing customers want and being careful about analyzing closed loss too carefully on a feature basis.

Grant: That's great. Let's talk more about that process of GA in beta, and how you think about building out a feature and getting it into customers hands before you launch it more publicly.

Peter: We have different processes for features, versus products. For features, we tend to rollout to a percentage, oftentimes to self-service first because they're a little bit more tolerant of issues. Whereas enterprise customers are expecting slow and steady, but works, guaranteed.

We often roll out new features to self-service customers or smaller customers, and then over time roll it up to the larger ones. Unless it was a feature that we were specifically building for large customers that we had a specific two or three customers that we were building it for.

For example, multi-level account and role permissions is obviously something that we would build in partnership with a few large enterprise customers, and then we would launch that to them specifically in a closed beta or limited situation. And then we would expand that over time.

For products, we do something similar, where we develop the product in partnership with 10 or 20 customers that we think are representative of a broad variety of use cases or industries, and then we typically have pretty long private betas. We'll have a private beta run for six to nine months where we're confident that it's delivering value, and we have cases and case studies and everything, then we launch it to general availability and that's the first time typically that we do marketing around it.

There's been a couple exceptions, but typically GA is the first time that we put it on the marketing website, announce that it's available at all, etc. Our strategy is that by the time it hits the marketing page it's there and ready for anyone to buy it.

Grant: It sounds like it's also ready for your sales team to sell it, and your marketing team to promote it.

Peter: That's right. And with an enterprise sales force or just sales force in general, there's a lot that has to go into getting your product ready to sell. If it's a major new part of the product and not just a feature, then you need potentially updates to all your legal agreements which then affects how your deal desk is getting ready to sign those agreements, that affects pricing, which then affects all the pricing calculators and ROI calculators that you provide to the sales team.

It affects all the collateral, all the pitch decks, all the messaging. There's a lot of work that has to be done from the time they have a product that the beta users are using and succeeding with, until you have a thing that sales team can effectively sell into the market.

Grant: I love this topic because this is one thing in enterprise software that's hard to grasp at first, but you have to spend as much time creating the collateral that you have. It could be code complete, but it's not ready to roll out until all of your internal teams and stakeholders know what it is and how to talk about it and how to position it. You have the collateral and how do you describe it. Do you guys work with channel partners?

Peter: We don't, really. We have some partners who do implementation work, we obviously have a whole ecosystem of technology partners that we integrate with and send data to, but we don't have an extensive channel partnership or reseller model today.

Grant: That adds another layer of complexity for rolling out these features, because now you're talking about enabling not just an internal team but several external teams.

Peter: It's an immense amount of complexity.

Grant: As a product leader and someone building these things it's one of these things that you have to recognize, that your job is not to just deliver the feature, you have to deliver the customer use cases and everything end to end in order to make this ready for the market.

Peter: That's right, and it is a lot more work than you'd expect. We have shifted. We started as self-service, now an increasing percentage of our revenue comes from what I would call truly the enterprise. Thousands of employees or tens of thousands of employees.

As we've gone through that shift the need for more of that supporting material, supporting process in launching a new product, the need for that has gotten greater. So when we were mostly a self-service project we were just like, "Put up the landing page," and off we go. But obviously you get a lot of go-to-market leverage and revenue leverage out of having a salesforce and all these other supporting materials and processes in place.

Grant: What have you, as a CEO who-- None of your founding team had a background in enterprise software. How have you continued to arm yourself with this information and learn and grow into this role? What have you been doing?

Peter:

You learn the most from hiring execs who have experience in the field.

For example, our VP of marketing, Holly, used to be VP of corporate marketing at MuleSoft. Classic enterprise software sale. She brings an enormous amount of experience and understanding of how enterprises buy from analyst relations to how to run a conference, and so on and so forth.

All these things that you just don't know that she has extensive experience with, and similarly on the customer success side, Vishal who runs customer success here has a background at Medallia, which again is a classic enterprise company. These are the people who teach the founders as much as they operationalize things in the company, and teach the company how to go about doing these things.

Grant: That's great. It's about the people you've been able to hire as you've scaled, and then you guys have to stay up to speed and continuously learn.

Peter: Obviously you can learn from advisors as well. The first sales advisor was hugely helpful in getting us from an MIT open-source mindset to, "We're going to charge real money for this highly valuable product." There's a lot of people that help along that journey of learning more and more, and every sales person that you hire also comes with experience of how this thing was previously sold at whatever company they came from, and how it used to be done at Salesforce or the folks in marketing bringing that experience.

Even folks we hired in engineering used to work as consultants or contractors, and they have an experience of, "Here's what it's like to work with a large corporation." All those things add an enormous amount of the mix of knowledge in the company, and Segment is about 320 people today. There's a lot of tribal knowledge and information sharing and learning that can happen internally.

Grant: That's cool. When you look back at your experience of coming from not having this background to now being pretty deep in the enterprise software world, what are some of your biggest learnings? What are some of the misperceptions you had previously versus what you think today?

Peter:

One big misperception was how sales works. Which sounds maybe trite or dumb, but a lot of young engineers and other technical folks have this tendency, and I was definitely in this camp. They have a tendency to believe that sales is showing up polished and giving an amazing pitch and selling it.

Especially in the enterprise, but true at all levels, the better your sales process and the better salespeople have a different approach. Which is to do discovery and understand what it is that the problems are that your champion or that your leader, your prospect, your potential customer are trying to solve and getting quite deep into understanding their business.

The process of sales is very different and much more consultative and intellectually stimulating and warm and value creating than most people realize or give it credit, because the sales people they encounter maybe sold them a car, or whatever, which is a pretty different type of sale. There's a lot you can learn when you sit down with a customer and ask them how their business works, and shattering my understanding of what good sales actually looks like continues to be both fascinating and just different than what I came into Segment expecting.

Grant: That's great. For many technical founders, we all learn a lot about sales as we as we grow, so it feels like an area where we don't really understand why it exists when you first start. Then as you get into it you start to realize that it adds a lot of value, and if you can get in the room with a customer and hear their problems, you can start to problem solve even better.

Peter: Exactly.

Grant: Many enterprise software companies do a total top-down approach, where they have this outbound team that's creating every lead, and they're walking the halls in these organizations. But Segment comes from what I would call bottom-up roots, and you still have what looks like free plans. How important are those developer signups to your enterprise sales motion?

Peter: We do still have a free plan and it's by far the most used plan by number. We have about 19,000 companies that send data through Segment today, while the vast majority of those are on the developer, free plan. What's interesting to us is if you take the long view on those small companies who are using that, unfortunately most of them fail as a business.

What that means is that the people who learned, either on their side project or their side business, or on a startup that didn't end up working out, maybe even on the team plan. They end up then going somewhere else. Could be to another larger startup, or it could be to start another company, or it could be to join an enterprise.

A lot of our enterprise customers come from people who've already used Segment somewhere else.

You get this transition of, "Now you have a champion who was born ready. They know how it works, they know how to deploy it. All they have to do is figure out how to navigate the internal purchasing at the enterprise, and now money no longer matters."

These movement of people between businesses from small to large has been a huge growth lever for us. Part of that is that we have a relatively bottoms-up sales motion of a relatively junior engineer or engineering manager or engineering director typically kick things off, and then we end up signing with a CTO or a VP engineering or a CIO.

The bottoms-up motion of the sale matches with the bottoms-up nature of people moving around between companies. In just the last year we've had conversations with some of the world's largest telecoms and one of the world's largest shoe makers, and they become customers as a result of people coming from startups into those large enterprises.

Grant: That's interesting. So it's not even just a developer from one of these big enterprises comes and signs up for a plan and starts to put it into one project, it's that they've used it before in side projects or other places, and then they want to bring it into their companies?

Peter: That's right. If you take a company, let's compare and contrast with Twilio for a second. For those of you who don't know, Twilio is a way for developers to send text messages and make phone calls and stuff like that with a nice set of APIs over what telecoms provide.

And that's a product that a lone developer can use for a little hack at work, for a demo or they could build a little side project or whatever. There's a bunch of things happening inside a large company, where they might have a small use case and that becomes their in, but it is the enterprise using it.

It's just one developer inside an enterprise, and the question is, "How do you move up the chain?" Segment has a different motion, which is it's difficult to get that much value out of Segment unless you're using it holistically at a business unit level. You either deploy it to the website or you don't.

If you are going to deploy it to the whole website, now that's a business unit that owns that website and maybe has an iOS app and an Android app or something like that. Now you deploy that business unit granularity, rather than individual developer or individual team level. What that means is that

we tend not to land with an individual developer, we tend to land with a business unit.

The motion for us is more people moving into a business unit that then we land in because their startup failed or whatever and they got hired by an enterprise, in contrast to what Twilio does. Which is a developer starts hacking on something and there's a natural motion to just use more and more by deploying it into a core product as opposed to a demo.

Grant: That's great. Is there any tension between your developer plan and your paid plans, or do you think that it's a pretty natural progression that once you start using the business unit you move into this next layer?

Peter: It's super natural. There's no way. The developer plan includes 1,000 tracked users. If you are a business with more than 1,000 users, then the free plan doesn't work, which makes sense because we have to limit our costs on the free plan, too. We can't be processing massive amounts of data.

Grant: It looks like you don't allow the free plan to do any user management. There's just one user.

Peter: That could be the case.

Grant: You mentioned your open source roots with the JavaScript project, but you guys have done a bunch of other open source as well. Why do you do that and how has it helped your enterprise adoption?

Peter: I'm not sure that it has helped our enterprise adoption that much, we mostly do it to show the amazing work that the engineering team is doing and give back to the community in ways that, "We built this thing. It's not really a product that would go in our product suite, so I hope someone else can make use of it," kind of thing.

Some of those are more infrastructural, like we open sourced our stack and some tools around using some of HashiCorp's products. We've also open sourced libraries like Nightmare.js which allows you to do crawling, which we originally used to automate logo creation with 99 designs because we have hundreds of logos in the product for all the different things that we integrate with, weird pieces of our tool chain and stack we've open sourced primarily to show off what the engineering team is capable of.

It helps attract other engineers who want to work at a company that's willing to give back, and where they can see the good quality and excitement and development that's happening on the team. I'd say it's less helpful from an enterprise perspective for us, although it could be a strategy that others use. For us it's more about the team and the brand and giving back.

Grant: It's more of a hiring advantage to be able to have these great projects and give back to the community.

Peter: That's correct. And honestly some of them are more popular than Analytics.js. Nightmare.js has 15,000 stars on GitHub, so it's doing well, and I'm sure someone could or should have maybe turned it into a product. But it doesn't align with our strategy so we just open sourced it and let folks run with it.

Grant: It is funny, I'm looking at it right now. Analytics.js has 4K, Nightmare has 16K and even Metalsmith has 7K. Some of your side-project open source projects are getting more stars than the core value. Obviously there's so much more to Segment now than Analytics.js.

Peter: That's right. Not every open source library is as amenable to being a software hosted product as Analytics.js was. You can get a lot of value out of Metalsmith and Nightmare as open source products, but it's difficult.

Analytics.js as an open source library doesn't solve the core problem, ironically, which is that the whole point is to try to get the engineer out of the loop so that you can turn on new marketing tools, so that you can turn on new analytics tools and send data to all these new places without needing the engineer there to do it.

But if an engineer has to go recompile an open source library and redeploy it to the CDN, you haven't really solved the problem.

A lot of engineers like the open source library because they're like, "It's great that I can see the code. This is totally the right way to abstract and solve this problem." But at the end of the day, to really solve the problem you go use the hosted version. So, not every open source library is as amenable structurally to a business model.

Grant: Early on, were all three of you writing that? Or was it something that one of you guys did and the others just let happen?

Peter: All four of us touched it in meaningful ways and improved it in meaningful ways prior to its launch on Hacker News, but it was spread out over 18 months. The crappy first 50 lines of code that don't even look like the library were written by me, and Ilya made a bunch of upgrades where then he turned it into a library and clarified a whole bunch of things. Then Ian and Calvin did a lot of fine tuning and polishing and recognized that it was even a thing. So everyone had a hand in bringing that library to life.

Grant: Then with new products that you guys developed, do any of the founders still have a hand in zero to one on new products?

Peter: Absolutely. In May we launched a new part of the product called personas, and personas basically takes all the data that's flowing in from all your different sources and bundles it up into a profile of that customer, and your interactions with that customer, only your first-party data, and then it allows you to build audiences that you can market to and gives you API access so that you can build internal apps or modulate your product or whatever, based on the data that you have about each individual customer in its totality.

That product was driven by Ilya my co-founder. He is often the tip of the spear for new product development, and then Calvin works much more heavily on key infrastructure improvements. Major improvements to reliability or visibility into data delivery and core infrastructural things at the heart of the integrations product and core platform.

Grant: Cool. So Ilya is still involved in the new product introduction?

Peter: That's right. He led a team of about a dozen people to build that product.

Grant: That's cool, and you were off doing other things I'm guessing?

Peter: Yeah. There's a few other things on my plate now. A mixture of sales and hiring for the exec team, and so on and so forth. All the things that that fall to the CEO.

Grant: There's obviously a lot a lot going on there as well. But do you do you miss it? Is that something you enjoyed spending time with?

Peter: I love spending time on product strategy, and spending time on understanding what problems customers have and what we could do to solve those problems. My role now is one more of understanding the market and understanding a broader product strategy, as opposed to specific product choices.

There's a lot of talented people on the team who can and should and will do better than myself at working on product specifically. But the broad overview of a market and how the business is operating and all that business context is helpful in understanding product strategy. The CEO can contribute there uniquely.

Grant: One thing that Segment has done well over time is understand how your customers are using your product, but then also figure out where the edges are and what they're integrating it into next, and then trying to make that next integration even easier. Is that a core part of your overall strategy?

Peter: It is. The path of finding product/market fit, we think of as a competitive advantage, and that's something that we've put a lot of time and effort into refining how we go about doing that internally. We were gifted with a specific set of experiences in the early days, where we failed twice and then saw something work.

We saw both sides of the coin and had the gift of being able to observe what happened differently in those two cases. Since then we've had a few other product/market fit moments. Launching data warehouses is a downstream set of destinations that have a transformative effect on our pricing, our growth rate, on pulling us up into larger companies and enterprises.

So we've had a few of these product/market fit moments, and we've tried to be self-analytical about what it was that led to success in those moments so that we can try to have real repeatability around product market fit.

Ultimately, product/market fit is the thing that drives the opportunity set for a company, which is if you can find product/market fit on a new thing, you suddenly have a much larger opportunity and obviously you need to execute on the go-to-market motion.

But the opportunity set increases every time you are able to expand product/market fit, so we put a lot of effort into understanding where those edges are and which ones are worth attacking, and trying to develop a real process for understanding where and how we should take advantage of those opportunities.

Grant: It sounds like it's far less happenstance than the initial product market fit with Analytics.js. It's like you're much more methodical about this now.

Peter: Analytics.js was a shot in the dark that worked, and we learned a lot in retrospect about what we shouldn't be doing. We previously developed a lot of grand visions. Like we had a grand vision for how we were going to transform the classroom. Then we had a grand vision for how the world should do data analysis, and the reality is the world doesn't give a shit what your vision is.

The market or the world has certain problems, and if you solve those problems then they will come knocking. It's helpful to have a vision for people to rally behind, but it's much healthier to learn how to pay attention to and dive into what customer's problems are. There's a lot of lip service given to that, but it's not an easy thing to do. To dive into what problems the customer has is actually challenging, awkward and quite unnatural when most people go to try to do it.

Grant: Part of the challenge is it's hard to earn the right to be in the room to hear about those problems.

Peter: Totally, and why should they tell you? Exactly. Problem number one, "How do you earn their trust, such as they'll actually tell you what their real problems are?" Super not easy.

Grant: Then problem number two, understand those problems in a way that you can go and try to solve them. Right?

Peter: Yeah, and the real problem is that most people don't go deep enough. The real problem is that typically a product manager will ask a question like, "Would you find value in this? Would you pay for this?" They get a yes or no answer and then maybe they ask one or two follow up questions, but at that point they make the decision as to whether or not there is product/market fit.

There's this art of reading between the lines or whatever that product managers try to learn of like, "Are they excited about it or are they not?" And there's this witchcraft of "How do you interpret the response?" I think it can be relatively straightforward, but it's quite awkward, which is asking question after question after question after question.

You just keep diving deeper and deeper and deeper and deeper into their problem, until you get to a point where it's natural to ask for an amount of money to solve that problem. For example we launched this product called protocols recently. It helps companies keep their data clean, consistent, and accurate as they're collecting data about customers from all their apps and everything.

The initial conversations that we would have with customers would be more like, "Do you have trouble keeping data clean and consistent?" "Yeah, we do." "OK great. Would you pay for a product that would help you make that data clean and consistent?" "Absolutely." And you're like, "OK great. product/market fit. Check."

But the much better conversation is, "Do you have this problem with keeping data clean and consistent?" "Yeah we do." "What do you do about it today?" "We have a team that does all the data QA." "How big is the team?" "It's about a dozen people." "What exactly do they do?" "Every time we release a build they go in and push all the buttons in the app, and make sure that the data shows up in Segment every time for every correctly on every single button push." "Interesting. Does that slow down the deployment process?" "Totally. We can only deploy four times a day or three times a day as a result." "Interesting Where are those people based?" "They're based in LA." "OK. The salary is $80-100K per person there?"

And they're like, "Yeah. Something like that." "OK. You spend a million dollars a year just on data QA." "Yes." "OK, what if we gave you a way to enforce this control in this way? Here's a mockup. Would you pay half a million dollars for this?" "Yeah, we would." Now you have product/market fit, and you asked a bunch of questions that feel awkward and penetrating and incisive, but it's a totally different kind of conversation that is not easy to have.

Grant: What do you think can make it easier? Just acknowledging that it's going to be awkward and you are going to sit there in weird stares for a moment, or is there something you can do to help make this a bit of an easier process?

Peter:

Most product managers don't realize that they can go that deep. It's one of those things where it feels awkward, but the other side is happy to talk about their business. Everyone is happy to talk about their business, it's what they work on all day. They love it and they'll be delighted to tell you everything about it.

No one else ever asks at this level of depth about how things are going or what's going on and what their problems are. Most people are actually delighted to talk about it, but it feels wrong to the PM who's looking into it.

Grant: Do you do those in-person, or do those via Zoom? How do you do that?

Peter: In-person is always best, because then you can read body language, but Zoom can work, too.

Grant: So, today you try to do those in-person as much as possible?

Peter: It's harder. The other person has a little bit more of a social contract when you've looked them in the eye and shook their hands, that they're, A, going to tell you the truth too. It's a little bit of a process for them to get you out of the room and out of the building, so the pain factors are such that they're a little bit more willing to answer your questions in depth.

Grant: How many of those customers do you talk to or look for before you say, "OK we're going to build this thing."

Peter: 10 to 20 if they're varied enough.

Grant: Why do you look for a wide variance, just for total market size?

Peter: Exactly. You want to make sure that it's going to be broadly enough applicable for whatever it is you're building.

Grant: Do you go in there with mockups? Do you go in there with a proof of concept? What are you taking in to them?

Peter: We will take whatever it is we have at that point. Obviously the initial discovery of trying to see whether there's even anything there, might just be a concept and some pencil drawings, or you might just whiteboard and then over time you'll start bringing in more and more as you refine it. Then you want to de-risk it further, then you could start bringing in mockups and say, "OK. Here's what it looks like."

The problem with mockups and some of the higher fidelity things is that someone will maybe start commenting on how the UI could be better, which is not-- You want to be spending your time mostly getting at the business problem. So mockups can be counterproductive in having people focus on how the UI can be better, as opposed to whether or not they have the business problem that they would pay to solve.

Grant: More like diagrams or workflow, or data flows, or--

Peter: At least until you've validated that there's a business problem there you're effectively doing sales qualification without a proper demo, which is tough, but you're doing sales qualification without a proper demo. Then once you've qualified them, "OK. Great, sure, yeah. Pitch it and then maybe show them the mockups, or whatever."

But it's still a dangerous thing to do if it's early and rough, because they may give you feedback on something that's obviously going to get better, like the UI or the UX instead of whether or not they really have a problem that you are going to solve.

Grant: Are these things that Ilya is doing, or is it something that your product team's doing? Who's taking the first versions of these meetings?

Peter: It's the product team, so the product manager on Ilya's team who has developed several products over the years. Kevin, he's fantastic. And Niel has been driving this on protocols, and the whole team of product managers that are doing this to varying degrees across the company. There's a different type of product management that's more refinement of flows, and a little bit more numerical and so forth, and that's a totally different thing.

Grant: Interesting. So you differentiate the zero to one product discovery, product management from mature product management?

Peter: We don't differentiate the product management. Not the roles, or anything. But we differentiate the process or whatever we're following for the two different types, for sure.

Grant: That makes a lot of sense. But you have the same people do both?

Peter: Sure. At different times, yeah.

Grant: One other topic that I want to hop into because I know you guys spent a lot of time on it, and I want to see how it's working out and what your thoughts are, is GDPR. This was a hot button topic a few months ago as that date was coming around.

I know you guys got ahead of it, but this is a really enterprise specific, obviously it has implications down the whole pipeline but can you just talk about the process you used to figure out what you were going to do for GDPR? Maybe even a little bit about how it's worked out?

Peter: GDPR is super interesting for us. We started working on it more than a year ago and we had a product built around it well ahead of the actual go live date for GDPR in May. Because Segment is obviously a data processor, we have data flowing through our systems on behalf of customers and they continue to own the data, so we're just processing on their behalf.

It's a big product opportunity for us. There's GDPR compliance that we need with our own data with respect to customers, but there's also the fact that we're processing this data and fanning it out to a whole bunch of other tools that they're using.

If they need to process a user deletion request or they need to process a change of a trait of a person, then we're uniquely positioned to federate that deletion request out across all the different tools where we happen to be sending data to for them.

There's a real opportunity for us to be helpful not just in being GDPR compliant ourselves, but actually be helpful to them in being GDPR compliant with their customers. For us it was a product opportunity, and that's why we invested so much more heavily in it than many other enterprise focused software companies have done.

Grant: Sure, and as that date has come and passed, obviously there was a ton of build up to it and I'm sure that there was a lot of conversations. Has it continued to drive new conversations with your customers?

Peter: I don't think it has ever driven new conversations for us, and we didn't expect it to. It's a huge boon to be able to explain to companies that we're not just compliant but actually helpful. Especially for our European team, we have a team based in Dublin that works with all of our European customers. That's been helpful for sure there.

One thing we have been surprised by is just how many deletion requests there are. We originally built the API to handle deletion requests assuming, nobody knew how many people were going to want to delete their stuff, so we made some rough estimates about how many people would delete stuff. We've been surprised by the volume coming through that API, so we had to go do a bunch of work to make it cheaper for us to handle each one of those requests.

Grant: So, the deletion requests that you've seen in aggregate are an order of magnitude or two orders of magnitude more than you initially thought they would be?

Peter: Maybe two orders of magnitude higher.

Grant: That's interesting insight.

Peter: From a regulatory perspective, in terms of enforcement of GDPR, I assume that the regulatory bodies are moving slowly and we'll start to see stuff land in the latter half of the year. I don't have any inside track there, that's just my gut feeling, is that the enforcement of it is yet to come. That may cause a second panic as opposed to just the first panic around the date it went live.

Grant: That's a great point. A lot of people are waiting in the wings to see what happens, and if 4% of revenue ends up being taxed as a result of these GDPR regulations it will definitely put more people into motion.

Peter: Exactly.

Grant: When did it come on your radar? When did you realize it mattered? How did you decide, "OK. Let's invest here."

Peter: I don't recall exactly. It may have been a product manager at Segment who is particularly talented for having his feelers out on the internet, and knowing all the market trends that are happening, who noticed it and he ended up leading the project to build the product and launch it.

Grant: Because I'd say, you guys were paying attention to it far earlier than most other companies were. Obviously you built things out ahead of it, so you were a year out ahead of most other companies your size.

Peter: Full credit to Chris, there.

Grant: Another advantage of hiring great people. Peter, this has been super helpful. I love learning about how you build new products and how you think about that. If you don't mind, I'd love to have you pitch Segment for a minute, or however long you want to pitch it. Give an end to end about what you guys do.

Peter: Historically, most companies have kept track of their interactions with their customers in a CRM, or a customer relationship management tool. But what's interesting is over the last few decades the world has moved online and become much more digital, which means that the channels by which you interact with your customers has changed drastically. Companies are no longer interacting entirely in person, possibly with the exception of really heavy enterprise sales companies.

What that means is you're now interacting via a website, via a mobile app, via email, via push notifications, via help desk. All of these digital interactions no longer fit well into a CRM, and instead modern companies need a way to structure, store and use the data about interactions that they're having with their customers.

That's what we call customer data infrastructure. It's infrastructure that helps you collect and understand and use all of the data that you're getting from all the interactions with customers across all these digital touch points, and that's what we're trying to build at Segment.

We have three products that line up with each of the three major value props of customer data infrastructure. We have our core connections product, which is about collecting data from websites, mobile apps and so forth and fanning that data out to all the places where you would use it. We have protocols, which is the way to ensure that data that you're collecting from all these different touch points is consistent and accurate. It's a way of enforcing that data schema, which is especially important if you have a large company with many business units.

Then we have our third product called persona, which is about activating and using that data by structuring it onto records of individual people and allowing you to build audiences, and market on top of that. This whole bundle we call customer data infrastructure, and it's used today by about 19,000 companies and increasingly by large enterprise customers IBM and Intuit, and so forth.

Grant: Peter, this has been super helpful. I appreciate your time. I know you've got a lot going on.

Peter: It's been great being here. Thanks for having me.