The Data Stack Show - Data Council Week (Ep 3) - GTM 101 for Engineers With Chase Roberts of Vertex Ventures

Episode Date: April 25, 2023

Highlights from this week’s conversation include:Chase’s journey to where he is today (0:51)Lessons in go-to-market roles which helps in the VC world (2:38)Differentiating between go-to-market and distribution (8:13)Taking an idea to the market (11:33)Hardest part of the pitch (17:08)Playbooks for go-to-market founders to follow (20:25)Focus of sales and marketing in go-to-market strategy (28:01)Answering the what and how of the problem you are solving (32:30)The importance of pricing in a go-to-market strategy (46:11)Connecting with Chase (1:00:58)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Welcome to the Data Stack Show. Each week we explore the world of data by talking to the people shaping its future. You'll learn about new data technology and trends and how data teams and processes are run at top companies. The Data Stack Show is brought to you by Rudderstack, the CDP for developers. You can learn more at rudderstack.com. Chase, great to have you on the Data Stack show today. We are here in person at Data Council Austin, which is so exciting to get to record some conversations in person instead of over a Zoom. I'm Brooks. I'm filling in for Eric today. He did not get to come to the

conference. He got in a little bike accident. He's okay, but wasn't able to make it. So you stuck with me today, but Chase, so excited to have you on. To kick us off, could you tell us a little bit about your background, kind of how you got to where you are today and what you're doing today? Sure. So I grew up in a small town in Oklahoma where the primary industry was not venture capital and nor was it technology. It was ranching. After college, I went to work in the finance industry for a bit, did some work at an investment bank and an alternative asset manager and did that for a couple of years and then realized moving numbers around on spreadsheets wasn't the most exciting thing in the world to me. And by this point, I had become aware of this place called Silicon Valley and this idea of tech based entrepreneurship

you know growing up the you know the idea of someone starting a company and that product reaching the world was just like totally a non-thing and yeah I started to become aware of this and decided like I want some that. And so I quit my job. Cold turkey, had nothing lined up, and just figured out I was going to get to Silicon Valley somehow and shorten the story so we don't sit here and dwell on it forever. But I sent a cold email to a software company called Box because I had read a book by a guy named Clay Christensen called The Innovator's

Dilemma. And I found a video of him speaking at an event for this company. And I was like, hey, anyone who puts this guy on stage, they must be doing something right. And yeah, that led to my first job in the Valley and drove on to U-Haul with my wife of three months, who probably thought I was crazy. That is a bold move. And joined the company sight unseen. And that kicked off my career at the Valley. I joined Boxer early, spent half a decade there on the go-to-market side and wore a bunch of hats on the rise from, you know, we all still fit in a room to public company.

After that, I went to a software company called Segment where I joined as the first hire for the BD team and helped grow that and build that function. And then I got into venture capital about four years ago. So today I'm an early stage investor investing in mostly technical founders at the Seed and Series A stage and living the dream. Yeah, that's awesome. So before we get recorded here, we're just talking about your role now, and especially I think working with technical founders is kind of, hey, let's really do some research and find the best products. But your background is on the kind of go-to-market side, and you're talking about even some lessons you've learned as an investor about the relationship

between the product and kind of the go-to-market motion. Can you just unpack that a little bit for us? Yeah, happy to. So I think that one of the most common failure modes we see among founders is they don't think of go-to-market or the commercial side of their business as part of product development. The idea that I think a lot of founders will pursue is they look at the problem that needs to be solved and they try to build an elegant solution to solve that problem. And they're actually not wrong in doing that in the sense that building deep empathy for this problem and trying to build a really great solution to it is actually a good thing to do.

That's half the battle. The other thing that you have to do is figure out like, how do I get this out into the market? And, you know, your product isn't just how like what you've built, it's how your customers come to realize it. And that means understanding how these buyers and users of the technology become aware that the problem that you're solving is one that they have. It means trying to understand how they would go about seeking a solution for that problem. So not just what competitors of yours might they look for, but like, what are the substitutes? What are the internal, you know, tasks they do to, you know, brute force that problem? How would they go about evaluating a solution to that problem? So what are the decision criteria for that?

And who is involved in that? And then ultimately, what is the thing that's going to compel them to buy? And all of those things are actually part of getting your product into the hands of a customer. And I'm going to give some very straightforward example here, and probably the most rudimentary example, but I think it'll drive this point home. So for example, if one of my decision criteria as a company for whether or not we can use a product is whether it has something simple like SSO, that matters from a go-to-market standpoint, and that also matters

from a product development standpoint. Now, that's a more simple example. I think a little bit more difficult one would be, well, who is the buyer? There are users of technologies and there are buyers of technology. And what is the thing that the buyer cares about from an organizational standpoint when they're evaluating these tools? And what are the metrics that they're trying to move within their organization that would actually say, hey, this is something that matters to me. It's great if it makes users happy, but if that's not going to move the needle for this single person or group or whatever who is involved in making the decision, then it doesn't matter if the end users like it,

it matters if the features and the value that those features are providing are actually moving that needle for that person. And so, or that group of people. And so I think that like trying to consider all of these things is really important for, you know, actually just building a problem or building a product that people are actually gonna buy. One of the things you mentioned was just this kind of thought exercise

about products and go to market. Can you just rehash that for us? So, you know, there's this, you know, we run this thought experiment. If you, it's empirically true. And I think it was Peter Thiel who might've said some version of this previously, so I'm borrowing this idea, but it's empirically true that you can build a monopoly selling an undifferentiated product through a differentiated go-to-market or a differentiated distribution. But if you were to flip that, the inverse of that is not actually true. So if I have a differentiated product, but the way that I reach customers is completely undifferentiated, it's completely non-unique, then it's really hard to build a monopoly. And I think an example of the former, I think we can come up with multiple

