a16z Podcast - a16z Podcast: How Founders Hire a VP of Product

Episode Date: November 10, 2017

Hiring a VP of Product -- especially as the founder of the company -- can almost feel like handing over your baby to someone else to hold, observes a16z executive talent team partner Caroline Horn, who hosted an event on this topic earlier this year (which this podcast is based on). Featuring Vijay Balasubramaniyan, founder/CEO of Pindrop; Shishir Mehrotra, founder and CEO of Coda; Gokul Rajaram, Production Engineering Lead at Square; and Alan Schaaf, founder/CEO of Imgur -- and moderated by general partner Martin Casado -- the discussion covers everything from what the VP of Product role really is to how to hire and integrate it into your company. Because if you're going to be handing your "baby" over... how can you avoid common pitfalls? And know that you pick the right person for the job?

Hi and welcome to the A16Z podcast. I'm Caroline Horn, and in this episode, we talk about how founders hire a VP of product management. A lot of founders tell us that this can be the most emotional role to hire. I often say it's like letting someone hold your baby for the first time. So in this conversation, based on an event held last year, we talk about the challenges of what to consider and the process of hiring a VP of product management. The conversation, moderated by A16Z general partner Martine Casado, included in the order in which you'll hear their voices. Vijay Balasubaramanian, founder, CEO of Pindrop, Alan Schaff, founder and CEO of Imager, Gokul Rajaram, product engineering lead at Square, and Shashir Mahotra, founder and CEO at Koda. I thought maybe what we'll start with, it's like your high-level philosophy is about product management.

One of the people that I talked to when I was hiring my first VP of product was the VP of products at LinkedIn, Deep Nishart, And he said, a good VP of product is someone who has the brain of an engineer, the heart of a designer, and the tongue of a diplomat. And I think that's, you know, a pretty well-put thing. And if you actually deconstruct it, it's actually very, very true, right? You have so many different stakeholders. You need to corral them all. But more importantly, you need to get shit done, right?

I'll add to that great VPs of product also build great teams, right? So hiring is the other part of it. But ultimately, you know, in terms of scope, I almost view product as a support role to all of these functions, right? Sales, marketing, customer success, your actual customers, engineering. And so it's a really, really important role. There's different types of users. There's the marketing team. There's the engineering team.

And basically every team in the company is going to want to have a stake in what gets built. You also have to be really analytical because data is like another stakeholder and you have to really look at the metrics to kind of turn sort of negative retention actions into like positive ones. I actually think there's a lot of confusion on the scope of PM. So I'd love to hear if like you could also kind of like draw scope. I think that would be super useful. The product strategy for a company is driven by the product lead at the company. It turns out that many cases founders or CEOs. They've never actually articulated a clear product strategy.

I think that's one of the most important things, formally articulating the product strategy. And the second piece is shaping or sculpting the product organization. A lot of product development teams are organized organically based on engineers, based on skillsets, based on iOS versus Android versus whatever it is, skill sets, and so on. The right product leader comes in and takes a completely different product-centric view and organizes the team differently. This is a technique I got taught by one of my favorite bosses over a decade ago, and then we kind of adopted it to Google. And basically, the way this works is you say new PM comes into a company, comes into a group, and you hand them a problem, you hand them a solution, you go talk to this person, run this meeting, and so on.

And their job is to execute. And at some point, their job becomes to figure out the how. And they go figure out which meetings to set up and how to organize a team, what the cadence should be, all those sets of things. and early on in people's careers, they tend to grow by growing scope. Like, they get bigger and bigger features. You can manage a feature being built by one engineer, now five engineers, and you kind of grow that way, and the way you do the job changes. They actually have generally the same scope, but they just do the job differently.

I call these the clarity creators, like the number one job of that person is to take ambiguous spaces and turn them clear. And that could be organization, that could be product, that could be strategy, but the way they do the job impacts it a lot more than the scope. So the question is, when do you know you need PM, and then when you need to know a VP of PM? In general, you have two stages. Pre-PMF, a product market fit,

at which point you don't hire any leaders. It's just you, your co-founder, and then a bunch of builders. And so you build for a while. And the next evolution is where the number of engineers grows big enough that it's hard enough to essentially be the product manager. So you hire, ideally get one of the designers or engineers to become a product manager. Again, I have some strong philosophies around

