"Let's Talk about Product Managers" by Josh Elman at Lean Product & Lean UX Meetup

a new additional thing. So, all right, without further ado, let me get to tonight's speaker, Josh Elman. I'm super excited to have Josh here. I've known him for a while and he's gonna be sharing his advice about product management. He's currently a partner at Greylock Partners. He's on the board of a lot of awesome startups. This is just a short list: Medium, Meerkat, Operator, Super. He was an early PM. I think he's the only one I know that's been at LinkedIn, Facebook, and Twitter. He's managed to like just—

I'm not sure.

Surf to all the hot companies. Before that, he also did work as PM at Zazzle and Real Network. So he's truly a PM and now he's transitioned to venture capital, but he knows a lot about it. His Twitter handle is @JoshElman and you definitely should read his posts on Medium there.

That's the link.

So without further ado, let me introduce Josh Elman. Is your mic on? All right.

Cool. Thanks everybody for coming out tonight on a Wednesday night. I remember many, many days, actually I've been in this exact room before. It used to be AOL and I'm forgetting what it was before that, or maybe it was always AOL, for different meetups and nights and learning. And so, you know, it's cool. Like this is how we all play the wonderful world that we live in in the Valley of getting to work on cool companies, hopefully ideas that become a lot bigger. And get to touch a lot of people in the world. And I still feel so lucky every day that I get to wake up, and have gotten to wake up for the last, whatever, 15, 16 years, just trying to work on stuff and help people make stuff that can be better. And for everybody in the room who isn't in— OK, awesome. I thought you were like, volume up, talk louder. You're in the back. No, thank you.

More light.

OK, cool. I'll scoot a little more into the light. A little bit blinding. It's fun. Was anybody in the room an engineer currently coding? OK, a couple of you. What I always respect as a product manager— I started my career as an engineer. Actually, my first job was building Windows products for Real Producer and Real Player. Do you guys remember Real Player?

Yeah.

Anybody else here ever coded on Windows? Anybody still even working on a Windows app? Yeah, so it's crazy. When I was first in my career, Windows was everywhere and I was like writing code every day and just trying to figure it out. And what I realized was being part of the process, like massive respect for what it takes to write code and make it work, massive respect for what it takes to be in the role where you help figure out what to be done so that people who are actually writing code can do it. Part of the reason I wanted to become a product manager was because I felt like the people I was working with at Real— and Real is not as strong a company anymore today, although it's still a publicly traded company. I felt like weren't always making the right decisions for the users and figuring out how to do stuff. So, I thought I'd go to business school. Anybody have an MBA? Okay, a bunch of you. I only did one semester unfortunately, I dropped out. I found this company LinkedIn and they're like 15 people and I managed to convince them to hire me as a product manager even though I'd never done product management. But I had gotten to work on RealPlayer and I'd been running a big product and engineering team for that. And I still remember in my interview, Reid Hoffman asked me, he was like, OK, so BD people, they— everybody has an artifact in their job. What's the one for product management? He said, BD people, they ship contracts. They're actually responsible for the artifact that is the exact language of a deal they make with another company. Engineers, obvious, they ship code. Designer is obvious. They make mockups and often the very final pixel-perfect designs. He said, as a CEO, my artifacts are the bank account, having financing, and the organizational chart. I'm responsible for filling up the organizational chart and the vision statement. He said, what is it for product management? And I looked at him and I said, wow, that's hard because product managers don't really do anything. And here I was trying to get a job at LinkedIn. And I said, but look, look, the artifact is a carefully written down set of concepts that gives the team the guidelines for what they should build, what code they should write, and what they should design. And it turned out to be a good enough answer that he hired me. So maybe that works. But it just has always stuck in my ear. It was like, what is the artifact? What is the actual thing you produce when you don't do it? And so as I've gone now through the rest of my career— I was at LinkedIn for a little while. We did a lot of early stuff on growth, launched LinkedIn Jobs. Then I got sort of excited about the future of on-demand commerce. I see a buddy of mine named— Mike in the back, who worked with me at Zazzle back in 2005 and '06. This idea that bits to atoms, anything you can imagine digitally, you could get on a physical product, a super ambitious vision. I did that for a couple years, kind of burned myself out at sort of the startup life. So I thought I wanted a big company. And I went to Facebook when it was maybe 500 people and got to go work on the platform there. We got to launch Facebook Connect and sort of tried to convince the rest of the world that you could make your products, websites, everything more social if you just added a Facebook button. and brought in the Facebook login and identity. Tons of great stories on how we got that working, and I'm pretty proud of that. But as I was working at Facebook, I started using this product called Twitter every day. And I was like, Facebook's going to be great, but it was already kind of a big company when I joined. I want to go to something smaller again. So I wormed my way into Twitter. And it took me 6 months, by the way, to get a job at Twitter. It wasn't like I just applied. There was an opening and I applied. A friend of mine introduced me to the founders. I think it was Biz Stone at that point. And wrote me back and said, sure, hey, we'd love to meet you. I'd been at Facebook, I'd been at LinkedIn before, and I thought maybe I could do something useful for them. I went in and met a few folks and they were like, we're not really hiring somebody like you right now. And so I just sort of kept in touch and they would occasionally ask me for advice on Facebook or other things. And then I just kept like, hey, just in case you guys are thinking about hiring product managers, just to let you know I'm still interested. Even though I was in a very good job at Facebook, I kind of Didn't ever feel like it was exactly where I wanted to be on the platform side. And so I kind of kept writing to Twitter. And then finally, 6 months later, they were like, hey, we just raised a bunch more money. We're thinking about expanding the team a lot. We'd love to kind of add a product manager. Are you still interested? And so I went and I was like, absolutely. I'll be there tomorrow. And so I went and met with them again. And they kind of gut-checked on where I was at and what I thought Twitter could do. And I got really lucky to kind of get hired as one of the very first product people at Twitter. And I'm not going to tell the full story. I've done other talks about Twitter growth. But I walked in, and the very first day, it was like, everybody signs up for Twitter, nobody sticks around. Help us fix that. And back then, we had maybe 10+ million users. And so we spent a lot of time trying to understand that and figure it out and how to get a much more addictive habit. And it's funny, because I think the reality of a question like that is you have to keep asking that and keep answering that, like every month, every year, on and on and on. And I think that they're struggling through a bunch of that right now. And I'm still a shareholder, so I sure hope they fix it. But look, I still use the product every day, and I love it. And I want to figure out how to evangelize it to anybody here who doesn't or elsewhere. And so that was my path. And the reason that I just kind of went through that in a rambling way is now I'm a VC. And because I got to be at a bunch of really early startups, built relationships with a lot of people, And I've gotten to kind of see some of these things that started really small become really successful. I've kind of been lucky enough to kind of get this chance to now go on behalf of our limited partners, go and find the next great companies and get to help them. And being a VC is a totally different trip for me because my job now is to find great people building great things and convince them that they want to choose my partners, my partnership, me on their board over anybody else to work with, team up with them on their company. And it's not that different, though, than when you're building your career and you're trying to find the company you want to work at and you're trying to convince them to hire you. So I feel like I'm just on a perpetual job interview. And you think that as a VC, we get to do all the interviewing and we're like, come tell us why you need money. But it turns out the ones you really want to be involved with are the ones that you actually have to go interview for and really win the job at the end of the day. And so in some ways, doing VC is just an extension of product management. working on one product, I get to work on several. Instead of being responsible for one area or feature set, I do have a portfolio, but it's just leverage. And I'm sitting there working with them on some of the hardest strategy problems, challenges, hiring, resourcing, building the team, getting the cadence right that you could possibly imagine. So in some ways, I think VC is sort of just a more leveraged way of doing product management. And I tell this story mostly just to to remind you guys all that you're all sitting in this room, product management, building your careers, finding interesting things to go work on. Just keep doing it. You never know where it'll take you. But the one true thing in my whole path has been everything I found, I was like, this thing is really cool. And if it really works, it could be so much bigger. We could put it in the hands of so many more people. And I just kept following that dream. And I still am. I mean, now I'm investing in smaller and smaller startups. My latest one we announced today was a company called Discord. that's sort of in the gaming communication space. And it's an amazing company. If you play League or Dota or Counter-Strike or anything and you're still using Skype or Ventrilo or TeamSpeak, totally get on Discord. OK, that's my plug. So in this talk, what I've tried to do is sort of capture a lot of what I've learned about product management across my career and try to kind of answer that super hard question, which is like, what actually does a product manager do? Because all of you in this room, I'm sure, face this. You're like, your team asks you this. The company asks you this, like, why do we even need a product manager? If you're a small startup, which many of you were like 10-person companies, you're like, we don't need a product manager. And in many ways you don't, because the founder and the CTO and the first engineers, they kind of are collectively doing that function of product management. But it's kind of this eternal question. And I start— when I actually went and interviewed at Zazzle, which was my job after LinkedIn, they asked me, what does a product manager do? And my answer to them was, I don't really know, just like I did at LinkedIn. But I said, but in 6 months, you're going to look back and you're going to wonder how you ever got through it without product management. And you're going to be so thankful that we have product management to help be the glue and get the team done. And it turned out to be a good enough answer that I got that job. But I don't think it's actually a great one. And so I'm going to kind of just talk through and work through just a bunch of thoughts on kind of how to think about what a product manager does. And I really tried to write this as like trying to explain it to my mom. And she used to always ask me, what do you actually do as a product manager? You know, your brother is a designer, your brother is an engineer. But she could never actually figure out what I did once I stopped being an engineer. And now I get this about venture capital all the time. So, again, going back to that Reid Hoffman question, you know, I always think about like what a product manager doesn't do. Look, at the end of the day, we aren't responsible for a bunch of these things that other teams are. We don't write code. Engineering writes code. And as much as you might want to think about yourself as like, oh, I can still hack and prototype a little bit, like, you should not be writing industrial shipping code for your team. It's just not the most leveraged way to be a great product manager. You know, we don't create mockups. Like, design creates mockups. And the best product managers enable design to have better eye and better vision. That doesn't mean you can't create some like quick wireframes. It doesn't mean that you can't sort of sketch things out and help inspire the team on a direction. But your job is not to create pixel-perfect mockups. And if you are the product manager trying to do that, your designers probably hate you. You know, we don't sign deals. Look, ultimately, the business development function in a company is really where the deals get signed. Now, product management is very involved in it because we're constantly helping think through, well, what would we need to build to sign this deal? What do we need to do to make this partnership really work? What are the win-win relationships? It can be a great partner to BD in doing that. And ultimately, you take responsibility of executing, you know, with your team a bunch of the stuff. that might have gotten signed. But it's not really product manager's job to own the final contract. That really is on somebody else. And we don't like plan PR. Communications runs PR, marketing, maybe you have product marketing that does all that stuff. So ultimately, we don't actually do any of these tangible things. What we do do is sit in the middle of a lot of it. And the product manager's job is to sit in the middle of all this, make sure it's all happening really smoothly so the team can get a lot of the stuff done. And as a product manager, I like to think of the responsibilities in a whole bunch of different areas. It's defining the market customer, understanding who that person is. It's working on the launch timing, making sure all the collateral is getting made and that you kind of are keeping track of everything. This is a little bit of project management. And sometimes you can have a separate project manager, but really the best product managers that I've ever worked with are able to, you know, sort of oversee all the project management as well as this vision and details and define like, the customer. Look, defining the problem value— the problem and the value proposition. The one of the most important things you can be doing is articulating to your team very specifically, here's what we're doing and why. Here's why this feature matters. Understand the competitors' products and competition. Look, if you're not— how many of you as a product manager use your competitive products like once a week? Okay. That's not enough hands in the room, by the way. Like all of you should because if you're thinking about your product in your space, You definitely don't want your engineers, your designers, everybody doing it. And you definitely don't want to design by what the other guy does. So you don't want to be like, copy— well, they just added this feature. We must add this feature. But if you aren't understanding their cycle and their cadence and their psyche and what they're delivering to their customers to make sure that what you're delivering to your customers is wholly better, you're not doing your job. Because somebody on the team has to be able to do that and bring that perspective in. But again, that doesn't mean you're like, well, they just added this feature. We're going to lose on the checkbox rating, because that never matters. Fundamentally, being an internal communicator— and I'll talk a little bit more about this— is one of the most important jobs of a product manager. And lastly is being an evangelist and champion. I think one of the hardest parts for me about being a product manager was being a constant cheerleader. Stuff goes up. Stuff goes down. Stuff goes sideways. But you have to sit there and be the one who's like, look, stay on course. Stay on target.