examples of commodity products or undifferentiated products that are just giant companies. I mean, look at oil and gas, look at airlines like these are exactly the same product all the way and through but if but you know if you look at the other example like let's pretend i've got the absolute best charger in the world i've built i've got it supplied the best it charges phones the most quickly but if i'm selling that on amazon and i don't have any edge to reach those users like it's gonna be really hard for me to rise above the fold and build a great company there. And there are ways to build great companies on Amazon,

but they've been able to figure out a way to differentiate what they're doing among their competitors, among the other people. I think a lot of technologists and a lot of founders will get caught up in trying to build a technically elegant solution a very sophisticated solution thinking that if they can do that you know in the most excellent way then that's going to be the thing that causes them to win but i think the thing that i think that you know building a product that solves a problem and you know having product market fit you know is a necessary condition but it's definitely not a sufficient one. I think winning to meet that sufficient condition, winning means figuring out how do I win the ground game?

How do I win the go-to-market game in helping get this thing in the hands of people? That's a very interesting thought experiment. You mentioned two terms. You said go-to-market and distribution, right? Let's get a little bit like in explaining the terms. And what's the difference between the two? I'm using them interchangeably. I'm using it as a catch-all for you just process of taking this thing that's built

and getting the market to realize it. And how does it usually look like when you start, right? Because you start like the company, you have something in your mind as a founder. Usually it's probably like a technology that you have in your mind, especially if you're like a technical person, right? What are the steps like to start like laying down, laying out like strategy for going to market? So I love this question because one of the things that I often see is founders will decide that

they will see the importance and they will decide, I'm going to turn this on, basically I'm going to put a key in ignition, turn it on, it's going to work. And they make a decision kind of like in isolation around, like, hey, we're just going to get this thing working. And what they'll do is they'll say something like, there's a common phrase I'll hear is,

you know, we're just going to, we're going to turn on product-led growth because we think that the way that this should be sold is like bottoms up. And, or they'll say, we're going to turn on top-down sales because the way that we think that we want to sell this is by selling to bps avenge and the problem is that statement doesn't actually say didn't incorporate the language how does my customer buy because the way that you go to market isn't really isn't a function of how you want to go to market like how you want to sell it's a function of how your customers want to buy and so coming back to the statement i made earlier around how would your customers become aware that this is a problem that they have and how would they go about evaluating a solution here? If that means that the way they become aware of it is they go to Google and they search for a tool,

they go and test it out, and then they buy it and swipe a credit card independent of talking to anyone in their company, a product-led growth might work for you if the way that they become aware of a solution is well someone has to call them ring their doorbell and send an email or send a care package or go to a conference and say hey you know here's a problem that you probably don't realize you fully have or here's a different way of thinking about a problem that you probably don't realize you fully have, but here's a different way of thinking about a problem that you're trying to deal with internally. Let us help you evaluate a solution here. And then if there are multiple people involved

in trying to make a decision around that, multiple stakeholders in that problem, then you're doing top-down sales. And so you're going back to the question you asked, which is, you know, what are the steps? What is the sequencing? The first step is trying to understand kind of the problem space, not just your competitors, but just like all the substitutes for this thing that you're doing. And then try to understand how your customers or your prospective customers would go about

trying to tackle that. How would they evaluate tools? How do they typically buy things in this category? That's kind of like the first thing. That's the first set of questions you ask and you work backwards from that. Yeah. That makes a ton of sense. But let's say you're an engineer who is working in a company like AWS or Meta or Netflix,

take any of these crazy big companies out there that build amazing pieces of technology, right? And you build something there, right? Let's say it also gets open source. And you're tempted to go out there and build a business around it. You might think that, okay, I built it in here, so there is a user or a customer internally, right? How close to reality is that?

And what kind of, let's say, change in mindset requires for a person who has gone through that right like because they built something for someone it's not like they built it like it's like from scratch completely right like someone asked them and like there is like internal value for this but probably like this internal value is not exactly like what the rest of the market is out there so what's your take on that and like what you would say to these engineers that they are thinking or doing something like that well i think i mean you know the good news is in the case of that engineer they've got some sense that there is a problem and it can be solved a certain way

and they've built something that to solve it that way i think that you know the first thing i'd say to them is like the way that the way that companies are going to buy and you know look for technologies and evaluate technologies like this is not you know an internal pm saying like hey we need this thing yeah or you know business leader you know calling someone on the you know developer tools team or something like that it's going to happen in a much different way. And so the assumptions that they've made around, maybe not even assumptions, but the experiences they've had around how the problem gets discovered

and the solution gets ultimately realized by the organization is not going to be the same when you have a different email alias and actually have to get money to change hands to get them to buy whatever it is you're you know have a different email alias and actually have to get money to change hands to to get them to buy whatever it is you're selling yeah 100 like how like that person should engage into that like learning that like do you believe that let's say we have the smartest like engineers like from whatever company okay and they get the smartest VCs out there, including you of course, to give them money. And they already like to go and attack the market. How they are going to learn about that stuff? Because humans take time to learn.

It's not like something that you just read a textbook and you go and execute. Do you believe that like they should do it on their own first of all do you think that they should bring let's say sales people or like go-to-market people let's put like everyone like under an umbrella there early on to take on this role and like try like to do that like what have you seen like working and whatnot so i'm gonna i'm gonna start with an anecdote and then I'll answer your question very directly. Last night I was at one of these fun, happy hours for the data conference. And I was speaking with an engineering leader out of Twitter who was starting a company.

