#19 Product-driven Culture - (Founders Fund) Leigh Marie Braswell | Slush 2022

Hello. Thanks, everybody, for coming to the talk. Super excited to be presenting here at Slush and so grateful to be a part of this amazing event. Yeah, so a little bit about me. I'm a principal at Founders Fund. I focus primarily on investing in enterprise software companies, and I have a particular interest in developer tooling as well as data and ML applications and infrastructure. So today, I'm going to be talking about fostering product-driven culture. So what is product-driven culture? Honestly, just kind of wanted to pick a mysterious talk name to get everybody to come. But jokes aside, I'm going to be sharing some tips that I learned through my product management trial by fire at scale. So You know, this is going to be a bit anchored to my experiences being the first product manager at Scale, but hopefully can be generalizable to different people's, you know, experiences with your own companies. So I started at Scale when we were just a few people serving a few customers in a tiny little office. And ultimately, when I left, it was a few hundred people. The company was worth $7 billion, and we were serving a lot of people that were doing machine learning in production today. So when it comes to product-driven culture, there's some commonalities in companies that you might describe as product-driven. They're obsessed with their customers, they're obsessed with sort of their own team building, and they're obsessed with measuring their own success. So I'm going to go over some patterns today that these companies sort of exhibit to create great products again and again. So the order of this talk, it's essentially sort of the different decisions that you're going to face as you end up building a company. So the first part of the talk will be on the role of engineering. So when you're going from 0 to 1, when you're going from nothing to something, and you're sort of, you know, hiring engineers and building the first version of the product in pursuit of product-market fit. The next sort of section will be a question I get asked all the time from portfolio companies, You know, when do you hire a product manager? How do you evaluate them? And then also, you know, how do you not only evaluate them in an interview setting, but then when they're actually at the company? And then, you know, why do you hire a product manager in the first place? Like, there's sort of trade-offs when you hire someone. The next section will be on early product manager mistakes, coming mostly from my own experience. But basically sort of mistakes that are common at the earliest stages with product managers. And the last section will be sort of challenges that you face as you grow the engineering and product organization. So when you start a startup, it's a very exciting and precarious time. I remember when I started at SCaLE, I was very energized, but also kind of terrified, because a lot of the decisions that you're making are life and death. You only have so much time to figure out how to build a product that customers will find mission-critical and get them to sort of pay for the product and have a sustainable business model. So the first sort of group of people that you're going to hire are engineers. And they need to be— this is sort of a trade-off that I talk about a lot with my portfolio companies, but they need to be very self-sufficient. So these engineers, they'll be making sort of product decisions in their day-to-day work. You have the CEO who is kind of the source of truth and product vision at the company. You might have some other technical founders that tend to help with product requirements. and sort of, you know, managing the engineers. But ultimately, you need to kind of create a team that is self-sufficient and able to kind of construct the sort of product details for themselves. There's another trade-off to be made here. A lot of times, I hear from engineers and engineering management that maybe you might want to hire contractors to support part of the first team. But there are some trade-offs in that contractors can be really good at sort of self-sufficient tasks, but then when given sort of the day-to-day of a startup, it requires a more individual buy-in that can be challenging to get from somebody who's not a full-time employee. So there's definitely sort of trade-offs. And sort of thinking through, do I hire full-time, do I hire contractors, and how senior of engineers do I need to hire? Ultimately, these engineers are going to be talking a lot with your customers. So they'll be able to unearth a lot of pain points. But ultimately, the CEO will be making the final call. So something that I recommend a lot when different people come to me and say, hey, Leigh Marie, should I go work at the startup? The number one thing that I'll tell them is, do you trust the CEO? Because ultimately, the CEO will be the first PM and will be making the product prioritization decisions. And that's kind of the disagree and commit triangle. Ultimately, you know, I think the kind of saying goes that great product decisions aren't made by a committee. They're made by sort of an individual, and I think More often than not, you see that being the CEO. And then a last point that I want to talk about here is I think this is the most important time when it comes to in-person versus remote and the sort of decision around that. So I think at the very earliest stages of a startup, communication is paramount. Communication among the team and then also communication with the customer. And remote makes that a lot harder. So if you are a remote team, It needs to be for a really good reason. So perhaps, you know, there's a necessary talent reason for you to be remote, which makes sense, but it's going to be sort of a harder process of managing different communications. So just a sort of trade-off to keep in mind, but ultimately, you know, either way can work, just sort of— Something to keep in mind. All right. So, I'm going to talk through a case study. I'm also going to get some water. But basically, this is a very famous team who did not have product managers for a really long time. So, Stripe actually, it was 5 years before they hired their first PM in title. And before that, of course, they hit product-market fit, And they were, you know, sort of doing product management, but it was the CEO and the engineers rather than sort of people, product managers in name only. So Stripe, yeah, it was past their Series C, past the 50th employee mark. They had launched multiple products, and it was kind of so controversial at the time that Patrick Collison wrote a piece on like sort of explaining the decision to not hire product managers until that time. And kind of his reasoning was the engineers can do the product management themselves and they enjoy doing it. A lot of the engineers that joined Stripe very early days, they either were previous founders or they had experience in design and biz ops and partnerships, but basically, sort of a background to be able and to be happy talking with customers and getting pain points from them. And so, ultimately, it was, yeah, quite a while, and I think there's some other reasons, too. Stripe, it was quite a developer-focused product, or I mean, still is, and a fun fact is that actually half of the engineering team of Stripe in the very early days used the product as a customer before joining. So that was kind of, they actually were the customer in a sense. And then, yeah, let's see. I guess there's some other sort of trade-offs to illustrate with this example. So there's the trade-off here of, you know, when you hire your first PM, you inherently sort of, there's another step in the communication chain versus when you just have engineers. If you're an engineer and you're talking to customers and you're getting paid pain points, that you can do that and then you can build. So there's no information that's lost. Once you hire a PM, you inherently introduce a little bit more of a step in the communication chain. And yeah, it's just something to kind of keep in mind. And then also some engineers, if they're more product-minded, enjoy sort of defining product requirements themselves. So let's say you're thinking to yourself, when do you hire a product manager? I think it really depends on the stage of your company. If you're pre-product market fit, product market fit, or in the hypergrowth phase. So let's say you're pre-product market fit. In this case, you might not really even need a product manager. But let's say the CEO is too busy to project manage, Let's say you're pulling on multiple product threads and the eng lead or the CTO can only optimize one of them, or, you know, maybe the engineers just are overloaded, can't communicate with the customer as frequently as they would like, don't want to share updates as much. Maybe you do want to hire a product manager. However, in this case, it's really kind of a product manager in name only, and it's— they're going to— their functional day-to-day is more like a project manager. So essentially a project manager to the CEO's vision. They're sort of managing the engineering processes, maybe they're doing some basic analytics, dashboarding, defining metrics, but ultimately they're very focused with execution. So in this case, you know, I think there's a few paths in terms of hiring somebody. You can either hire someone more junior. This is something that people talk about a lot. you know, comes in with the understanding they're a project manager. You can transition someone internally, so an engineer perhaps, like me at scale, or you can hire someone more senior and experienced as a product manager, but with the understanding they're currently not doing the traditional product role. Trade-offs to all of these, in the former cases, basically you might have somebody who anchors on being sort of this execution project manager, and when the time comes, they are not able to transition into more of a product role or don't really know what that means or how to do it. But in the latter case, if you hire somebody and they try to be a product manager too soon, then they might butt heads with the CEO and sort of slow the team down by having different sort of product visions. I think at the time when the traditional product management skill set becomes really handy is product market fit. So once you've hit product market fit, that basically means you have customers that are using your product in a mission-critical way, that are hopefully paying for it, and in a very ideal case, you're able to acquire customers for a lower cost than their long-term value, or you have some line of sight to great unit economics. So in this case, the CEO probably has a lot on their plate, the engineering team has a lot on their plate in terms of scaling the product that's working, and there's this risk that a lot of context gets lost. So a lot of product context and customer context. And what the product manager can do is sort of unify the team, through defining the customer personas, the use cases, and then also just the broader business context, and can sort of communicate with everyone, make sure everyone's on the same page, make sure the customer's on the same page, which is quite important. And in this case, you might have— I think the easiest way to think about it is there's sort of 4 risks. to product building. You have the value risk, so will people buy your product? You have the viability risk, does this sort of product work as a business? So for example, like compliance, things like that. You have feasibility, which is can the team build the product? And then usability, which is can the customer use the product? And this sort of is sort of the framework given by Silicon Valley Product Group. Product managers value and viability are the 2 risks on their minds. Design is usability and then engineering is feasibility. So that's, I think, kind of the easiest way to think about what the product manager is going to be doing at that stage. So ultimately, the product manager is going to be talking with leadership, talking with customers, talking with cross-functional teams, getting all those ideas together, and then sort of focusing on product or like problem themes. And then sort of working with engineering product and design or EPD to define sort of a very fine-grained roadmap of engineering task. And then sort of the next question on your mind might be, well, how do you find this person that's going to do all these great things once we've hit product market fit? And I think there's a few different options that you have. So one, you promote somebody internally. Or 2, you find someone externally. Both can work, and I've seen both work really well. I think in both cases, the important things to really think about are, can this person handle uncertainty, and does this person have agency to affect change? So that's more of a personality type than, like, a particular company structure. And at Scale, we actually call this running through walls and having a bias to action. as like a sort of culture value. And so ultimately, like, you would love to have a PM that kind of checks off all the boxes when it comes to product management that, you know, has great product taste, knows all the best practices when it comes to processes and communication, knows strategy, can make a dashboard, can do all the metrics. But in practice, what you're probably going to find is you want to hire a person that can spike in one or more of those areas, and then learn how to do the rest. So you really want sort of an empathetic learner that is going to have the curiosity and drive to become a world-class expert in a particular domain, which is what you really want out of a product manager. And then sort of the last stage here is growth, when you have like a core product that's working really well, and then you're starting to think about product expansion. And at this point, you're probably going to hire multiple product managers, A sort of good heuristic here is 1 to 10, so 1 product manager to every 10 engineers. If you have a more technical product, you're probably going to want more project managers versus product managers because the engineers have a lot more say in the product roadmap. But ultimately, you know, you start— as you start to specialize your teams, then you're going to start to specialize your product managers. So maybe you have somebody from a business background, from a growth background, from technical background, design background, and they sort of work with more specialized teams. Hopefully they complement each other and are able to sort of educate each other. And then the other part here is you might also start to think about hiring leadership PMs. So people that are managing PMs, and I think the main benefit here is that CEOs and founders are really good at thinking about short-term, and really good at thinking about the very long vision. And then these sort of PM leaders are really good at filling in the medium term, so a quarter to, you know, a few years ahead. Case study here, my experience at Scale. So I joined Scale, was one of the first engineers, and then transitioned over into a product management role. When I joined Scale, like, I already knew that I wanted to be a product manager. I had done an internship, and sort of the role really resonated with me. But when I joined Skill, it was sub-10 people, so they didn't need a product manager, as we kind of talked about in the slides before. So ultimately, I joined as an engineer. I started taking on more product responsibilities as the company grew. So started project managing, sort of helping with the Scrum board. And then as, you know, sort of the business started to take off, there was a clear opening for me to talk to customers, to learn more about the autonomous vehicle industry, analyze competitors' products, you know, start to work with the sales and support teams and support them and sort of make sure that their requests were getting done by engineering, things like that. And then as Scale hit product-market fit in the image annotation product, and it became clear that LiDAR 3D annotation was sort of the next product, it made sense given the product surface area for me to become the product manager of one of those products. So essentially, like, you know, it took me maybe 2 years after I started to go from engineer to PM fully, the title, and then also, you know, stopping coding, which is always challenging. But sort of made that transition. And SCaLE actually ended up doing that for a lot of their employees. So most product managers in the first 4 or 5 years of Scale were people who transitioned from engineering or ops. And that has a really great benefit in that you have a ton of context. You can hit the ground running as a PM. But then the drawback is that because there's sort of a lack of outside product management experience, best practices, it's hard to unify them, and processes can kind of be a little bit all over the place. Now Scale has a great mix of sort of people from internally and then externally, And I think that works pretty well. So next slide is common PM mistakes. So I've made a lot of these and kind of wanted to walk through them so that you don't make them. So the first mistake I made was not sharing enough context with engineering. I think it's really tempting as a PM to be sort of a barrier to all of the sort of noise and hope that None of your engineering team has to context switch. But unfortunately, when that happens, you end up micromanaging engineering because they have no product and customer context to make product decisions. So quickly learned that it was a lot more efficient to sort of expose engineering and other teams strategically to the product spec process and then to customer feedback, which ultimately led to more productive brainstorming, And sort of faster iteration times and more productive product building. The next mistake that I made, mistaking motion in progress. So I think this is really tempting as a young PM in particular to want to build new things. So, you know, you'll see like a customer pain point and you'll want to sort of go after it, build a new feature, build a new product. But that's not always the most productive thing to do. So very frequently, it's a lot more productive to have the customer stack rank all of their pain points and, you know, only build some— a new feature and product when that's the most acute need, and it also makes sense from a holistic business perspective. So, you know, it might be a more productive exercise to iterate on a feature that you've already built, maybe like a metric, is it completely there yet? versus just building something completely new. And sort of creating a culture that values, you know, PMs saying no and values PMs focusing on the core business is very important. And then the last sort of thing I didn't realize for a really long time was I thought I was sort of doing something wrong when processes kept breaking. And that's actually something that's expected. As a company grows and also, you know, from company to company, processes are different. And they should be changing. And you should audit your processes and make sure that they're keeping people productive, that they're successful. And you have a lot of different processes to manage as a PM. You know, pre- and postmortems, products launching, beta testing, prototypes, customer calls, making sure that all of this is productive every few months is something that was not obvious. I thought you could just make a process and if it was sustainable enough and easy enough, it would be fine in the future, but you need to revisit. So now I'm going to walk through when you're growing the team and sort of chaos is reigning, which is a good thing at a startup. If it's chaotic and you're growing, that's a great problem to have. But you're going to be faced with a lot of decisions about both the product building process and the product team building process. So first sort of thing, goal setting. So in general, you know, as a startup, you want to keep processes lightweight. You want to bias towards building things very quickly. But then at the same time, you need to have metrics that each team is working towards as a North Star. And sort of when you're thinking about goal setting, you start at the very basic level with task tickets, with sprints. So like you're planning 2 weeks in advance, you're putting tickets into a 2-week bucket. Eventually, you'll move on to a one-pager, sort of like maybe a description of a more complete product. And then you'll maybe go to a PRD, which is a bit more sort of fleshed out in terms of all the different things that are going to come out of a product. And then the intimidating OKR, which— so there's actually going to be a talk later today. Steven Jacobs is going to give a great talk on sort of the details here. But essentially defining objectives and key results for both your company and then each team. And it's also very important to think about sort of the vision, and that's pretty easily communicated when you're a team of 10 in one room, but when you're a growing company, having a vision doc with very clearly specifying what industry you're going to dominate, who your customer is, what your moat is, what your advantage is, is very important. to make sure that everyone's on the same page. Org design, super fun topic. Something that probably, like most processes, should be revisited at somewhat of a frequent cadence, to not surprise anybody. I think one decision that you have to make pretty early on is how interconnected EPD is going to be. So do you have separate engineering, product, and design orgs, or are they combined in some way? Advantages and disadvantages to both. If they're combined, you sort of move faster. You have PMs reporting into directors of engineering, sharing, but you might lose some people's voices in the shuffle, and you might have some people that don't sort of feel empowered to speak up because they're reporting to a different function. On the other hand, you don't want to have these sort of walled gardens of engineering, product, and design that are just throwing things across the wall to each other and not sort of handing off things in a very collaborative way. Customer involvement, so I think it's pretty obvious that you want the customer to be very involved in your product process. But I think there's a few things that you can be very intentional about. Intentionally, you need to talk to customers, you need to see how they're using your product at some frequent cadence. Personas can be very useful here, so having product managers formally write out who is the user, you know, how are they using the product, why do they care about it, and making sure that we're not making assumptions about customers. And then, you know, how much do you continue to include customers in the roadmap. Maybe you have some sort of advisory board, maybe you have like a public roadmap online, but there needs to be sort of an understanding that every request won't get done and that ultimately it is a product decision sort of how much to go with exactly what your customers say. And then lastly, new product bets. So you should always be thinking about your next act as a company. It's a bit existential in that if you stop thinking about product expansion, your customers can potentially, or your competitors can potentially catch up. I think a great example of a company here is Scale, where even from day one, Alex, the CEO, was talking about how Scale was an ML data platform, even when the only product we had was a data annotation tool for images. And so it was always sort of a North Star that we kept in our minds as we grew the company. And now, You know, it has a ton of different ML products. And then another good example of a company that does this really well is Rippling. It's another Founders Fund portfolio company. They've sort of designed their whole organization around this idea where there are these small autonomous teams, lots of startup founders. I think they have 50 startup founders at their company. And they have a very modular architecture and very lightweight process so that each of these teams can run very fast together. So took a lot from different product leaders in this talk and highly recommend that you check out their material, whether it's podcast or Twitter or whatever. And yeah, really do appreciate your time. Hope you learned a few tactical things and would love to talk more afterwards.