Yeah.

We're getting into fine. So I took this from a guy named Martin Erickson who runs the Mind the Product event. But there's this great way just to think about it much more simply. Take the user experience, the right thing for the customers, the technology, and the right thing for the business. You get to sit right in the middle. And fundamentally, I try to define it as a very simple role. You as a product manager, you're successful if you help your team and your company ship the right product to your users. And if you are helping your team be better, that's great. You don't define it. You don't own it. Everybody says, hey, you are responsible for it. And the answer is no. Your team actually does all the hard work and all the heavy lifting, all the debugging, all the pixel-perfect manipulation. But if you aren't making every single one of them better, then you're not successful. And I like to think about what would be the Net Promoter Score of a product manager? I think there's 2 ways to measure it. This is tricky because we always like to have one metric. One metric is clearly, did you ship the right thing to your users? Did you have the business impact? Did your team actually deliver the business impact? But I always like to think there's sort of a second metric, which is, does the team want to work with you again? Because fundamentally, if you blitz everybody through and you ship the right thing and you're successful for your company, but nobody wants to work with you again, then you aren't actually achieving the success of helping your team. So it's a really interesting challenge of how do you do both. And I, as a product manager, often found myself— I think I got along pretty well with the teams that I worked with, but stepping on other people's toes in the company in order to get our stuff done. And it's a really sensitive line, one which I might have crossed more than once. And so when I think about this, I'll kind of break this down. Because I think it's really important to think about what does actually helping your team mean? So how do you actually define your product team? And man, this has been so confusing in so many companies I've ever been at. Like, what's the team? Is it in the extended team, the virtual team? What I like to think about is you as a product manager are 100% responsible for making sure that everybody who's spending their 24/7 on your project is more successful. This is the engineers, designers, QA, marketing, documentation. They're on your project, and your goal is to ship something new and deliver that out to the market. What's interesting, though, is there's always been this virtual team. I think we kind of sometimes half-ass it where we say, oh, these people are sort of on the team or not. As a product manager, it's actually your job to figure out and define the team and say, look, these people from user support, we're going to consider them a key part of this team and user support impact is really important. Or we're going to not consider them a part of the internal team working on this stuff, but we'll take their input and then we'll make decisions. I've seen it done both ways and it works really well both ways, but you have to be clear about it. Everybody wants to have input into your stuff, and you either have to let people onto the team where you're collectively making the decision, or you have to keep them— or you have to say, thank you for your input, but this is the core team that's going to make that decision. And that's sometimes a company issue, but as a product manager, you're surprised at how much responsibility you actually have for that. So what is your role on the team? And look, who here kind of loves this term, I'm the CEO of the product?

Me.