And he volunteered one of the weaknesses that he's concerned about himself. He's like like you know i'm just because i'm a wonderful engineer he goes but i'm just not comfortable with go-to-market stuff i'm just not comfortable with commercial stuff and what i the way i challenged him is i said look if you define the problem that you're solving as i'm building this product for this technology then you will be bad at go-to-market stuff. But if you expand the scope of the problem to include like, and getting it in the hands of people and understanding how they might consume this technology in their organization, you've

just changed the problem definition. And now your job is to apply your engineering brain to that and not just building the technology. And so what does that mean from a job to be done if I've just left Netflix or whatever company? How do I actually get these learnings? you know, as you're having those conversations with customers about, you know, the problem itself and, you know, the pains that they're having the organization, start also asking the questions like, what have you tried in the past? What other solutions did you evaluate? Who was involved in that? When you're looking at tools like this, how do you typically evaluate those as a company? What are the metrics that matter that this tool needs to influence? Oh, it's a cost thing. Oh, it needs to move revenue in some certain way. Oh, it needs to minimize risk along this dimension. And you start figuring out the value metrics that actually matter. And then it kind of gives you a little bit of a North Star,

like, okay, well, if I bring this product to market, I know that these are the type of people who are involved in choosing this tool. I know that this is the types of things that they're going to be evaluating me against. And I know that these are the metrics I need to be able to influence to actually earn the right to ask for the order. And so I think it's, and so I think it's just, it's part of the conversations that they're already having with people inside

the, like, you know, as they're doing their customer discovery that every, you know, every good founder, every technologist does whenever they're starting a company. That makes a lot of sense.

Okay, so I want to go back to your past. You mentioned that you were doing business development in that segment, right? Yes. And the reason that I want to go to the segment specifically is because, first of all, I'm aware of the products and I know that when it came out, it's not exactly the easiest thing to go and pitch to someone.

And also, it might have users and buyers that are different. I can see that. I can hear developers talking about segments, i can hear marketeers talking about segments i don't know exactly who's paying at the end so you as like a person who is getting in the company and starts like business development on that like what was the hardest part to figure out the perfect pitch what was the hardest part to figure out the perfect product pitch. What was the hardest part to figure out the perfect pitch? I would say that it was understanding the value metric that mattered for the buyer of Segment. So the first part is figuring out who that buyer is.

And then understanding what it is that they care about that would actually compel them to open their wallet and buy. So in the case of Segment, the people who are downstream to the problem that Segment helps with are people using analytics tools, so product managers, people using marketing tools like HubSpot and Google Analytics and Iterable and things like that. And so at your instinct to say,

okay, well, maybe we should go sell to product managers because they're using Amplitude and Mixpanel and things like that, or we should be using or we should be selling to the people using HubSpot and marketers because they're the ones who are downstream of the data that Segment's providing. But these aren't the people involved in implementing and these aren't the people who own the budget. The people who are involved in implementing Segment is engineering and therefore engineering owns the budget. So it's like, well, my pitch at Se segment is not to the product people and the marketing people. They're

not even involved in the decision. I pitched a segment has to be something that resonates with the engineering leader. And so then it was a function of understanding, well, what does the engineering leader care about? They care about productivity. They care about keeping their engineers happy and they care about costs. And so we have to think about what can we do along those dimensions? How can we influence those such that when we make the case that engineering leader who holds the budget for what the problem that segment solves, that we can actually influence those things for them. And so, and we did, we were able to come up with a story along each one of those because we're able to say like, Hey, this is infrastructure. You'd have to build yourself.

It's going to take this long. It's going to to be this hard here's what it would take to do it with segment it's fast it's less expensive you know here's the boring work that your engineers are going to complain about because what you know the thing that we're replacing is not rocket science it's just boring you know you know boring re-implementation of collection libraries and sdks but now you can just do it once a segment it it's easier to maintain. And by the way, this whole using something like segment means you can dedicate these resources to other core problems for your businesses. When that realization was there, that's whenever I think the floodgates open. And so then everything pivots towards selling engineering and moving the metrics

that matter for them. Are there playbooks in the market? Are there recipes that someone who is an early founder, first-time founder

also, they haven't tried to do it before, something that they could follow? And a second question on that, how much people should be paying attention on

like the content out there around that stuff oh that's a great question so i think there's lots of playbooks but i'll flag one like one task or one playbook that i think a founder should like hone in on and that's customer discovery and customer discovery is what it sounds like it's trying to understand what are the set of problems that basically brought this customer to your front door like why are they even talking to you today what is the business need that matters to them etc etc and the point is like it's you know it's part one which is straightforward which is to understand hey, are we a good fit here? Can we solve this problem?

But two is, this is the more important feature of discovery. It's figuring out if they're actually qualified, if there's enough pain involved in here, that they might be compelled to act and buy whatever it is you're selling. Because in startup land, the most important asset you have is not capital. There's lots of that. And there's lots of people like me who are willing to make investments and make sure that there's lots of capital available. And as much as there's not a bank run. Sorry, SPB joke. I don't know when this is coming out.

And the most important thing that founders have that is in short supply is their time. And so I think that in the early stages, there's an outsized importance for founders to make sure that they're getting the best return on their time. And that's what customer discovery is doing. on the other side of this Zoom call or this table that is going to cause this customer to be willing to act and open up their wallet and try to evaluate and tackle the solution. And they're not just having a conversation with me because they heard me on a podcast and think I built an elegant solution. And so I think that the thing that I would encourage