whether you hire your first PM from the outside or whether you make one of your designers or engineers into a PM as your first product manager at a company. What is your strong opinion on that? About 25 to 30 engineers is when you see the first evolution of leadership in the product function, because, A, there's enough engineers that there's many different things. You could organize them in many different ways.

So there's need for more explicit strategy formulation. And finally, there's a team of people who needs a leader where the CEOs or one of the co-founder. Now, one of the co-founders could become the head of product. But then I think the question is, are they the final head of product, or lead of product. Many multi-product companies have gone to the product unit model where there are people leading product engineering and design. Facebook, Google, Square, a bunch of

companies have gone to this model because, in my opinion, it doesn't make sense to have a person who's literally managing three different product units that don't really have cohesion. What are you holding them accountable for at that point? Being a good manager? Not really. You want your most senior executives to be held accountable for direct. results, driving a specific outcome around product. So I think there is a very strong push again in having product unit leads. Because when you have a VP of product or head of product who has three product directors, a CEO quickly finds themselves going directly to the product directors.

So I think that it's also important to note that there's no right way to do this stuff. And I can tell you that with confidence, especially considering that I did the opposite of your strong views. And it works. We had been chugging away out the product for like, five years. And so we had a lot of built-up assumptions. We were kind of a little bit dogmatic about certain topics that we didn't need to be that were probably holding us back. And so having a fresh set of eyes, somebody that actually does also know product management for the first time, did really help. The downside, of course, is you have somebody that doesn't know your product as

well as other people that have been there for a while, sort of making the decisions on what to build. For me, I found it very difficult to hire any position that I hadn't actually done the job. I just found, like, I found, like, really good at, like, hiring things that I had done, and I found it very difficult hiring that I haven't. So, especially for those that are not PMs or have not done PM, that are thinking of hiring, what is your mental framework for hiring? I think one of the most important things is that for any role you hire, companies make the mistake of not listing on paper the exact top four or five criteria they are looking for or skills.

and then looking both inside and outside the company to figure out who the best interviewer is. For example, people leadership and team leadership is a really important part of this role when you hire a people lead. And you might not have a 30-person startup, you might not have anyone who's essentially really good at judging whether someone is a good leader of people or not.

So I would really encourage you to look at your board, many of your board members or investors or advisors. In this case, the first thing that matters is customer focus and empathy. And again, not just your own customer, but really trying to dive deep into how to think about customers, what kind of unique insights they've had in the past about customers. When you give them a product area,

can they actually articulate a winning product strategy that is rooted in amazing customer insights? The third one is people and team leadership. And the fourth one is how to analyze data. So one of the things, again, as part of onboarding, I would recommend, is really getting an account with basically your into your SQL database, essentially getting an analyst account

and starting to run your own. queries because turns out at younger companies there's no analyst role or there's an analyst but they're overwhelmed with a lot of dashboardy stuff so you need to as a product leader come with your own insights so one of the best things as part of your state of the union you present hopefully at the end of 30 days is also a completely new look at the data that the company has that you have 30 days to analyze and understand what this data says about customers about usage about every single thing about the product every single person in the company needs to be an analyst for a company to work effectively. This includes every senior leader of the company.

Any good product person, if they can't wow you while they're sitting in front of you, then that's way below the minbar. When someone is at this level, and I call someone on the team, like for the top level as an example, I call someone on that person's team, I don't tell them who I'm reference checking, and I say, tell me who owned the vision for this thing. Tell me when there was a real hard decision to make, where do you go? When you had to frame how the opportunity was created, where did you go? If you want to figure out the how piece, you say, Did things run smoothly or poorly, and who was it most due to? And so that process of finding information from the network of people is an art in itself,

and I personally believe you have to do it yourself. So lesson number one, I think, is being very, very good at reference checking and having a framework in mind. The second thing I'd say is you have to find a way to simulate work with the person. And there's lots of different thinking on this. One thing we do, actually, this is not just for product. We do it for every function. At the beginning of every interview loop, the person presents for about 30 to 45 minutes. it's actually open to the company.