OK, so I totally don't, so nobody raised their hand. But it comes out all the time. And people are often saying, oh, I want to be a product manager. I'll be the CEO of the project, and I'll get to run everything. And I just look at all of them, and I'm like, that is the worst possible way to think about product management. If you think of yourself as the CEO of the project, then that means you kind of have this ultimate authority. You get to tell everybody what to do. The entire way that product management has been defined— I've seen it work successfully in the Valley— is the opposite of that. It isn't assigned authority, it's actually implicit earned responsibility, earned trust. And I think that's a really important distinction. Because when you are the CEO, the buck does stop with you. You have real make-or-break decisions you have to do. You hire, fire. You own resourcing. You own allocation. And that's a real challenge. As a product manager, I mean, I don't know about you, but I never as a product manager got to decide what resources were on my team. I got to make a case, and I often got bigger teams or smaller teams that we would allocate to a given project, but never owned that. It was more like, how do you take the team you've got and make something great? Whereas a CEO has a— they have to do some of that too. They have the team they have. But they do have a little bit more implicit authority. But while you're not the CEO in sort of the parlance of the buck stops here, you really are the leader. People do look to you to kind of set the cadence, make sure that every idea is coming up, making sure that the product is— the team is operating smoothly. Make sure that you really are extracting that responsibility of owning what the team is doing and sort of bearing it on yourself, which is very similar to what a CEO does, without having that final authority. And the best product managers can actually earn that trust implicitly. It's one of the hardest things that I always felt about the job. So how did we— these are some of the tips that I learned in setting the cadence properly that really, I think, made a lot of my teams work more effectively. The first was we tried to kind of build the roadmap quarterly. And we tried to stay on a quarterly cadence with the roadmap because if we went too far and said, this is what we're going to do all year, we would change it halfway through and everybody would be like, oh, we keep changing the plans. But if we tried to like only do it once a month— or sorry, do it every month, we'd feel like, OK, whatever was coming next, how can we even plan ahead? So, I found that quarterly was really good and I'll talk a little bit about how we did. Quarterly brainstorming in a second. Look, the second thing that I always found was really important was articulating that roadmap just super clearly and consistently, actually writing it down, actually having a document somewhere in the company that people could point to and do it. It did change and it wasn't always up to date, but having it as a starting point was something that a lot of PMs and everything didn't do or put into deck form that was sort of like a deck that gets emailed around, that's sort of a magic thing. The third thing we did on our team was we held these regular weekly or biweekly meetings, which I'll talk a little bit more about, that were trying to be like the one meeting for the team. It is so easy as a product manager to get into meeting hell, where you're like, oh, here's a question. Let's have a meeting. Oh, here's another issue that comes up, like should we make it blue or red? Let's have a meeting. Let's do a design review, and then a feature review, and then a product review, and then another design review. And if you're a product manager, your schedule's probably— Full. Really blanked out. But what's even worse is when your team schedule is really blanked out. So, like, the engineers have to keep coming to meeting after meeting— bug review, bug triage, bug— and so, what we tried to do was kind of distill it down to, like, the one meeting a week you really needed to come to, or every other week, where you'd go over everything important for the team. And if you missed that, you missed out on what was going on and what was happening. But almost everything else, try to get decided on the fly or in brainstorms or other things. I'll talk a little more about this thing called Act Solid, which was our way at Twitter of defining how we worked with external teams, and then taking and sharing notes. So, the brainstorm meeting. So, we did this once a quarter, and everybody has a different method, but I found this worked really, really well for us. We'd come into the top of a quarter and we'd have a very clear sort of set of goals. And I would often have prepared some materials like, here's the metrics that are working, here's the gaps we analyzed, here's the set of things in which Like I was saying, for Twitter with growth, we'd say like, look, we think the biggest problem is retention. We think we're getting this many people through the funnel, then they don't actually follow enough in their first session. So we think that's an area that we should approach. And so how can we bring people back or get them engaged? So we'd kind of come with a couple of theories of what was broken, but these were more problems to solve. I always tried to treat the team as the set of problem solvers, not the team of executors to a very specific vision or solve problems. So then I'd— and we would tee this up over a couple days or a week ahead of the quarterly planning as best we could. So it wasn't just, hey, welcome to this meeting. Now go start brainstorming. And then in the meeting, we'd kind of give everybody a chance to sort of pitch their idea. And they would kind of say, hey, I think the best way we can move the needle on retention, or the best way we can get a little bit more virality, or the best way we can increase stickiness is by this. And we'd have everybody write their their idea on a little sticky note. We'd paste them up all over the room or all over the whiteboard. And so then we let people do Q&A. So if you said, hey, when you said address book, what did you really mean? Did you mean address book for invitations, address book for matching later? So we'd kind of go back and forth just to clarify everybody's ideas. And then I made everybody vote. And everybody on the team got a vote. If you were on the team as we defined it earlier, you'd come up, you'd write your initials. So they weren't like private random votes. They were like you just write your name next to the the 3 features you thought would deliver the highest impact for the goals that we had for this quarter. And sometimes, if there were an even longer project, longer lead, we'd say, hey, the goal at the end of this quarter is to get this thing built so that we can ship it in the next quarter. So we'd go through, everybody would vote, and then we'd have a big discussion. This was the fun part. This is, I think, where the team really came together, is people who voted for one thing or voted for something else, we'd actually get to ask each other, why'd you vote for that? You were the only one who thought that was one of the top 3 features. People kind of get to make their case. If like 3 people voted for one thing and 8 people voted for the next, we kind of go back and forth and people would again make their cases. And after everybody heard their cases and they saw kind of what was getting more votes or less and what had sort of team momentum, then we would let people change their votes. Because that way, like if you're like, hey, okay, our little feature the way we defined it isn't going to get done because only 3 of us voting for it. But if we all 3 go vote for that one, that'll finally make it on the list. And so, we let everybody re-vote because look, at the end of the day, we want to just pick the thing that the team is most excited to work on. And at the end of all that process, I generally said, look, if we go do these 3 things this quarter or whatever else on the list, we have a great chance of achieving our goals. The team's bought in. The team's excited about it. They believe it is— they had a chance to get heard. If their pet project didn't actually get enough votes, they at least had a chance to be heard and hopefully they'll get it next time. And so, I felt that was a really inclusive way to kind of come up with priorities. And I know it sounds haphazard and like, oh my God, but how did you ever get the vision? But look, we hire the best and brightest and smartest people to work with who are super passionate about the problems that they're working on. And we try to give them all the input and all the knowledge that everybody else has. Like, at the end of the day, they're going to go do the work to do the coding, the design, everything else. I trust them to make good decisions. And if we don't trust our teams to make good decisions, either we're on the wrong teams or we're the wrong person to be on that team. So, that was like how kind of we set our core. We said, OK, we're going to kind of go after these things. And like, I'm lying if I didn't say it changed a lot afterwards. Of course it changed and of course it flexed, but it worked. So, the next thing we really spent a lot of time on our team with was like, how do we do a cadence that actually works that tries to get us out of the meeting hell of our team? And we did daily stand-ups. So, every morning for 10 minutes, everybody would run around and go, here's what I'm doing, here's what I'm doing. It was kind of a good gut check for the team. But to me, most important was kind of the product operations meeting that we tried to do, sometimes weekly, sometimes biweekly. And here was the basic agenda that I tried to make that meeting. I tried to make it— again, if you're here, you won't be missing out. If you miss this meeting, you may miss out on what the team is up to, and you'll feel a little bit left out. So the first was sharing any company news that was relevant for the team, because not every engineer or designer is in every discussion or picks up every sort of company update that's happening. The second was going over kind of like the final launch list for things that the people on the team were shipping very, very soon. The third thing was something I felt was really important. I felt like I hadn't seen a lot in my career, which was a look back on recent launches. How many times do you launch something and then you're so quickly on the next thing, everybody's like, well, how did it do? Should we actually change anything? Should we fix it? Did we hit our metrics? Did we not? And so we would actually spend more time on actually preparing A nice sort of analysis with data on what happened when we launched it. Did it achieve our metrics or not? Are there 3 bugs we learned about that we need to go fix? And then many times, I think the— I call it kind of the curing period. The sort of 4 weeks after you launch something are actually the most important before you really move on to the next project. And actually, to think one more step about that, so often when you ship something, you're like, oh, I cut out all these features in order to make my deadline. Let's just go add all these features. But when you actually launch it, you realize those things you cut out may have not been the most important ones at all. And so what's really important is launch with all the stuff you cut out, then go figure out what's important, then actually maybe go build it over sort of a curing period. And literally, you can keep going forever. So you might as well just stop and probably get more impact out of the next thing you might launch rather than continuing to iterate on that thing. So anyway, we did this kind of look back every time at recent features. Roadmap check-in on some of the big things that were going on, whether people were giving updates or demos or showing new mockups, so that everybody kind of knew what was happening with the other projects that they might not have been directly working on. And then lastly, if there was time— this was a 90-minute meeting, so sometimes the last 30 minutes we'd cut off, or we would have a guest speaker in from another area of the company where we could use that as really a good time to sort of share knowledge because we had everybody together. And we were trying to make it the one time to skip out on on your day and be out of work. Now, this sounds great in theory. Of course, this meeting gets bumped around and there are other meetings that happen. But when we really had this cadence working, I felt like it was sort of the most like meeting-light time because all the issues that would normally get pent up and sort of call for a meeting could actually get discussed, raised, and addressed or surfaced here for working sessions without needing to have lots of ad hoc meetings or even— Lots of sort of ad hoc conversations, because you knew you had a consistent place to raise them. So when I go back and think about my product job, doing even these meetings, doing this planning, doing this analysis, I found that my job was really about being much more of a glorified note-taker. Sure, I set up the meeting and run it, but that wasn't kind of what I was really mostly doing. I was sitting there trying to capture everything that was said and figure it out. And I would actually spend more time after a meeting writing the notes up than I had actually spent in the meeting. Does that happen to anybody else?

Yeah.