founders and new company builders to really try to understand and look for content about is like, how do I do customer discovery really well so I can make sure I'm not spending time on the wrong customers? And the last thing I'll say on this is like the one thing that every founder guarantee is going to run into, guarantee it it is there's going to be that logo that is like the one it's a logo it's like oh my gosh lyft is talking to me or like you know procter and gamble picked up the phone and they're doing a discovery call with this guy or this gal and they're gonna think like oh my gosh because it's this great logo i've got to go all in on this and i've got to do everything i can to be a hero and try to get this logo over the finish line but i've seen this

over and over again they don't do great customer discovery they get the logo starry eyes and they spend time in cycles on this customer when this customer is not there to buy i say more often than not if they're like one of these large companies and it's a big company, big logo, you're talking to JP Morgan, you're just the most interesting thing in their day. And so they just want to talk, they want to do something different

than the internal meeting where someone's going to be pontificating for 30 minutes about something that doesn't really matter. And they're just pumped to talk to you and say, don't confuse that for a customer that is excited to buy whatever it is you're selling yeah yeah okay i totally get that i can relate to that but i have a but a big but here okay i'm an engineer like it's all about like in my career

like until today it's all about getting into the flow my career, like, until today, it's all about getting into the flow. No one's, like, I have, like, my notes counseling, like, headsets. And I'm me and the machine. We're becoming one thing, right? And that's it, like, nirvana. I don't have a lot to talk to people. Like, there's nothing inconvenient with my compiler, okay? You said you don't like to talk to people.

No, I don't. I have my compiler there. I have something that I know how to work with and produce outcome. And now suddenly, I have to do something very different, something that's much more fun. Yeah, I agree.

Let's do customer discovery. But doing customer discovery is not exactly a science. It's a little bit of art also. Like you need to build intuition. You need like to hear what the person says and listen behind the words what's happening there, right? As you said, like you have, you're just like the most interesting thing

for someone like at JP Morgan instead of pontificating like during a call, but you're not going to get that like at the beginning because you are not, let's say, that's not a bad thing, right? Like it's, I'm not saying that like engineers have like some kind of like handicap because it's just like a different nature of like how we produce like value and work, right? And it takes time to change that so it's uncomfortable dude like it sucks like it's not nice and it's even worse when you get like on the call and you

start like hearing like no like i don't like that or it doesn't matter or yeah i like it and like after like 10 calls you're like okay are you going to pay now I'm paying well no like why I would do that so what's your advice like to people on like that they get into that they start they feel the discomfort right how they can help themselves like with that yeah that's a wonderful question and i empathize with that tension because if it's not something you enjoy doing it's kind of like well why why should i sign up to do this thing i'd say that like there are multiple routes to get to the information that you need to really understand the commercial design of your business. And one way to do that is to build primary information,

talking to people. But I think that there is still a lot of good content for specific markets and ways to combine that information with your headphones on in front of a computer. And so you're building a data infrastructure product. Like there, you know, there is lots of stuff that you like, maybe I'm building the next, I don't know, like the next DBT called MBT or something, whatever that means. And, you know, there's things I can read about, like how people interact with DBT and how,

you know, how analysts typically, you know, evaluate new tools. And I can think about my own experience. If I've been an analyst myself, well, what was my instinct here? And I can consume information to get to that. But I would say that with anything, the best route to information is primary information. And if you can do it in a setting

that allows you to ask questions and dig deeper, and perhaps you can get there faster. But I would say that you kind of have to do what works for you. At the end of the day, our work is not, we don't need to be mercenaries. We should enjoy the things that we're doing. And so you kind of have to figure out the mode that works. Yep, 100%. All right, one last question from me. Go-to-market like two like major components.

One's like sales and one's like marketing, right? What's the difference and which one should someone like engage with first? That's a good question. Which one should, all right, so we'll define them first and then I'll talk about sequencing. So I kind of think of, you know, marketing as a catch-all for a lot of different things.

I think that in the early stage, the feature of marketing that is the most important is product marketing. I think of product marketing as the translation layer between what problem my product solves and how my product does it and so i think that there's a great inclination there's often an inclination among founders especially those that are technical especially when they've realized that they've built something that's unique and elegant to want to talk about the how right hey we do it this way we build these great you know something under the hood it's really fast we're probably using generative ai in some cool way and it's you know it's really interesting but the thing is like come like you you can only get attention for so long and people don't typically respond to how they respond to what problem is

this solving so why do i care hey this makes it easy to get your data from point a to point b i didn't say how, I didn't say, I didn't explain the technology, but if you care about getting your product from point A to point B, then like, we're going to, we're going to deliver some value here. And so I think that product marketing is basically figuring out the way to talk about the what, right? The problem that we solve. And so, you know, tactically, this means understanding the language that your customers use or your prospective customers use to talk about this problem and how they think about it. And then understand and understanding the language that would actually compel them to act on it, compel them to say, like, you know, I've got these other set of priorities, but this is this seems important. And this is something I want to look more at and what i would you know one challenge i'd put to you know founders or technologists or any product builder is to try to like kind of keep the what out or the how out of the picture right the how

lives on my docs my documentation page and docs are the best place to understand how and any person who wants to go dig beyond the what, they can go find your docs, they can read the how. But if your messaging is a series of how, you're probably not going to get, you're not going to drive urgency. But if I can talk about what, it makes it easier for buyers to self-select,