And the rules of that presentation are pretty broad. Like, we tell people you have 30 to 45 minutes. Make sure you cover your whole background so that it doesn't come up again in every interview. Tell us something interesting, like keep our attention, and give us the best to yourself. Any product person who can't figure out how to entertain you for 30 to 45 minutes is definitely not worthwhile as a product person. And the third part of that, and this is somewhat controversial. I think it's very easy in interviews to do either Home Corps or Wake Court questions. I'm trying to figure out how to bring this product to market.

What do you think? Or you do away core questions. You say, hey, I'm really interested in how you did. Like, I see that YouTube did this thing. Why'd you guys do it this way? Why'd you do it that way? And my view, it both are terrible. The home core questions, you're spending your whole time trying to figure out, well, what does he want to hear? You probably thought about this way more than I have. And so you're not really getting a great calibration. And the other side, you can't separate this person from the rest of the whole company that was around them doing this thing. So I think it's really important to ask neutral ground questions. And I do this for every role. Come up with a bunch of synthetic questions. We're going to build a hypothetical product together, and they can be super broad. Like, one of our favorite ones is you've been tasked to build a tool in the grocery space, and your job is to arm these small grocery outlets with ways to increase customer loyalty. The product can be anything. And we've had people build all sorts of different things. And I think you'll find when you get neutral ground, you can isolate what that person is uniquely good at, which I think is really important. I actually find it really useful to ask the product person, the home court question.

But the way we kind of change it around is we actually do it more offline, right? We spend a lot of time with them in phone conversations, letting them do their research. And at some point through the process, we actually give it to them as a homework assignment. And the really good product leads actually, you know, we tell them, hey, if you thought of what Pindrop needs to do, you know, as Horizon 1, Horizon 2, Horizon 3, build out that product vision and tell me what it is. And we ask them to write it and send it to us. And it's a big advantage because two things happen. One, you start understanding, you know, the company space,

and you start fascinating about what it is to work there. So you really give it your best shot. And the best product leads we've had have built some of the best, you know, vision documents for the product. And it shows two things, right? One is when they write something, there's amazing, you can see the clarity in thought. And then the second thing is when you tell them you want to see what's Horizon 1, Horizon 2, great product leads are phenomenal at prioritizing things, right?

There was one product manager that I worked with, and he used to make lists of everything, and he would prioritize even his kids if his wife allowed him, right? And so, you know, it's one of those things where people who can put that down with that clarity of thought and give their first shot at a prioritization, it's a wonderful quality. to have, and that's the way we hire. Product market fit is kind of everything. If you have it, and if you don't have it, it's kind of hard to make it work type thing.

I mean, it really is. And, like, the PM sits right in the central nervous system of product market fit. And, like, everybody in the company, everybody has a vested interest in the product market fit, and everybody has an aesthetic around it, and everybody has a design around it. And so, like, onboarding a PM the wrong way,

if it's coming externally, is a very tricky thing to do and can be very disruptive. So, I mean, Gokal, I mean, I know you talked about bringing it internally, bring it internally, or maybe that's the reason you want to do it internally. But I'd love for you to talk about, like, how do you actually introduce somebody into something that is so sensitive? So there are three phases to onboarding when you onboard a product leader, actually any lead.

First, before they join the company, it's really important that you give them time to meet with their team before they start the company. I onboarded this way at Square, where you essentially send a survey or some way to collect questions from the team or at least the direct reports of the person before they start. because everyone when they hear there's a new person starting that they might not have met during the process has a bunch of questions about what does this mean for me, what is their style like, what do they expect?

And so you essentially collect a huge set of questions and then literally you sit down with the team before you start at the company maybe and gather all of them in a roundtable setting and you just literally walk through and honestly just in a small setting just answer these questions. Especially if you make it anonymous,

a lot of the tension is out of the room. And then you also build personal connections with the people before you start. So I think pre-starting, it's really important to build that rapport with the team. Once you start, again, this is a classic 30, 60-day thing. The first 30-days are all about diagnosis. To diagnose the company, the organization,

the strategy, the people. And so you essentially have a set of standard questions. You literally have four questions that you ask every single person. 30 minutes, you actually send the questions in advance. 30 minutes. Don't interrupt. Don't say anything. Just listen, take notes, and then synthesize

at the end of 15 or 30 days, synthesize and then ideally present a state of the union back to the organization. I think that exercise alone in the first 30 days will get you so much credibility and will be so valuable because no one I guarantee you has ever sat down with these people