OK, so like I would literally like try to craft the document and the email that would go out with the summary of the meeting. And it would often take me longer than we were actually in the meeting. So I was trying to like remember everything, get it captured, fire off the couple of emails to trigger other conversations that were important from the meeting, and then sort of have it captured in one place. I found every time I did this, it really made the team and the project much better and stronger because it really was written down versus, oh, rush to the next meeting and the next meeting. And then 2 days later, you're like, what did we decide? And so, you know, it's a hard thing to do though, to actually spend time writing down notes. That seems like the most boring, useless thing. You know, some people have gotten really good at like taking notes during a meeting so it actually almost feels like a real-time capture. But I found that extra time I spent organizing it and just putting it into the framework of what was really decided and what the action items were really helped me. And I found the other great thing was when we had the notes, other teams in the company felt much less nervous about what we were doing. Because they could literally go read these nicely crafted notes that organized what had happened in our teams. And we didn't sort of have all that uncertainty. Every other team in the organization got to share it. So at Twitter with those other teams, we called it Act Solid because for us, When you were building a product or a feature, we decided that these were the 8 teams that you had to do. The other acronym that we almost formed was Lost Acid, but we thought this sounded better. For us, it was understanding the different teams in the company that whenever we shipped a new feature, it wasn't like we're just awesome and shipping it for our product team, but it really did affect a bunch of other groups in the company. It affected the analytics and the data group. They needed to know the new data that was going to go into the pipeline. They were going to be able to add things to the dashboard and do stuff. And that they were aware of that. We always had cases where we'd ship something and it would flood the data warehouse. So you really need to have them engaged before you launch anything. Communications, PR— I don't know how many times people have launched something and then communications finds out a day later when there's some massive privacy flaw that got unearthed that nobody really predicted. And they're like, why didn't you just tell us you were launching this thing? At least we would have been aware instead of the hair on fire.

Poor communications.

If there's any job that gets more emergency hair-on-fire moments, it's the big PR leak or the big PR mess that they have to go cover up. So just telling them in advance, at least always they knew who to call and they had enough context. They're like, oh, that was that thing. Oh man, that sucks that that happened. But at least they knew instead of panicked. At Twitter, we called our user— we had a team called Trust and Safety that was responsible for kind of user security, the safety of the network. Not every company has that, but most consumer companies do. Because it's different than user support. It's like, how do we make sure accounts are protected, or people aren't getting abused, or directly harassed, or anything else? And any feature that we shipped and changed on that always had a big impact on them, stuff that we didn't even know. And again, the heads up makes all the difference versus the, like, I'm sorry. And everybody's like, oh, just ask for forgiveness. And you're not actually asking for approval from them. You're not like, we're going to ship this. Is that OK? You don't necessarily have to do that. But you certainly have to give them the heads up. Obviously, our user support team, whenever we ship something new, they want to know about it. The operations team, so that if we blew up the servers, they were well aware. The tech ops team. Legal. Twitter was the first company— and the general counsel when I was there is now working in the White House as deputy—

General Counsel.

counsel for the government, for the White House. But he was the first time I sat down with a lawyer and he said, look, my job is not to tell you no or tell you what you can or can't do. My job is to work with us so that whenever we're trying to build and ship something new that pushes the limits, we understand all the risks, all the factors, and hopefully I can help you make it better and both like help you like maximize your output. And he was an engineer himself. in the past, and I thought the way that he approached that was just brilliant and really helpful. And it was the first time that I felt like a legal team is really part of building great products, not a no or a gotcha. And so if you can ever make sure you try to build that relationship with legal, it's really, really healthy to do. Anyone here want to say they have that? Got a few of you. It was amazing. It was eye-opening. International was obviously a huge area for us. We're like, oh, we're just building this feature and we use it in the US. And you forget that there's 77 other languages that your product's translated into, other countries it affects, things that you might do that have massive cultural impact that you don't always think about. And so it was a very good gut check to work with that team to make sure we were doing it. And then design— we had designers on our team, but often they would sort of be designing our feature and miss some of the overall brand guidelines or other ways that things were moving. So kind of that gut check was a really important thing for us. So this was just a great sort of moniker for us at Twitter to just make sure that Great. Work on your team. Ship. Build as fast as you can. Don't get in the way of other things. But be conscious of the fact that anything you do affects a lot of other people's work afterwards. So that's really all the team stuff. And that's where I found as a product manager I spent most of my time. But I like to think about sort of— if you remember my definition, it was like help your team parentheses and company. Because ultimately, you're only successful when you're helping your team if what your team is doing is overall helping your company. I found a lot of teams that get so myopic. They're like, well, we're doing this thing. We're going after this metric. We're going to nail this new feature. And we're going to have more users searching on the product. OK, but nobody really— only 10% of our users even search. We need to solve so many things upstream before we do that. That doesn't mean you're the most important thing and you should get rid of all these other features. I used to— as part of growth, we owned the Twitter homepage. And every team, or lots of other teams, come in and say, can we put this on the homepage? And the problem is the homepage can then be cluttered with everybody's little button and feature. And every time we put a new button or feature on the Twitter homepage, we lost people to actually sign up and get active. So since we were focused on how do we grow the whole base for everybody, putting all these micro features on the homepage actually and taking away from growth might not have been the right trade-off. And we were constantly vetting that. Like what's the company's overall goal at that time? It was growth. So you really want to make sure that you, both for your team and in the context of the other teams, are thinking about your company focus. I think that it's really important as a product manager to remind teams of the founder's vision and remind everybody what you're working on, the founder's vision. And you need to be in touch with the founders, the CEO, the executives on what that vision is of the company. It gets so easy to get lost and think, oh, I got it. Oh, I'm not so happy with what they say. I want to do it this way. But fundamentally, we're all there to serve at kind of the business of what the founders and the CEO are really driving to do. And that's what we're hired for. And that's what we're funded for. And they've gone and made a bunch of assertions to a bunch of people in the world. And so if you help realize that, I think it really pays off. Tying your incentives to the company goals is great. And look, whenever I was interviewing a product manager, I always looked for how many times they said we, the team, and here's Here's the founders I worked for and what they were trying to do. And here's how I thought we could go deliver that the best way. Much more than I, I, I. I had this great idea. I thought of this thing. I tried to do this. And it is really important when you're interviewing product managers to kind of find that filter. On the other hand, if you want to say I, I, I and me, me, me and have great ideas, go found a company. It's on you. It's awesome. Honestly, I've never done it. And I've always been a joiner and not a founder. And I have the most respect. And even more so now in my role in VC on how much of a burden it is when you say, I'm going to go start this company from scratch, incorporate it, raise money, commit to every single person who comes and joins me on this journey that they're on this journey with me and we're going to go make it great. And like if that's where you want to be, you should totally do that. But if you join somebody else's company, you're joining their company. They've already done that and set the table. And we're all so lucky to sometimes get to work for great people who've done that. So, wouldn't be talking about product management if we didn't talk about shipping. Because fundamentally, like, if you can't actually get your product out the door, nothing else matters. Like, at the end of the day, the reason that we're hired, that the team is hired, is to build something that makes lives better for our users. And I often find that people, like, want to make it perfect. And it turns out that anything that's much better than what they had before for users actually makes them a lot happier. So even though it's never perfect, you literally do improve your user's life. Now if you're not doing that, you're building crappy products, which we'll talk about in a sec. But as a product manager, you're always going to agitate. Like, everybody's such a perfectionist. We try to do great work. Most people kind of work their butts off in school. They always aim for the A. They can't help but want that when they're working at a company. And they're like, oh, it's not good enough. But it turns out, as a product manager, you kind of have to like— Believe that and yet still fight through it to be successful. Launch readiness, providing those clear criteria, making the very tough trade-offs. I can tell you how many times I was like, oh, I really wish we could add this extra feature to make it better for users. Or we would often sometimes ship without building all the customer service tools, knowing that we could build those right after we shipped, even though we knew we were going to cause a scramble for a little while. And I say that with customer support people are probably all staring at me with laser eyes right now. But that's how we always had to make the trade-offs to get it out the door. And I really do stand by that point I made earlier. When you're trying to build all these features and you have to start cutting them, you have to realize the ones you're cutting, you might not have actually needed to ship in the first place. And you'll learn that once you ship. And it doesn't mean the next thing you should do is just go ship them. This is a dumb quote that I made up, but find that tricky balance between getting it right and getting out the door. That's your job. And finding that balance and where do you sit on that line. There's nothing more important for a product manager than to think about this all the time, because you're going to be the one who thinks about this much more than the rest of your team. Half the people who aren't building the stuff every day are going to be like, why isn't this launched yet? Where is it? And the people who are writing the code and doing the design are like, it doesn't feel right yet. It's not perfect. And you have to thread that needle and really own that for the team. So how do we get the right product? And this is, I think, now where the other real strength of product management comes in and really kind of honing this for the team. The team's creative. Like, our job is to harness the creativity and let the team really, really be creative. You might think you have all the great ideas, and as a PM, I'm sure you have a lot, but that designer, that engineer, that person in user support who's listening to customers all day, they can come from anywhere. And so, your job is to take all of this in and help recirculate it with the team in a way where you guys kind of believe what you can do. And then listen to feedback. Like, so many times I also hear people like, oh, this is right. We're just going to make it, you know, this way. And like, the feedback really helps. And don't just say, okay, well, they said to go this way, so now we turn. But listen to the feedback, you know. Take all that— take all those testers and active users and what features they want. Well, the feature they're asking for isn't always right. There's always a ground truth of what they're poking you for that is really important. Non-users— too many times, I think, we talk to people who love our product and want more. And we don't talk to the people who don't use our product. One of the best things we did at Twitter right when I started was we went and did this exercise where we called people who had signed up for Twitter, never got going, came back over 30 days later, and then got active.