like, hey, this is a problem I have. Yeah, this is some problem I care about. I got to figure out how to talk about this. Like, hey, let's go read these docs. Like, there's something here. And so I think that's the most important thing on an early stage and like early stage marketing especially because where i see the sequencing get messed up is when founders will say like well i've built the product i'm ready to sell it i'm just gonna go turn on like search engine you know buy search engine ads turn on

you know do my growth marketing and just start sending out emails but like that's going to land on deaf ears if you haven't optimized product marketing basically the way that we talk about a problem product so you know so i would say getting that right is important and then to your question on like you know what comes first you know marketing or selling i think that to do repeatable selling you have to have the messaging nailed because this is about handing someone a playbook. This is how we talk about a product. This is how we position it. And then getting them to go execute that playbook. But I do think that revealing that playbook does take some early reps with customers and trying and failing with certain messages, trying with failing with certain ways that we sell to those businesses. Like we a poc do we not do we talk about pricing up front do we not like how do we

talk about pricing and then and so i would say that like real repeatable selling follows getting the product marketing getting the messaging right but to reveal that you have to do some selling you got to get some reps out in the field. A hundred percent. And it's a very interesting conversation that we're having. And like, we don't usually have these because we like to talk like more like technical people about like the technical problems.

But like, I realized like, that's like why I stole it because like, I'm thinking like as you talk and like, it's very like, That's why I stopped because I'm thinking as you talk. It's very provocative for me too. So what I wanted to ask actually is, you said about product marketing and the how, the difference between the how and what problem we are solving, right? And I would like to ask you,

is this true even when we market developers like if our audience is like developers do we again like need to go out there and like talk about the what we are solving or focus more on the how and the reason like i'm saying that is because it's very common to hear from developers about the fluff right i'm going to a landing page and it's actually true like we get too abstract many times like in the copy that we use like on the landing page for our product right and they're like okay i'm done with the flap i don't care about the fluff tell me like the dirty details like how this thing works why like you have like features of that the other system does not have or whatever. Or at the end, it doesn't matter.

Developers are still consumers, right? And they have similar behaviors to anyone else. It depends on the market's maturity around their understanding of the problem. And so, for example, ETL. ETL is a category that's very well understood among its buyers, right? And so, or data warehousing, for example. Like data warehousing is a category that's very well understood among its buyers. And in those cases, like you don't have to do you don't have

to talk much about the what maybe in the case you know when five train was coming out it was like hey you know etl with a lot less headaches like okay you know but in those examples your audience is already has a good bearing on the problem that it solved the thing that they would hire your product to do and then you do want to be then you do want to push more of the how forward but i would say that like the balance is trying to figure out like which how matters for driving that first interaction and which how is just going to create too much noise and there's also like there's also another balance here where you kind of want to leave some to be desired right like you don't want to put everything out there yeah because you want to give them a reason to engage because once

they're engaging that's whenever you know that's whenever you have an opportunity to kind of build on that and potentially drive that to a sale if it's a self-service product like it's still the same thing it's like what information is actually necessary it doesn't have to be like all the implementation details doesn't have to be like all the implementation details. It doesn't have to be all of the, you know, what makes this technically better than everything else out there. But the thing that matters is like what is necessary for them to be able to evaluate this tool and make a decision.

And so like if you were to distill that, if I was going to distill this, it is what is the state of maturity around our understanding of the problem that it solves yeah and then what is necessary to get to a decision yeah actually you mentioned five trump always i have like a lot to say right because i experienced like that period of time where like okay building like a product you are addressing let's say technically a well-defined category but the category is like actually like changing or like creating into like subcategories in a way right like because if you think about like what happened with like systems like fivetran

is that we took like the concept of etl and we separated like into two parts. We named it ELT, but actually these systems are more of an ingestion system. The main work that you have to do is to extract data and load data and then we'll see what happens. We don't care about that. And I think it's very interesting to see that with Fivetran, who is, let's say, the winner in this category, because at some point they started implementing functionality close to dbt to allow the transformation part, but they abandoned that. And instead of that, they're like, okay, we have dbt now, we can work, you should be using dbt, not the SQL functionality that like, as part of the product experience. And, you know, like, what was, like, very interesting back then was that

you would build, like, this experience, which is, like, so seamless. Like, you just, like, click a few buttons, let's say, and you start, like, seeing your data getting into your data warehouse. But still, like, it took a lot of time for the market to believe in, like, not the need necessarily, but also, like, this is, like, a sustainable product at the end. But it makes sense for me, like, to pay. Because we're talking about infrastructure here. Like, okay, yeah, sure, it's not like removing a data warehouse and putting a different data warehouse there, but still, it is infrastructure.

It takes effort for a company to put it in and take it out. And people, you know what most people were saying, which is kind of crazy in retrospect? Why you're building this, this is a feature for Looker. Looker will build it at some point. And by the way, back then was the time where, okay, the BI market was, like, really hot, right? And a little bit before, like, all the consolidation was happening. So it's very interesting to, like, even, like, existing categories,

how, like, new categories are emerging. And, okay, going through, through like a new category creation is brutal and it doesn't matter like where you are why did you do that if you are like a YC company you are not a YC company you are going to spend a couple of years where everyone is going to say you are crazy like spending time on this shit right

the listeners can't see this but I'm nodding my head so I don't know it it's... Do you think that like a founder, even if like, let's say, they don't, especially when you're like a first time founder, you don't think in terms of like categories, okay? You shouldn't actually. But do you think that they should try and attach the product to an existing category even if it is going to form like a new category or like go from the beginning into like nowhere like something completely like different? Like one day Gartner is going to attach their house category and we'll be proud we did this this is the question that faces just about every innovator i think that the nice thing about the nice thing about there's pros and cons for both