and has asked them, what's working well, what's not working well, what's not working well, what you do if you're in my shoes, what should you do what you're not doing? Essentially, these four questions synthesize and then publish it back to the company. Here's what I'm hearing. Very simple, first 30 days.

Next 30 days is where you actually take, the things you're hearing and put them into action. Two things. One, most importantly, org changes. You have 60 days to make org changes. After 60 days you become an insider. It's very hard to make org changes. So the first 30 days you also diagnose not just the company but the people. So based on the insights, based on what you're hearing, based on people who are actually giving you the most insights, there are a lot of good people who are buried deep in the org or are not in optimal roles. Again, people who are maybe in roles where they should not be. You need to identify

and that's part of your job in the first day it is. And you need to make those changes in the next 30 days. You have to. If you don't, you're toast. So that's first. Change the arc. And the second one is do something impactful. Whether you're coming as a senior most leader managing a three-level arc or as someone who's just managing one-level, you need to do something yourself. You need to drive something, a product.

In this case, you need to drive a product change. Why? Because you need to have your team, the company, the CEO, see you in action. You need to show that you can deliver. You can actually drive something. They see your decision-making style. They see your philosophy. They see all of that in action.

So in 60 days, those are the two things you need to accomplish. You sculpt the arc. You make the arc changes, exit people, and then you need to drive one change that people remember. Your first 60 is what people remember, always. So make an impact. Diagnose one state of the union, then arc change, and then one ideally significant product.

If you do those things in your first 60 days, you have enough organization credibility at that point. you'll basically do well. One important thing to add to that, I can't tell you how many executives working for me, advising, so on. Nobody does it. When you show up in the organization,

you have to tell your team that for eight weeks, I'm going to do what the old administration did. You have to do something meaningful. You through 60 days, you haven't done something meaningful. I think it's really important that actually that's a small thing. Don't take the biggest thing.

Like, do something impactful, but it doesn't have to be the biggest problem. Don't show up and in week two say, oh my gosh, like, I've been all built up and I just have to do something. So I published this paper about how everything's screwed up and I haven't gone through the listing tour, but the CEOs give the person some space. And we hired this person because there's some problem. Like there's something going on.

And that person showed up. It's been three weeks and haven't solved the problem yet. Like that's crazy. And you have to let that be because if that person's credibility gets ruined, not only is going to – like, you probably hired that person thinking there's a huge problem. Your organization, maybe they don't think that's such a problem. Maybe they've got something else that's worried about. This person is going to assess that. They're going to come back and tell you what these problems are.

I had to get rid of a guy that was a fantastic high. and he got onboarded poorly, and he flushed out in six months because he just lost his rapport by not following that process. And so I think that I could not emphasize enough how important that advice. The head of sales takes six months to become productive. At least give your product lead a little bit of faction on that time, right? So, Alan, you as a founder are replacing part of the brain. How do you do that with like the minimum amount of damage? And so like the antibodies don't like kick it out.

Like how did you view about bringing in external people in the PM and limiting damage? or if you got it wrong, how would you change it to get it right? Yeah, so we operated, but when I brought our VP of product on, we had, I think it was at the time, three PMs, and I was the acting VP of product. And so there was little that the new guy could come in and do worse than what I was doing. Because I had a lot of other stuff going on,

And all three of these guys reported to me, which basically meant they had, like, no manager. I'd just add one bit to the diagnosis, which is in the 30 days in order to actually diagnose. Your guy just totally needs to be an information sponge and learn everything about the product. He needs to be, like, out on the street, talking with users, he needs to be looking at all the bugs that come in. And the guy that we hired went through our internal wiki so deep that he read the profile of one of our office dogs. And so we also have this forum that like a lot of our really heavy power users joins that it's almost like a little mini community within the broader community. And they talk a lot about product features. And they talk a lot about user suggestions.

They talk about bugs. And so I actually wrote up his first kind of couple of action item. and one of them was to engage with the people inside that community too so that he could learn how users actually interact with each other and how he can interact with users and it's not such a scary thing. He came back with, these are all the things that are essentially turning our users off and these are all the things that are keeping them coming back.