Wow.

And because they had gone through the journey, we were able to really ask them, why did you sign up in the first place? What happened? What didn't deliver on it the first time? What brought you back? And what kept you there the second time? And for almost everybody, we heard this thing where, oh, my friend told me about Twitter. And they said it was this great place to broadcast and shout. And lots of famous people were doing it. So I signed up. And I had nothing to say. And I didn't understand the product at all. And then later, because I'd heard about it again, I was like, ah, maybe I should try it again, but it seems stupid. And then they'd always have one story that was like, my reverend is on Twitter tweeting out sermon and Bible quotes and is engaging with people and is replying and is telling us about church events. And so I wanted to get back on Twitter to hear from my reverend. Or my favorite food truck will tweet out their location, so I wanted to get the—

The location.

location of the food truck so I could go find it when I was out there. Or I heard this funny celebrity was on Twitter and it was like Shaquille O'Neal at one point had said, oh, I'm in an airport. Anybody, the next person who touches me wins a prize and gets a picture with me. And they heard stories like that and they're like, I just want to hear from these people. And so they started because they heard about Twitter as a megaphone, didn't work for them. They came back when they heard about Twitter as a listening device. And it really helped us kind of realize all that criticism from all those people who were like, I don't get it, I don't get it. Meant that we weren't actually delivering on something they wanted, even though it was what they'd heard about. So we spent a lot of time trying to understand that. Get input from founders and leaders. At the end of the day, you want their insight in your product, and you want their blessing. And if you don't have the blessing of your leaders, it will always catch up to you. I've seen so many times where people are steamrolling through. They're about to ship something. They're super excited about it. And all of a sudden, like, oh, let's go for a final review with the CEO. And then they crap all over it. Because what they're doing is spending all their time outside the company, inside the company, learning, filtering, processing information at a very different strategic level often than what you're able to do because you're so focused on building your product. And their gut check, even if it's a flash gut check, is often very well informed by all of that stuff. That doesn't mean they're always right. And it doesn't mean that you should just— you should totally feel free to argue and push back and debate. But, you know, and the flybys of like, hey, what are you working on? Oh, that's a terrible thing. Make it, you know, make it red. Change it around. Like, those aren't useful at all. So, you should be seeking it out and you should actually be going and gathering that feedback as much as you can. You know, and then look, like, if you're a great PM, you are searching the web, trawling, listening to Twitter, trying to find ideas everywhere you can and just bringing those back to the team to keep the ideas flowing. Creativity starts, you know, the team is fundamentally creative or we wouldn't be making new products and new technology. We're always building stuff that hasn't been built before. So get that. But measure. So I started my career at RealPlayer. We shipped desktop software. And it was mostly once a year. And measuring was hard. We just couldn't really measure it. We'd send out a product. And we'd get very little usage data back. There wasn't any of this stuff. We all build internet-connected products all the time now. If you're in hardware, if you're in B2B software, maybe, although SaaS totally changes that. Maybe some of that stuff's a little bit harder. But what a lot of us get to build on consumer technology, we put it in the hands of our users, we get all this usage data. If you're not measuring what you want, it's even worse. But measuring isn't the only thing. I hear, oh, what's your data? It's really about the theory and the hypothesis. Do you guys remember the scientific method from school? Hypothesis— or sorry, it was like problem, hypothesis, experiments, analysis, theory, right?

Yeah.

And so you kind of go through this exact method, actually, when we're shipping products and features to users, it's exactly the same thing. An idea of what we want to solve for our users, the feature that we want to go and test on them, analysis of the results, and then did we make an impact to deliver the value we wanted or not? And I like to call that the data scientific method instead of the scientific method. And we don't do that enough when we're building projects. think about it that way, and yet that's exactly what we're trying to do. And so, so many people skip the measurement step. So don't skip it. Look at what works and what doesn't. Look for kind of the bright spots where you're like, oh my gosh, wait, a bunch of users are doing this thing now that didn't do it before. The other thing that I've learned a lot is how many times you run that A/B test, you run that new thing, and some metrics go up and some go down. And that's almost invariably what happens. You really have to have that gut feel for, OK, Well, if these go up and these go down, but the ones that went up compound in this way, we're much better off for the business. Or wait, we lost these 2 important behaviors that really used to have very important compounding effects in our network. We actually need to revert until we figure that out. So the last and most important thing about product management is we represent the user. As a product manager, you're the one person on the team who's not writing code or designing or doing all the other things. So you're just thinking about, is all the stuff we're doing going to make the user's life better or not? You need to keep telling stories, keep telling those use cases. I think the single most important thing a product manager can do on the team is say, OK, so when this type of user goes and uses the feature this way, here's what they're going to have their expectations, and here's what we're going to deliver for them. Is that what we want? And whether you use user personas or whether you use use cases, there's a whole bunch of different— User stories. There's a bunch of different ways to actually implement this. But as a product manager, whatever tool you use, you just have to think about that user somewhere sitting in the middle of Nebraska who's opening up their phone or opening up their PC, and they're doing something with your product. Or if it's a physical product, they're touching it there. That's the difference you're making in the world. And if you can't be empathizing for that person and telling stories about that person all the time, you're not doing the same thing you can to help your team. So just make sure you're understanding your users all the time, what the product actually delivers for value, how they expect it to work, how it unboxes or onboards the user. People always underestimate the importance of onboarding and unboxing. That's when a product first gets in the user's hands. They're actually like, what does this thing do? And then they can't figure it out. And they're like, oh, this thing sucks. But if you actually get that experience right and Teach them step by step how to use the product. I spend a lot of time talking about onboarding. It's an area I got to work on at Twitter and at LinkedIn. And can just talk forever about how important and what difference it makes when you have great onboarding. And then you've got to continually listen to all that feedback. So to kind of summarize this whole long, rambling talk— you guys have been a great, very patient group— fundamentally, your job is not to make decisions, but coordinate all the key decisions with everybody's input. Negotiate all the disagreements and make progress and get the ultimate consensus. I like to call it disagree but commit. At the end of a conversation, if people are still not on the same side, it's okay. The team has to make a decision. Sometimes that does fall on you. Sometimes that does fall on majority vote. Sometimes that does fall on somebody who's not in the room like an executive. But you guys need to make a decision. And once you do, hold the team accountable to committing to it. I just find so many times people will— the worst thing you can have on a team is let things get rehashed again and again. But last time— oh, why do we still do this? Why are we still doing the feature this way? Just get it done. Turns out that's actually much better. Don't just try to build what you think is right. Look, we're all smart. You guys are all great product managers in the room. But if you're bullheaded and don't listen to your team, you're not going to have them wanting to work with you the next time. Now, when I say don't just build what you think is right, I don't mean build what you think is wrong. But I mean, like, don't be blind to everybody else's input. And sometimes the best thing you can do is not what you started with, but what somebody else did. The team's not just going to take your orders blindly. And ultimately, don't forget where credit is always due. Ken Norton, who I think you guys might have seen if you came to the last talk, always talks about being the one who brings the donuts. And I just think it's even more important. Like, no matter what, when you're in the company, it's like, your team shipped a great— You shipped a great feature. And you're like, the product manager's like, yeah, uh-huh. That's terrible. At the end of the day, you're like, there's always a great team behind you who's actually doing all the work. And your job's never done. Once you ship, that's only the beginning. You've got to start learning, thinking about the next thing you're going to build, thinking about how this thing's going to have impact on the world. You've got to be looking for areas of improvement, looking for the impact you have. I find that everybody's like, oh, we launched. Launch party. Everybody go home. Rest. And maybe for the engineers who've been writing a lot of code, designers who finally got their final mockups done and were just submitting images, they might get to rest a little bit, and totally deserved. Man, the product manager's job couldn't have just gotten harder than that first day of launch. And lastly, no product's ever finished. It's never perfect. I mean, Apple's such a great example. With every new phone, they're already thinking about the one a year ahead and 2 years ahead. You simply have to just keep moving forward and keep moving everything forward and always be looking out. And yet, understand the discrete milestones of launching and putting things in the hands of users. The other hard part with this model is, as a product manager, you're often always thinking ahead. And you're totally forgetting the experience users are having today. You've been on the beta build for 2 months. You've been using all these new features. And then you start looking in the wild. And you're like, whoa, they're actually having a terrible experience. If we had made this one extra thing we could have made, their experience a lot better in the meantime. Be very careful of that. Now, I mean, it's a slippery slope to keep shipping without doing some of the big ambitious things. But you just have to remember that we all have great Wi-Fi, great LTE, the newest phones. We are missing out on the entire rest of the world. Facebook now, as a company, has started to have what they call 2G Day, where they turn off some of the cell towers and everybody's on 2G traffic in order to kind of feel what it's like in the rest of the world. I was talking to somebody today. They said, look, a lot of people in India are afraid to click on links because literally you just don't— you're megabyte constrained on your data plan. You don't know what the link's going to do. So many web pages are like 10 megabytes of code with ad code and other crap that comes down and takes forever on a slow connection. So just remember, your product's never finished. What your users have isn't the same thing as what you do. And you'll be fine. It's an ongoing process of continued development to make it better. And that's kind of what we all get to do. So this is— I don't know. Anyway, this is sort of my story of how I try to define product management to my mom and to my teams and stuff I've learned in my career. I'm super happy to take questions too.