right and so the nice thing about stapling yourself to an existing category is your customers already have an anchor from which they can start to evaluate you as a product. And so we'll come back to like the five trend days. It's like, you know, we are an ETL tool, easier to use, right? We'll just kind of distill it like that, right? And so it's like, that's kind of the anchor. I'll speak to, I'll speak to segments journey here. And as a way to like make, like elucidate some of the tension here so a segment define or attempt to define a category called customer data infrastructure right you know one one way to simply collect

the events that your customers are generating across all your properties and then send it to all the tools where that's used right it's infrastructure product just moving data around there was an existing category called cdps customer data platforms and you know there's one change of you know one change of words at the end but these are like fundamentally different things and the cdp at that time had really been defined as you'll call it like the live ramps you know shape of the universe which is like one place to store all the data that you've bought about users on the internet and that you can use for marketing, et cetera. And Segment, at the time, we were very explicit.

Like, look, we are for first-party data, and we are about moving data around. We are not like this data intelligence layer. We are just really high-performing pipelines. And so we're like, well, we're going to define ourselves as customer data infrastructure, customer data infrastructure. But then when you go out to the market and you're like, hey, we are CDI, customer data infrastructure. We don't need that.

I haven't even heard of that. Because everyone had been building this stuff internally themselves, and they didn't realize this is a problem they have. And it made it really hard to get some of those early conversations going. But we were very adamant for a long time saying, look, we don't want to be associated with this category that has a lot of baggage. But slowly, the category definition started to change. And then all of a sudden it was like, OK, well, it's the category moved.

The CDP moved a little bit closer to us. And customers are now raising their hands thinking we kind of need this version of a CDP that's a little bit looks a little bit more like segment. And so then it was like, OK, we're going to re-anchor ourselves to CDP, and then we're going to sell them that category and build on that demand. And then we'll use the sales cycle to change the way that they're thinking about the definition of this problem. And so the challenge of that is your customers come with like a list of things that they're going to evaluate this product against.

And you're saying like, look, let me change the way you think about this problem. Let me see if I can change that list. That's a hard thing to do. But so is building a category and defining it from scratch yeah you know in the case of actually doing category creation you know i think there are ways to do it it's not easy you have some tactics that i've seen work and then ones that i've seen work effectively are defining like a very like straightforward vocabulary for those for that category and then lots and lots of repetition someone who i think has done this well in the data space is to potentially resonate with this audience would be bar moses at monday carlo data yeah your data observability and data quality if you've never heard those two terms together you you can kind of like,

you know, you can kind of instinctually think like, okay, I kind of think what's going on here. I know what observability tool is. You put data in front of it. So I think I know what's happening. And it wasn't something that people were talking about, at least the way that they are, have been for the last few years,

you know, six, seven years ago, right? Like it wasn't a thing at all. But I think one of the things that Barr did well is hired a content marketer very early in the company's journey. And then on a weekly cadence or more than that, there's new content about data observability, data downtime, data quality. And they just drove the, that language over and over again.

And then eventually the category starts to emerge. And so I think that like, I think there are tactics to do that i think for i think what gear mode did with for sale and creating a you know category around a cdn for react or for react components which talk to any engineer you know seven years ago they're like you're i won't use bad words but you're you're crazy yeah and then all of a sudden he's not the thing that he did was he brought the market forward by being out in front and center and talking about this future version of the world and getting people excited about what the world could like if you are designing your applications in this way yep and he did it with repetition and so i think that like category

creation really depends on having like one of the core features of category creation and do it well is a lot of repetition and a willingness to be out in front and center and kind of become like the spiritual thought leader for that movement. Because it is a movement when you're creating a category. If you're not able to do that, then I would think about like what can we anchor to, you know, without too much risk of being associated with you know kind of getting into the wrong you know evaluations but it's a trade-off it's a trade-off the whole way yeah yeah 100 and i think at the end like it has it has to do with the founders right like you need and there's no wrong and right here it's not like you have to be like a category creator or you don't have to be a category creator but i think it has a lot to do with also the person that they get involved, their personalities, their communication style. All these things are super, super important,

in my opinion, in the founding team that you have at the beginning. It might happen later on, maybe, but I think that's very rare. You need to have this thought leadership at the beginning. It might happen later on, maybe, but I think that's very rare. You need to have this thought leadership at the beginning. And there are examples like that. We can see with Modal, for example. You don't even have to use the product to know about the product because you have someone who is in the forefront out there talking about not just the company and the product and the technology but also everything around that. And you have to be that person, you have to be able to do that and not everyone can do that and that's fine. I think the most important characteristic is that you should have, as a first-time founder,

just to be honest with yourself. It's okay if you don't feel comfortable going and creating a category. There's still ways to go and succeed. There's no one way or another. Something is more glorious than the other. Cool. One last question for me.

I know. Keep them coming. Yeah. Pricing. Pricing. Yeah. That's like another, I think,

very interesting topic, especially like for first-time founders. How do we price? And most importantly, like how do we iterate on pricing? I think like the biggest fear people have is that the moment that you put your price out there,

then it's like we can't take it back. We cannot change it. It's like something difficult. It's something, I don't know, some people might feel like they are cheating right if let's say they put like 10 dollars and tomorrow I make it like 20 dollars or like 5 dollars right I have my opinion on that