And like we got to fix the things that are turning them off and then that was the first couple of things that he prioritized then in the next quarter. Then we're going to open it up to Q&A. We've talked a lot about the VP of product role itself and sort of how that's emotional. But how does this affect the role of the person who has up until this point been growing the company and owning that vision? Because their role fundamentally changes when that VP of product comes in. And whether that becomes uncomfortable later, how do you position yourself appropriately to make sure that you can work well with that VP of product and that your role can then continue to grow and mature?

It was really important to me to have the VP of product. product be my partner. At the time, we could have made the decision to get like a, a really visionary product lead that has the great ideas about where to take the product, but maybe he can't execute on those things. And then on the other side, you can just have a pure executor and you tell him what to do and he, you know, does it better than anybody. But I wanted some, you know, somebody in between, somebody that I could really partner with in order to decide where to take the product vision. I don't want to be the guy. that it's on the receiving end of somebody that's just

imaginering all this great stuff, like it was really important for it to be a partnership, but you're absolutely right in that the role does change. It changed a lot for me, but it changed so much for the better because I'm now no longer so deep into the weeds of like literally assigning bugs to people and writing up product requirement documents and sitting down with the engineers

for like hours a day. And so as soon as we had our guy join, I immediately I step back from all the weeds and now I get to partner with him on where to take this thing. And that's really what I want to do. Not like dish out every bug and make every product decision.

It's actually pretty wonderful when you hire a great product leader because when you are driving that product vision you're so close to it and sometimes just the fact that you can step back and let this person quarterback sales, marketing,

customers, customer success, engineering and handle all of those requirements, determine what's the right way, determine whether we need to build it, whether you can go get it. Once you know, you as the CEO, get to take away all of that responsibility and have someone do it in an extremely methodical fashion, right, listen and then, you know, attack these problems, it's very liberating. You get to actually step back and you get to plan much longer time horizons. So when you're really early as a startup, you have very short time horizons when you need to plan, right? You can figure out something and then go get it done. And a great product leader allows you to start planning for those longer time horizons while he takes care of a lot of the details and the strategy.

We've talked a lot about kind of the onboarding and kind of making the most of the first 60 days. I was wondering maybe we can talk a little bit about hiring and talk more about the crazy hypergrowth. I think we must get thousands of people reaching out for a role like this. How do you weed through that and kind of maybe talk through more about, you know, what are you looking for between the stages of that initial phone interview to, you know, the final hire? I have two pieces of advice on that topic. The first one is the mock framework. And it stands for mission, objectives, and competencies.

What it forces you to do is exactly what you're saying. Write it down on paper what you're looking for. you can't recalibrate during the middle of a search but you also kind of asked during the period of hypergrowth if you have a bunch of people reaching out how do you kind of deal with that which is my second piece of advice is what stage is your company at

I wish somebody would have told me this which is when you hire when you raise a round and what you're going to do with that round is grow your team and the first thing you should do is hire somebody to hire people. Like, literally, you raise a bunch of money in order to build your team, you have to hire somebody to hire people immediately. Because that, like, you cannot hire every individual person. Another way to frame that might be, what is the superpower they have? There are many

superpowers, many different kinds of supervisors that product people have. You need to figure out what is the type of superpowers you need from a product leader. And then you want to take that your person who's doing your hiring for you, you hand them that rubric and say, I want them ranked on this. Like, I want a UI-centered product person who's going to nitpick every pixel on the product, we need to know that and don't bring that later, as opposed to the data center product person who's a total quant or the, you know, you can pick

each of the different types that you could find. So everyone has a superpower, but in startups you usually need a unicorn, right, so they can do like four or five things. Like on the design side, you want someone who codes, you want someone who does visual, you want someone who does UI, maybe even product. You can't find everything

in one person. What are you doing to train people to go beyond their superpower? Like, if you have a designer or engineer, be the product person, what do you do to give them the product strategy or customer centricity or data skills? 70% of learning you get is by doing the job. 10% of your learning comes from reading and seeing stuff. 20% comes from mentors who you watch in action, and 70% comes from actually doing the job.

We actually have a formal process now where we have people from other functions, adjacent functions, wanting to transfer into product management. We essentially have a six-month externship or internship where they slowly take on projects, starting with smaller scope projects and ultimately you want them to actually take a problem formulation and figure out how to execute on something. And so you just give them projects of bigger and bigger scope and that's how you learn.