Great. Well, let's— Josh, that was an awesome talk. So awesome. Like, you covered such a wide range and so much advice in 45 minutes. So much PM advice, hopefully, everyone. There's a lot of great tweets and a lot of good notes.

So let's definitely—

Josh has said he's excited to take a lot of Q&A. So let's get some questions going.

We can start over here. So does your mom finally understand what product management is?

Sorta.

Yes, in that she understands how I'm in the room with all the people kind of building the products and helping make a bunch of decisions. She still doesn't quite understand what I do all day though. Meetings, notes, et cetera. There was one over here.

Thanks for being here, Josh. How do you know when you're spending too much time on design? There's kind of that fine line where you want to give design enough space to really spend time on You know, designing. How do you know if you're over-designing? Because it definitely can happen. I'm just curious on your thoughts there.

Yeah, that's a great question. And the answer is, you're always feeling like you're spending too much time on everything and too little. So the short answer is you have to move things forward at a cadence. And what I like to think about is like, look, at the end of the day, we can keep iterating on this thing, but we're not going to get it that much better. Our users, as I said, our users are using this old product, this old version. If we just even had this out— what I like to ask designers is like, if we just had it out like this, wouldn't we feel a lot better? It doesn't mean we can't improve it from here. And so you really want to put pressure on people to kind of get to good enough. You know, there's no— there's never a perfect. And so the product— your job is really to say, look, is it good enough? If we put this in the hands of our users, would we feel enough better that it's worth testing? And if one of the issues is some people want it one way and some want it another and we're kind of like trying to fit too many things, we're like— sometimes you're just like, let's build both and test both. It turns out it's often easier to build both and test both than to— and faster than to keep iterating on the damn design as well. And the last thing about testing that I've just learned so many times, like we think we're in like an ivory tower and we can like pick the perfect thing that will work the best. Being very clear about the metrics we want to do, The best thing you can do is build a couple versions, enough that feel right. I mean, if something feels wrong, don't ship it. But if it feels right, you put it in the hands of people and you actually see what works. And we have, whether it's usertesting.com— it came after I was a product manager, so I haven't gotten to use it directly. But all of that, Optimizely, we had to build a bunch of those tools back in my old jobs. It can really kind of help you make much better decisions instead of— constantly sitting there and designing and tweaking. So.

Hey Josh, thanks for joining us. You've worked at some really incredible companies with obviously some of the smartest engineers and the most brilliant designers. So I was wondering if you might have any words of wisdom when it comes to like managing the egos of really superstar teammates, like especially when things can't be 100% the way that maybe your engineer wants it, how do you keep them motivated and aligned with the bigger vision?

Yeah, look, it's a great question, and I've worked with some great people. Some were harder to work with, some were easier. Many of the people, by the way, who were really hard to work with have actually turned out to be amazing founders and building great companies. So I've kind of learned— the one lesson I've learned is like, if somebody's really hard to work with, and like really tough and they won't kind of do anything, but then they go on and decide to go found a company. Once it flips and it's totally on them, they're like, oh, that was why everybody used to think I was a punk. And then they turn out to be like great founders and really talented. So just if you see those people and they found a company, just invest blindly. My mistake, by the way. So look, the only way I've been able to create any success at keeping everybody on track is just be really clear about the goals. and the metrics, and what our team is being asked to deliver. At the end of the day, if we're asked to drive growth, then the question to the engineer is not a fight about I said, you think, I think, we think. It's, look, we need to get users who are coming to this product to use it more often. We need to figure out how we solve this retention problem. If you have a better way to do that, then I'm all ears for supporting that. And by the way, let's make that the feature we do next time. But if we get this one out and it has any metric growth, you'll be really proud of the metric impact you had on the business. And I always try to tie their work as closely back to the overall business goals as I can and to the set of decisions teams made and that people are depending on them. And you kind of put the burden on them. Like, if you want to be the guy who's like, we should just do what I think, well, how are you a team player? And people do end up feeling a little bit like— when they understand it and it's clear and the vision is clear and they know it's going to be accountable, and they know there's going to be metrics evaluated afterwards, I've found that they tend to actually perform fairly well when they understand all that. And when they don't, then it's very easy to fall back into the sense of what you're asking about. And I can imagine many of those situations. So I'm curious how general you think the advice that you've provided is towards the enterprise. if you had to maybe pick one of your points to emphasize in an enterprise context and one of them to deemphasize, which 2 of those would be? That's a great question. I literally have never worked at an enterprise company. I've been inside them a few times. So I don't know when you have to do sort of day-to-day work at an enterprise what truly— how truly different just the job is and what the sales process is. And now that we're in a SaaS world where where at least some set of enterprise products, whether call Slack an enterprise product, but sort of consumer adopted, enterprise monetized, or like Atlassian, that's sort of developer adopted, enterprise monetized. I think those are actually pretty similar to a lot of what we talked about here. If you're truly building like an ERP tool that has to get sold through a big sales force, I think there's a much bigger sales component that comes into the needs and analysis, And it's probably a little bit more of that, and it's either helping educate the team as much as you can about that so that they'll make good decisions, or understanding that there actually is a different decision framework from the input that has to come into sales is probably the biggest difference. But having never worked on an enterprise company, you guys who work on it, I'm actually much more curious to what you think is good takeaways and what you think is like, no way, that would never fly.

Hi, up here, Jared.

Hey, Josh. So when you talk about your experience as a PM and you kind of describe, let's say, general advice, do you feel like there's anything to focus on skill-wise from an early startup, so for instance, your early days at LinkedIn, to maybe when you were at Facebook when it was scaling?

So the first thing is get really good at interpreting data. How about I'll say interrogating data? Because figuring out what questions to ask is actually the single best skill you can learn. And this is why actually people who've done sort of investment banking, consulting actually get very, very good at learning how to ask questions. Now, they don't necessarily get great at how to turn that around into like, OK, once we've understood this data, we know how to creatively problem solve and build the next thing, which is I think a very different skill that's also very important. But understanding— like, I'm assuming most people who kind of get excited about product management start with that sort of creative builder bent. And so the thing you want to add is understanding how to interrogate data, ask questions, figure out what's going on, figure out how to tell stories from that. And then the second one would be how to write down a user story and tell a user narrative. And if you can do those 2 things on top of being creative and saying, we should build this, and whiteboarding and and brainstorming, then you can actually be really great at providing real value for the business and pushing the team. Hi, what's the delta between what you define to be a good PM and what you define to be a great founder? And for people in current PM roles who want to eventually get there, what do we work on?

Yeah.

It's a great question. Look, to be a great founder, you're doing something very different than being a great PM. You are identifying a problem in the world, and you are figuring out how to marshal resources towards solving that problem in the world. And to do that really well, you have to figure out how to articulate the problem you want to solve, the story you want to solve it with, 'Cause that part is similar to PM. Get really good at articulating the story, how you're solving it, understand the data. The skills you have to go learn that you often don't learn as a PM are how to hire, how to manage people, 'cause you don't actually manage people in most product management roles until you become a product manager manager, but even then you don't have nearly the same size of teams as you do if you have, if you're in engineering or sales or other organizations. So To learning how to manage people and learning how to raise money and learning how to actually tell the story in a very sequential way.