I'll keep it for the end but I'll share it I'm very opinionated on it you always fight at the end there's no way to not fight about pricing when you start a company with your founders or whoever else. You're bored. You will have discussions about that stuff.

You cannot avoid it. But I think there are ways to enjoy doing it. But I want to hear from you. So what's your take on pricing? So I'll react to the second thing you said, and then I'll answer your question around pricing. The statement you made around once it's out there, you can't hit the undo button and how do you iterate?

I actually think it's entirely false. I think founders have an overinflated or even larger companies have an overinflated view of how aware the market is of what they're doing and how they're doing it and i do think that you have the flexibility to change pricing now could like a company at aws scale you know turn around and say we're going to change our pricing model and then the metrics for how we're doing it no i think the world would probably unfold at that point yeah but I think there is a point that's probably higher than what most founders believe about. We'll call it, if you're still a private company, chances are you can probably still iterate pricing with very small implications and no one cares.

So I do want to say that there. And then I will say this, you know, on that point, founders also need to be willing to iterate, be comfortable iterating into perpetuity, meaning, hey, I might have had the right pricing model today. That actually could be the wrong one in three years. And so I think there needs to be willingness to look at it and be willing to like adjust that. So let's come back to your question around like, well, how do you price? I would say there's probably like three things that i would consider in this one is like what is the unit of value or the value metric for like that my product creates and so

like and so you know for example if i'm i don't know if i'm an infrastructure product and you know the unit of value here is like well i could build this thing internally or i could buy this from you and, you know, install it in a month and then it's great. I'll never have to deal with it again. The unit of value is not number of users, right? We're not doing user licensing there. And so I would and so I think value is one. I think that also, you know, I'm going to come back to the statement I made at the very beginning of this podcast, which is like, how do your customers want to buy? If your customers, if the way that they buy all of the other tools in this category and all in the way that they think about buying infrastructure is on, I don't know, a number of nodes or API calls to come in and offer something that's completely different than that.

Unless your customer feel like has a lot of angst with the way it's currently priced. And they're just like, I hate this. This is the end of the world. If I see another bill for API calls, I'm going to die. Don't try to get too creative because otherwise you'll induce confusion that could be unnecessary for your customers. And there's just some level of comfort that you just want to operate around. And then I would say like the, you know, the third thing is make sure that whatever your pricing is it's not going to disincentivize growth and disincentivize consumption yeah so secondly i mean we went through

like a this was like a difficult part of the journey for the company which is like how do we capture the value that we're creating for our customers and you know the you know one iteration we thought about api calls but these are really hard to predict for customers and if i can't capture the value that we're creating for our customers. And, you know, one iteration, we thought about API calls, but these are really hard to predict for customers. And if I can't predict what I'm going to be spending with you, I don't feel comfortable buying your product because it could just surprise me. And you also get in a situation where you're disincentivizing some bit of consumption and we don't want that, you know, we don't want that as a company. And so then we thought to ourselves, like, well like well you know we ended up settling on this thing called monthly tracked users and best way to think about it is if i'm using segment and i have 100 users the way my pricing is dependent on the

number of users that i have right in a given month and you know that's that you know that worked pretty well for us but you know come back to the thing i said earlier which the value we create is like basically moving data around. We're solving a data infrastructure problem, simplifying that. And that doesn't necessarily

always correlate with the number of users. And so we might have had companies that might have been using Segment to move data from one source to two destinations, but could have had,

you know, millions and millions of users, like a consumer product. And under our pricing logic, they'd be spending way more money than they had the capacity to spend. But then we could have big Fortune 500 companies using Segment that are B2B companies

and have very few end users, call it a thousand end users, but they could be moving data from a hundred different sources to a 100 different destinations. And so the value that they're capturing is outsized relative to the number of users. And so I don't know where the company,

how they're doing it today. I've been there for a while, but it was a tough problem. And so I give that example, and I'm hopefully not revealing too much, but I give that example just to demonstrate that there's not obvious answers here. And, but you have to be willing to like iterate and ask the hard questions.

Make sure that you're capturing the value that you're creating for your customers. Yeah. No, I totally agree with you. I, okay. I'll give my opinion like on pricing. First of all, pricing, like as everything else that you do like when building like your company you have to iterate and yeah you have to be bold with like making changes to be honest and well i think like people get wrong at the beginning is that the first time is that

pricing somehow is something that you know it's like too important for the market out there. But like the reality is that like when you're like just starting, nobody cares about you. And the moment like you get that, like it's a very liberating like realization. Like nobody cares. Like not even like the people that are using you already, they probably don't care.

Most people they buy, especially when we are talking about infrastructure products, right? You won't like to take it, run it, and you don't want to care about it. That's why you're outsourcing the infrastructure to someone else. Not because you won't like to be on top and pay attention, pay attention on it. Like, if that was that, then you would be watching Netflix, not, like, playing with data info. So, that's another thing.

The other thing is that, like, when it comes to pricing, I think what is, like, super important is, like, pricing has to be simple for the customer to understand, right?

Like, anything that's, like, too complicated, it's an indication that, like, there's something there that we don't get for your customer, right? Like, and there an indication that there's something there that you don't get for your customer. And there are playbooks there. I like what you said at the beginning about

how you price and the model that you have. My rule of thumb, for example, is that, is this a productivity product? If it is a productivity product, yeah, you should go and have a seed-based pricing because it's very easy for the people out there to calculate how much they are going to invest in you and how much to expect to get back. Every new Salesforce account is a new salesperson. They can