In a product center company, the VP of product and the CEO, no matter how they got formed, they're co-founders. When you pick your co-founder for your company, my guess is that you didn't pick like, well, I can do this 20 tasks we need to get done and I'm really good at these 10, I need to find somebody that's really good at these 10. Like between the two of you, first off,

there's some point of intersection as all sorts of stuff that neither you knew how to do. And we're going to go figure it out together. It's important not to treat that interview as just an interview. I spent essentially five hours before I even agreed to interview

at Square with our CEO, just getting to know him and understanding what his vision is for the company, what he cares about, what he doesn't, what his philosophy is how he works, because you can interview all you want, but this is such an important critical role that you've got to spend time with them.

I'd love to hear about the emotional aspects of letting go a little bit. What have you done to make it easier to let go some of the things to this new person that doesn't even code? And what advice do you give to the newbie that comes in to make it easier for you

in both ways, for this emotional period to be smooth and lovely like a honeymoon? One layer I think is you have to find a way to, like, this proper casual relationship with the person that I think is, like, and it could be as simple as we're going to take a daily walk. It can be, like, we're going to have a regular dinner. It really matters whether you treat people the same way and whether you, like, look at the

world the same way, or you're going to be handed questions, you know, if your ethics are the same, turns out to be a really important one. Like, if you're going to be, your ethics are going to be tested all the time. And if you don't think about it the same way, then, like, you're going to find lots of conflicts. I think that, like, that level of trust and building that only happens with time. I don't think anybody would get. get married after like an interview process for their spouse. You just have to spend time together for it. The other end of the spectrum, I think, is like figuring out how you make decisions together.

And in a lot of cases, that can be collaborative and easy and so on. There is a hierarchy here, right? Like that head of product needs to empower their boss to, like, help them in their process. And that person needs to trust that they're not going to be left out of every decision. So I think the commitment goes both ways. One commitment is, look, I will bring you options. Like when we have hard decisions, I'll bring them to you. You can guarantee any hard decision I'm going to make.

I'm going to bring you that list of options. I need to come in from you that if you think the list isn't right, you tell me the list isn't right. Don't like just go add something. It's like just a way of talking to each other. Of like you trust that this person is sizing up the world for you and bringing you problems and solutions. And that person is a trust that you will abstract out,

give perspective that they may not have had and help them make decisions and help them evangelize decisions. But you have to form that trust. At some point I realized that as CEO, and founder, it is my job to scale myself. And by not scaling myself, I'm not doing my job. And I have to somehow

separate that emotional piece and I have to let go of some of these things. If you're a founder, you're in similar shoes, you want to do your job? Do you want to do it well? Well, heads up, your job is to scale yourself. All right, quickly talk about the failure modes. Like, what can you get wrong with bringing in a VPFPM? I think the biggest one is not onboarding them properly,

not coaching them how to be onboarded properly and not pushing them to make org changes sooner than later. When you bring on someone, you've got to tell them, hey, diagnose the org, 60 days, don't over, like, push them to deliver stuff earlier. Give them some of them. So in my case, it's looking for commitment

because if you think about it, a product lead is almost doing the job of, you know, most CEOs is handing that over. So a product lead needs to be maniacal about, you know, where this company is going, how they're going to build, create product, and that takes a lot of work. If people say, oh, I visit customers on second Fridays, it's probably not the right person. Almost the CEO level of commitment or the

CTO level of commitment to make this company successful. You can screw it up by not having a good relationship with your VP of product. Man, it's all about the partnership because, like, you have to be able to work together and you have to have a good working relationship. If you can't spend a ton of time with that person, then it's not going to work. And in order to figure out if you can spend a bunch of time with a person, you've got to spend a bunch of time with a person during the interview process. I'd say the flip side of that one is not correcting it fast enough if it's not a fit. The general rule in small groups, you have to deal with problems fast. Like, that's a simple rule. That role in particular metastasizes. All sorts of bad antibodies form around

that. So I think, like, be sure you're ready and then evaluate hard on, is this really working? And if not, have that hard discussion, like, I don't know. This doesn't seem to be working, and here's some of the reasons, but don't go through a second one and not make the fix. I see that's true for any role. It's true for any rule, for sure. Well, that, please, guys, everybody to give it up for an amazing panel.