So before I was a product manager, I was in user experience. And one of the things I learned in user experience was I would tell my PM all of these great ways to improve usability. And product manager always said, hey, we don't have the cycles for that. And now that I'm a product manager, I realize, oh, I'm trying to balance revenue. I'm trying to balance growth and user experience. What kind of tips do you have to balance those 2?

It's a great question. Look, the challenge of balancing user experience is really tying it back to metrics more than just— and this is what you're learning as a PM— is tying it to metrics. And so when you look at the user experience and you're like, look, They stumble a little bit here, they stumble a little bit here, they stumble a little bit here. How bad is it? Because they're really getting through. You actually have to break it down to really be able to quantify it a little bit. It's sort of one answer to that question because that's the— the other thing though, the other answer I always like to give is I always just have a couple of freebies for the team just to clean stuff up. Like in every product roadmap, we always had some slop. That was just like, what do people want to clean up? We're not quantifying it. It's just like, if it makes you feel better. I would try to look at it afterwards to make sure we didn't make things worse. Because that's really important, by the way. Oh, we're just going to clean this thing up a little bit. And then you're like, wait. You refactored it and took away the one feature everybody used. Or they can't find that thing anymore because you buried it because the perfect, beautiful menu is so much worse than the 3-button option. But I think that's the nuance is you can't— you also, I mean, at the end of the day, you need to be really good at quantifying what you really invest the team's resources in. You create just enough space to let people get their pet peeves out because it turns out that the people's pet peeves on the team do actually play out through the rest of it. I always think of our roadmap like portfolio theory, like when you're investing. Which is like you want to do a bunch of things with very high beta. And then you want to do a bunch of things with moderate return, but you're pretty confident it'll get there. And that'll kind of balance your portfolio to try to optimize for great outcome, but not just blow it all and totally miss on a quarter.

Hey, what are your favorite questions for interviewing PMs, either for your own teams or just as a peer?

on your own team? Yeah, it's a great question. A lot of times I spent a lot of time when I was interviewing PMs on what they did in the past and actually having them walk me through decisions. And what I was basically looking for is how articulate were they about, well, here's what we were trying to do, and here's what we did, and here's what worked and what didn't. And if they were pretty thoughtful about what they tried to do and what they did and what worked and what didn't and what trade-offs they made, I was like, OK. Like, you've generally thought about this in a good way. And so a lot of times, actually, I would spend just digging into their current work. I would always ask them, what is the product you admire most right now and why? Because again, you want to hear somebody admire it. The third question I would love to ask was, what is the product you most want to fix? And so I would kind of try to hear them articulating their thing that they use that they would really want to go fix. And then this used to be my business question, which is not as relevant anymore. But I'm trying to figure out what the current version would be. Is I would always ask product managers, so email, everybody says you can't monetize email. AOL, Hotmail, Yahoo Mail, this is going to date me because this is like a 2008 era question. But I'd say AOL, Hotmail, Yahoo Mail, Gmail, like they all say they can't monetize. Gmail kind of shows crappy ads. And yet if you talk to every single e-commerce company, they will tell you that email is their number 2 channel after search for driving real revenue for them. So if these guys are all making all this money on email, and you're building an email product, and you can't figure out how to monetize, what's the gap? What would you do if it was like, let's go really monetize email? And the crazy thing to me is one of the answers I always had was go try to build a marketing inbox that whenever you want to go shopping actually organizes all the emails that have come to you for shopping that actually shows you the discounts and the sales and the expiration dates in a really good order. It's not until last year that Google shipped that Promotions tab, which is like a crappy version of it. And maybe that's a terrible idea, and so it was a dumb question, and the reason was you really couldn't monetize email. But I always thought there must be somewhere where you can identify that business gap. And so looking at what those might be today, whether they're mobile messaging— how do you monetize mobile messaging? Although you don't hear companies today saying, I make a ton of money off SMS like everybody does off email. But I think there's a lot of questions sort of where you see that value gap, where— and sort of how would you creatively build a business, 'cause then I was looking for the business thinking versus just product admiration. You mentioned in the beginning that today you feel like being a VC is like being a product manager for multiple startups. Mm-hmm. No, I didn't quite say that.

Wow.

I didn't quite say that. That's not true at all. It is like interviewing for jobs at multiple startups.

True.

But how well do you feel being a product manager helped prepare you for your current role as a VC? So look, I think what prepared me the most for my current role— and by the way, the hard part about VC is I have no idea if I'm any good. I love the companies I'm working with. I think all of them have a chance to be massive, massive companies. The founders I'm working with are some of my favorite people to get to work with my whole career. But VC is a job of people have given us money and I have to give them a lot more money. And it takes a long time and I may or may not do that. No matter how good or great companies I'm involved with, they may or may not do that for a large number of reasons, sometimes macroeconomic, sometimes luck, sometimes imperfect execution, bad choices, all these things. But I think the thing that really prepared me wasn't just being in the product seat, but was constantly thinking about products and where they were going and thinking about the product strategy and the trends and getting to understand what it took to scale and getting to understand like what decisions did we make that made a difference on why Twitter worked and why Facebook worked and why LinkedIn worked and why Zazzle worked well but not as well as some of those and just kind of keep getting those eyes in those stories. I've just made me able now when I'm meeting new companies to kind of like identify what are some of those same trends happening today that have a chance to go be a lot bigger and what can follow some of those journeys. And hopefully, more than anything, the instincts that I used to— I try to just go back to whatever instincts I used to pick those companies. I'm trying to find those same instincts in me now even more than stuff I learn day to day. What about the dark trash today?

Huh?

What are the trends today? So the question was, what are today's trends? You know, I have this weird feeling with social media right now where we're actually shouting at each other a lot more than ever. And yet, we're kind of more alone. And it's this really weird phenomenon where, what do you do? You look at Instagram. You're like, oh, that's a nice picture. That's a nice picture. Oh, they're having a fun time at that party. Oh, that looks like a really good meal. And when are you doing that? It's like when you're sitting in bed. And you might have had a crappy day. And you aren't really getting that emotional engagement. You're not going to post a picture of yourself in bed having a crappy day, because nobody will actually like your photo back. And so it's this really weird phenomenon where I feel like we're kind of moving away from each other instead of together. So I'm trying to think about what are the trends that are going to react to that. Snapchat was this amazing thing that was a phenomenon a few years ago that reacted to the fact that the world was so public. Everything, if you grew up, if you were like 20 years old or 18 years old when Snapchat came out, you lived in the, you were born like when Netscape launched or whatever. And you grew up in an era where everything was public and if it was on the internet, it was Googleable. And if it was on Facebook and you were tagged in it, mom liked it within like 30 seconds and it was totally embarrassing. And so like the idea of a product that made stuff private was like revolutionary. And so everybody who was in that demographic got on Snapchat because they were like, wait, I can send this to you and it just goes away? Like, really? Like, I'd love to send more pictures, but they go away. And so they really hit on that trend. So I feel like what today's trend is, we're starting to get in this world where we're all shouting at each other so much. Like, how do we really spend time together? Whether that's products that are like the live internet— it's part of why I was excited about Discord that I talked about is it's part of the live internet. We play games together. You know when I'm sitting there playing a game and I'm on voice with you, you're playing the same game too. And the people, when they're doing that— if you play games, this probably sounds totally stupid. But if you don't, what I found observing people is they're like, oh my god, great shot. And then, oh, today in class, I can't believe the teacher did this. I'm like, dude, good shot. And so you're constantly having these very emotional, personal moments at the same time as you're playing this game. And it's live shared, even though we're not sitting in the same space. I think on mobile, part of the reason I invested in Meerkat a year ago was I turn on my phone and you're all watching exactly what I'm doing. I know that there's no way that— we're having this moment together. And you're choosing to allow me to be a part of it. So I think the live internet's going to happen. I think interest groups where we feel like we have more people that we have in common with, where we're not just trying to impress our friends, but like, oh, we all like football, or we all like rugby, or we all like cricket, or we all like knitting, where we can actually just come together and talk about that stuff and get good feedback on the stuff we're talking about that we care about. versus constantly trying to peacock to our friends. Peacock, like showing off your big flowers. And so I think there's just a lot that's going to happen that's sort of a reaction to the world we've created today. That's how it always works. We build some amazing stuff. And Facebook's incredible. Instagram's incredible. Twitter's incredible. And yet, they're causing a lot of behaviors that I think will change. That's the social media world. There's like, obviously, is Bitcoin going to be a thing? The Internet of Things and consumer electronics that are all connected is going to be a massive trend that I'm super excited about. All these local mobile services, I feel like now we can get a car from anywhere. We can get food. There's still so many more things that can be connected to us in really easy ways. And we're giving people new employment. So it's a lot there.