almost quantify exactly each dollar that they pay on Salesforce, what will bring back. And it works for that. Can you do that for data infrastructure, for RDS? Can you imagine RDS with seed-based pricing? I mean, Splunk does it, I think, but in case Splunk is unique, let's forget about them, okay? No comment. Yeah. But you can't. You need to have like some kind of like usage based like pricing right and that's where like things i think start like getting complicated

because what people don't understand is that calculating like and figuring out how to charge might be complex but you have to hide these from your customer. And the best example that I can give about that, and that's because probably also my electrical engineering background, is like your utility bill for electricity, right? Like the process of calculating the price of electricity is extremely complex. There's a lot of forecasting happening there. Like it's super, super complex. But you as a consumer,

you don't have to know anything about that. You know that you are paying this amount of dollars and if you connect this thing with a heater, you can see the value out of it. Software is, let's say, more complicated, but that's where we should aim to. Like, that's what our North Star as, like, people that build companies on top of technology should be, right?

My only, let's say, like, what I don't like that much, like, when people, like, companies try to gamify the pricing. And I think we see that a little bit, like, with, like, the credit systems and, like, all that stuff, which, yeah, like, they have their own purpose, but there is also, like, a little bit of gamification that is happening there. So, anyway, it's a huge topic, but I can keep talking for, like for forever, obviously. I'll add one thing to the user licensing. So I think one important feature of a user licensing model is making sure that when user one logs in,

that person's experience is unique to them relative to user two. Otherwise, you will have people sharing licenses. And for a product like slack like i log in it's way different than whenever you log in and it's going to be it's going to be unique but like i don't know there are tools that not to reveal anything but there may be tools that you know vc firms pay for that give you access to research or data or things like that i log in it's the exact same as you i'm not going to pay for two licenses you access to research or data or things like that i log in it's the exact same as you i'm not going to pay for two licenses yeah i think that get figuring out how to like

create unique user experiences is a way to like command pricing there and then also and then i'll say this like you know trying to figure out like what the ceiling or how much you can trade really comes down to understanding what measurable value you're creating for your customers yeah and so you know i kind of bucket things and bucket products into two buckets one is there's i can't measure value but you kind of know when you see it and then there's the value that i can measure and you know as an investor tend to just stick in bucket two because bucket one is typically a religious movement.

I can't predict those. So for example, bucket one products, we're at Slack. At the seed stage, whoever invested the seed actually knew who it was. They did great. But is there any way to know that this form of messaging

was going to transform the way that companies communicate? No, right? But if you were to go to any CIO who has a $10 million Slack contract today, if those exist, and you say, what is the value of this organization? They'd be like, my users are going to be furious if I take it away. Yeah. And we have to have it. I don't know the value.

You can't measure it, but it is. We need it. Those are really hard to predict. In the second bucket, and those are also hard to price for that reason too. When you develop pricing power, the more religious converts you get over time and the enthusiasm with which they need that product. The former bucket, which is value that I can measure and value gets measured on three dimensions typically. Does it influence revenue in some way? Does it improve profitability in some way, meaning reduce costs or avoid some costs?

Or does it remove some risk? Because risk is measurable to a lot of organizations. And the nice thing about understanding the value that you're creating is you can measure it. Ah, if you build this yourself, well, it's going to take four engineers. Those cost, you know, $150,000 a well, it's going to take four engineers. Those cost, you know, $150,000 a year. And it's going to take you eight months. Well, we can do that math to figure out however, how many hundreds of thousands of dollars or millions of dollars it's going to cost you, or you can buy from us and we're charging, you know, 25% that. That is a value

trade that I can make all day. And I can communicate that to my customers. and the job of the founder the job of the person like building a product they're selling is to figure out like like how explicitly can they communicate that value and how close can they get to the top of that value trade well if i can communicate a million explicitly can i ask for 900k here right like like how can i exceed that ceiling is there some other value that i'm creating that like a premium this customer is willing to apply? But trying to figure out where you are in terms of that measurable value is really the job to be done. And that's how you think about pricing. Yeah.

Well, Chase, this has been a fascinating and super helpful conversation. I have kind of one observation as I've been sitting here listening and want to ask how folks can connect with you. But it's kind of towards the beginning of the show, you talked about how can engineers learn to go to market and talked about expanding the scope of the problem from just building the thing to also getting it into the hands of the right people. And then you talked about applying the engineering brain to that whole problem, not just the product. And one thing I've been thinking about is we've been talking and the pricing conversation, we talked a lot about iterating, right? And I think that's like, that's a piece of engineering that should directly be applied to go to market

is like ship and iterate and ship and iterate and you'll get better and better as you go. But I think that's a little piece that engineers can hold on to that's like very familiar and has just been, that's been going through my head as we've been talking. Beautifully summarized. But that's it. Folks want to connect with you. How can they do that? I have a very easy email.

Unfortunately, it's composed of words that are easy to spell. It's chase at vertexventures.com. And then I'm also on Twitter and it's just Chase Roberts with no vowels. You got to keep it nice and succinct. C-H-S-R-B-R-T-S. So we'd love to hang out in both forms. Great. Well, Chase, thanks so much for spending some time with us today. Awesome. Thank you. We hope you enjoyed this episode of the Data Stack Show. Be sure to subscribe on your favorite podcast app to get notified about new episodes every week. We'd also love your feedback. You can email me, ericdodds, at eric at datastackshow.com. That's E-R-I-C at datastackshow.com. The show is brought to you by Rudderstack, the CDP for developers.

Learn how to build a CDP on your data warehouse at rudderstack.com.