I have a comment and a question. So my comment is I've been in product management for 5 years. And one thing that I've learned that's been really helpful is being able to ask for help. Because managing multiple cross-functional products, you have— you're forced into a project manager role. But I've learned that it's okay to ask for help. So I often go to my peers, my team, to really support and get their perspective. So when you think about asking the right questions, also if you have a good team and they understand the problem, they'll actually present the questions for you. So that's a comment I agree with. everything you said from before. But the question I had was around UX and PM. In your past companies, was the UX a function of PM, its own function, or a function of engineering? And where was that kind of work structure? What did that look like? Just curious.

In most of the companies I was ever at— I'll take the Diet Coke. Oh, thank you. In most companies I was ever at, design and user experience was always a peer to product management and not something that was under it. You know, at the very executive layer it gets wishy-washy. Does sort of the design team report up? But I was almost always in matrixed orgs where design sort of reported up and engineering sort of reported up and product sort of reported up. We had like all this implicit responsibility with zero accountability and authority. And it always worked because at the end of the day, like all the stuff I talked about, like how do we just define the team and And work on this stuff together, and we're all in the same boat. And I just spent all my time focusing on that. And sort of like, look, as a PM, there's things you can control and there's things you can't. And you can either keep railing against the system and wanting to control the things you can't, or you're just kind of like, hey, this is the boat we got. This is the goal we have. See what we can do. And it worked. And look, I was really lucky to be at companies with strong founders who had strong visions, who pushed things forward, and everything else.

Yeah.

So it's not— I know that this is always difficult and challenging, but once it gets into politics and you're fighting about the what and the who, it just dies. And so try to— I mean, and product managers, the other worst thing about product managers is we're amplifiers. If stuff's going well, we're the biggest cheerleader ever. If stuff's going wrong or we're fighting, like PMs are fighting with each other, holy crap, the whole company falls apart. Because it's like parents are fighting, what are the kids supposed to do? And not that it's parent-kid with your team. But it's like, oh my god, those are the people who are supposed to be helping us. And they're in a total fight. It can be really devastating. So the last 10, 15 years, it seems like the process of product management is to have more empathy for the user or customer, right? You've got product-market fit much earlier, customer development in a fast iteration. What do you see as the trend in the coming few years? And what do you want to see, actually, in product management? So that's a great question. Because people forget how revolutionary Don't Be Evil was from Google. It was literally— I was working at RealNetworks, which, man, we made decisions at RealNetworks that were not in the user's best interest. There were times where there was some things checked below the fold. That when you were checking out to buy the RealPlayer, you'd be like, spend another $15 on FreeRAM Pro? And it did make more money for the company, but there's no way a user really wanted to buy FreeRAM Pro. And if they did, by all means, we should have sold it to them. And Microsoft was just notorious. And it wasn't that Microsoft was anti-user, but they definitely just didn't always design with the user in mind. Part of this is because technology was so hard to build. You spent so much time just getting something working. Actually, thinking of the user was like— I don't want to call it an afterthought, but it was definitely a final thought. Whereas like now, like literally, you can like spin something up on Amazon Web Services, write a little bit of code on Parse, and design something great, and you have a whole product that's working without all this extra heavy lifting, so you can spend a lot more time on the user. So I think that's one big part of the trend. You know, I think the goal— so I just think it's like this amazing trend. I think we always— Forget, like, oh, don't be evil. That sounds stupid now. And like Google, whether or not we consider them evil or not now, or that's really true to this day, it was definitely revolutionary and important to be user first and how they really got us on this mindset of being user first. I think now the question is, how do we help each other be better to each other? Let's go back to, like, if anyone's been trolled or DDoSed or whatever it is on Twitter, it sucks. And every once in a while, I get trolled by somebody. I was trolled on Secret a little bit when that came out. And like, they just— this sucks. And like, it really does hurt when some other human being is shouting at you in a way to make you feel bad. And yet, like, we're all connected. We're all online all the time. Like, how do we help each other be better? Biz Stone, who's the founder of Jelly, which is— I'm an investor in Biz's company. And we're going to relaunch it pretty soon. Like, when he started Jelly, he was like, we're all connected. Like, I helped build Twitter. We're all connected. And yet, like, why can't I just ask a question and get help from somebody else in the room? Like, the fact that we're all connected means somebody needs help, we should be jumping at the chance to help them. And how do we go build products to do that? So I would love to see the next 10 to 15 years of us figuring out how to be like, build products that like truly aren't just great for the user, but are great for like the group and make the group better to each other. And I don't know exactly what that means or— what that's gonna happen, but I think like the live internet bringing ourselves together when we're alone, the stuff like Jelly that's like ask for help, get help, that's like pretty powerful. I think there's a lot there.

So Josh, I'm next. Hi. I had a question about product manager's best friend. We call it roadmap. So in all of my past experiences as a product manager, I've been kind of given this initial version of a roadmap, and I've kind of had to build on top of it and keep it going. But in my new role, I've been asked to build a roadmap for this new business concept. So any tips around what's a good logical point for standing up the new version? Would it be at the beginning of your research, middle of it?

What do you mean for spinning up the new version?

It's sort of like this one word that the executive thing is a great area for them to invest in building a tool for, but it's just a word and there's a lot of work that needs to be done in terms of research before you can even say that this is our roadmap and this is how we're going to execute on it.

So I think the first step is tell stories and to say, if we achieve this, if we're trying to solve this problem, here's the problems people have today and here's the way in which we could help them solve it. And the next thing is to say the goals. If we achieve this set of problems, here's how many people have it, and here if they solve it this way, this is what it can mean for the business. And help them get— that's like the business and user story. Like, you really want to tell that story. And if you tell that story, then you're like, then the very first learning test we would do to figure out if this is even viable, if we can actually take people with this problem and do this, is this type of product. And then build the simplest skeleton you can. For that type of product. But I think it actually really starts with the stories and the storyboards and like getting everybody bought into that. And I often find if you're really with very businessy business execs, you need storyboards tied to the business story versus just great things. If you're working kind of at the companies I worked at, which are very product-centric founders, then it's actually these storyboards that tell the user story. They then will craft the business story in their own head. So, we did less business case modeling. All right, we got a couple more.

Question here, and then we can break. And Josh, maybe you'll stick around for a few minutes. You can catch people one-on-one.

Hi, Josh. So you mentioned how documentation is probably one of the most important things APM can do. I was wondering, you know, based on your experiences, do you have any kind of tips or pointers on, like, best practices when it comes to documenting? Because I know it's really easy to, you know, write, you know, a ton of documentation and write all these things that people won't even read. Yeah, I was wondering if you could share some of that.

Look, what is a joke? I would have written half as much if I had twice as much time, I think is really, really true and really important for product management. And I think one of the goals of product management is to spend twice as much time to write half as much. Because it turns out that when you can actually distill it down to like, this is the vision statement for what we're building. This is the user story outlined in a couple of key scenarios. And you actually keep iterating on that to get it that simple, then it gets repeatable. I used to spend a lot of time on finding the way to describe something in the company where you'd find the right code name, but people would actually know what the one sentence it referred to afterwards was. We had this thing at Twitter when we built the user recommendation service that we called it WTF, which was for who to follow. But every time people said it in the company, it made them chuckle. So it was like— it's a great thing, by the way, when you have little jokes. Everybody smiles.

Yeah.

What are you working on? WTF. And then, who to follow? And then what it was is like, we need to build our following graph. And so we're going to be figuring out how to push a lot of recommendations of who people should follow by analyzing our graph. And everybody kind of understood the feature from the funny little code name all the way down to it. And so you really want to figure out how to write like very simple statements of purpose, very clean things. And then, you know, again, this is why I spent all those time on that meeting notes was that it would be outlined with like, Here's the action items. Here's the key decisions made. Here's the couple of next steps. Here's the updates and lookbacks and things that we learned. Versus if you just kind of write everything down that's in your head, then you force the work on everybody else to do the interpretation.

Cool.

All right, great. Awesome, Josh. Thank you so much for sharing all your advice with us. And we'll give away some prizes. We'll give away some prizes. And maybe Josh will stick around and answer a few questions for people.

Awesome.

Thanks.