Women In Product Nov 2nd Event at Sequoia Capital: Product at Startups

Thank you so much for being here tonight and for spending your evening with us. I am so delighted to welcome you. My name is Manee Swigert. I'm with Women in Product. And for those of you, how many of you have been a part of.

Our community for a while? Yeah. Awesome.

Good, good.

And you're a part of the Facebook group as well?

Yes.

And you are signing up for the newsletter.

That's how you found out the events.

Awesome.

Great.

I just want to welcome you. It's been such a fantastic ride in the pat 18 months. Our community started with just 10 product leaders. Who was talking about who's going to the Grace Hopper conference. The leaders were thinking about, hey, why don't we have a conference just for us product managers? And that's how this community just started. Since then, we've been doing a number of events. We did our first conference last year, September 13th. How many of you got a chance to go to that one?

Sweet.

Then we followed up with the second conference on September 19th. And how many of you had a chance to attend?

Wow.

Wonderful.

It's so good to see return members to come and continue to support and grow the community. Thank you. It's because of you. That's why our community have grown from 10 product leaders to now 6,000 members in our Facebook group. But 5,500 is our new newsletter feed. We really appreciate your support and continuing spread of the community tonight. I'm just so delighted to be here and I'm just so grateful for Sequoia, our product partner here, that have sponsored the event tonight for us. And you're going to be hearing from some awesome ladies tonight. Before we get started earlier, I think today or yesterday, you might have got an email from women products swapcard. How many of you got that? Okay, so we're doing new things. We want to increase your experience being part of the community and so we partner up with swapcard to connect you. As soon as you register through the eventbrite, your information will be uploaded to swapcard and. And it's really up to you if you want to connect with your fellow PMs, either before the events, during the events, or after the events, or if you have questions you want to follow up with the speakers, you know, you can certainly send them questions. And again, this is all you know based on your preference, if you want to accept the request or not. It's going to go through LinkedIn. Just a normal way you connect with people and it's a great way for you to keep track of business cards. That you're going to be exchanging tonight too. You can take a photo of that and snap that and it'll upload and save you and create a Rolodex for you. But the most important thing is that we learned from the conference this year that we did the workshops, right. So a lot of you didn't get the email that I sent out in terms of which workshop you actually signed up for and you didn't know where to go. So we're hoping that with swapcards we can provide more better experience, better communication, faster time so you can see where you're at and create yourself your own agenda for the day. Okay, so after this event, I'm gonna send out a survey. I would encourage you to please take 2 minutes to complete that survey. It really help us to gather, you know, and again, understanding if workshops that we were putting on like tonight is helpful to you, and we also wanna hear from you what other things you want for us to be able to provide. Okay, so without further ado, I want to invite Mike Verno up. He is the early stage partner here at Sequoia and he's gonna introduce the panel.

Cool.

Thank you, everyone. So first of all, thanks to everyone for coming tonight. I realize you're all incredibly busy and your time is very valuable, so we appreciate you coming and spending your time with us. So maybe as a little bit. And we're sort of incredibly excited to be able to host this event and support and partner with women in production. So maybe just a little bit of quick context on Sequoia. So our mission at Sequoia is to partner with daring, exceptional founders who want to make a dent in the universe through building sort of legendary companies. And over the years, we've been lucky enough to partner with some exceptional founders and exceptional companies. In our early days, we were the first investors in Apple, in Google, in Oracle and Cisco and a couple others. And more recently, we've been lucky enough to partner with companies like Airbnb, WhatsApp, Dropbox and Stripe. And so we feel incredibly fortunate to be able to partner with sort of exceptional founders that are trying to build really, really interesting companies. Now, interestingly, 20 years ago, I would say the majority of startups were effectively started by salespeople. And I think the dynamic that would happen is you'd have a salesperson, they'd be selling a product, they'd figure out that there was some hole in the market, there was some economic opportunity, they would go and they would spin out of their company, they would start a new company, they would hire a tech team to go build a product. The product would be differentiated based on some bullet points against the product description and they would sort of distinguish themselves by their ability to sell. Now, in the past 10 years, with great consumer products like iPhone and Instagram and great enterprise products like Dropbox and Slack, we've really seen this rise of the best product winning, obviously in the consumer space, but also in the enterprise space as well. And because of that, I think we've seen this sort of tremendous rise in product people as the founders and CEOs of companies. I would say the majority of the founders that we meet and probably the founders that we partner with today are sort of fundamentally product people by training. And so we, you know, we feel incredibly lucky to be able to support women in production and events like this for probably three reasons. So first and foremost, we are all builders here at Sequoia. Both Jess and I are sort of formally trained as product managers. One of our partners, Bill, sort of built Bell Labs and then engineering at Google. Matt Huang, who's one of our partners, was a founder at yc. And so sort of by our DNA, we are fundamentally builders and we sort of derive our satisfaction by supporting other builders building products and building companies. Two, we all know we have a sort of diversity and inclusion problem in our ecosystem and the way to solve that is at the top. And so we are given the fact that the vast majority of founders, I think in the future are going to be product people. We want to do everything we can to support product people and hopefully a number of people in this room will at some point go on to found companies. And our door is open when you do. And then sort of lastly, we are in the business of supporting exceptional, mission driven entrepreneurs. And I think that definitely describes the people who started Women in Product. I was lucky enough to get to work with a bunch of them like Deb and Stephanie and Fiji at Facebook, and they're all exceptional. And so we're excited to be able to support ventures like this. Now, sort of without further ado, so thank you for coming. And without further ado, I would love to introduce Jess. Jess needs no introduction, but she's one of the partners here on the venture team and before that she was the founder and CEO of Polyvore. So with that.

Hey everyone.

So I'm Jessica, I'm the newest partner here at Sequoia and I'm also a PM by training and I have now the privilege of partnering with really amazing founders. And I myself was the founder before this. I was Interestingly, actually a super user of a product called Polyvore. Then I wrote in to complain about it, but because I was a pm, I wrote in with complaints and suggestions for how to fix it and then they hired me as the first pm. PM later made me a honorary co founder and then I became CEO. So it's a little bit of an unusual path to starting a company or being part of a startup experience. But I will say I think the training of being a PM is incredibly important for just starting a company and being a CEO. I think a lot of PMs are essentially mini CEOs of the feature that they work on the product, the business. And that was certainly the lesson that I took. But, but part of the reason I went into venture is because I really as someone working on a product, as a female founder, a female CEO targeted at women. Polyware was a shopping and fashion product. You got two ex Polyfam in the back.

Hi.

It can be kind of difficult sometimes to raise money, so that's part of why I went into venture. And I'd love to see many of you go on to start companies. So let us know if you do. But in the meantime, we're here to talk about amazing product management. And so we've got an awesome array of panelists. So I'm going to let you guys introduce yourselves. They've all had very interesting path into product. So tell us a little bit about what you do now and your path into product and what you think defines a great product manager.

Good question. I'm Gloria, I currently work at Stripe. Stripe is the technology company that builds economic infrastructure for the Internet and we support everyone from brand new small businesses to public companies like Salesforce and Facebook, accept payments and run their businesses. I've also worked at Apple. I joined Apple about 10 years ago right after the iPhone came out and worked on a lot of new technologies for iPhone and ipod. And after that I worked at Flipboard Social news magazine and was very early fifth employee there and was head of product and led that for four years. So what is great product management? That's a great question. I think it's really about doing two things. One is to help build better products. So define what is the thing that you are trying to build? Why are you trying to build it? Who are you trying to build it for? And the second part of that is building products in a better way. So how do you work with your development teams, which is engineering and design primarily, but could also involve a whole range of stakeholders across your company. How do you work with them in better ways to create a process that will actually work across different types of things that you're developing to make sure that your product velocity is good and that your product quality is really good at your company.

We're going to pass the mics back and forth, so we'll do the awkward dance. Hi, I'm Olivia and I currently work at Dropbox and I work on a lot of the collaboration products as well as the Dropbox platform platform and our ecosystem of integrations and partnerships, as well as all the APIs that people build on. You asked about path into product. Okay, so I did product before I knew what product management was. And I only learned years later that that's what I had been doing at this very small startup where I was building a new Internet radio station a very, very long time ago when there was barely bandwidth for that and have been in and out of product most of the time since. So what makes great product? I think I'll echo Gloria in saying build things that create value in the world and that people will love or will solve their problems even if they don't know that they love it. And the other piece of product is similar to that process piece is figuring out how to help the people you work with do that. Because so rarely are you, the person who's actually building it, doing it, doing any of the things, but figuring out what it is that the people you work with need to do their best work. So, yeah, figure out what problem you're solving, actually solve it, and actually help the people you work with solve it.

Hey everyone. I'm Clara. I'm currently at Airbnb. At Airbnb, I'm on the product management team and I look after our host communities. So the four and a half million homes that are on our platform and the hosts that provide the hospitality, my team looks after them. My path into product is actually somewhat nonlinear. I actually started my career as a designer, went from being a designer to being in professional services, went from professional services to engineering, from engineering into product. So I've kind of danced all over into various functions and just found that I kept gravitating back into product for the cross functional collaboration and the connection of your customer or user, the team and everything in between. And so what I think of when I think of great product, it's actually different at just about every single company. The exact manifestation of what a product manager does. So I don't actually have a one size fits all answer. But generally, as these ladies said, you're figuring out the market and the opportunity and making sure you're building great product for it. You're holding your user at the center, and internally you're working with your teams. And I like to kind of say that great PMs are hungry, humble and brilliant. Hungry in that you have to be crazy driven to figure out really hard problems and dot all your I's and cross all your T's and make sure nothing drops. Humble, because it's really not about your opinion. It's about the user you're serving and the needs they have and how you actually win a market. Possibly putting your own opinions aside sometimes. And brilliant, because what we do is hard and the world is changing fast. And you have to be able to recognize patterns and learn from every person you talk to, your team, your customers, et cetera. So that's maybe what I think makes up a great product manager.

So for you guys in the audience, how many people here work at a small startup? Let's say under 50 people. Raise your hands. Okay, so. So there's quite a few. What about between 50 and 100? What about 100 and up? Okay, so we've got a pretty wide range. You guys have worked at a variety of stages. So things as companies as large as Apple or Yahoo. And then also, I think you were the first PM at Stripe, although that was when there were 80 engineers and then she came in to run product. Talk a little bit about what the difference is between product management at scale. Scale at large companies versus at smaller companies. Any of you.

So at a large company, I mean, of course every company is different, but at a large company, a lot of the processes are already pretty developed. And so there's a pretty clear path to. Okay, well, if you want to ship something at Apple, here's exactly how you get it done. Here's how you get your stakeholders on board. Here's how you define the new market. Here's how you work with engineering to actually build the thing, test the thing, ship the thing. And at a small company, or at a company that's not small, but is new to product management, like Stripe was when I joined it at about 200 people, that's when Stripe had their first product management professionals, I guess there was a lot to be done. There was a lot to be done in actually developing the product. But also in terms of, there was great opportunity to come and define a lot of the processes. How do we do product development? What are some of the building blocks we need in order to work together more effectively as a team? Those things are all missing before there were any official product managers. And so that kind of could have felt like extra work. But in the end, I think it was a great opportunity to try to help build and define what those processes look like so that we work together ultimately in a much more effective way. So it's not just about looking after your product area, which is very important, of course, in saying, like, here's where I can help my users. But a lot of it's about how do I create the template for ways that we work together better. So how do we create product briefs and product calendars to explain what we're working on and plan that, how do we do roadmaps and all that stuff is really important. And you start to see it because you start to see throughout the organization, it just kind of happens organically. You'll just see people, engineers and marketers, and all these people are just writing product briefs, and they've never done that before. And you're like, oh, wow, this is great. We're actually much more effective as an organization. And you see yourself being a force multiplier. So that has been really rewarding to see.

Okay, I'll maybe add on to that and say, one of the biggest differences that I see, and I have a number of entrepreneurs on my team now, so this has been in stark contrast recently, is how easy it is in a bigger company for more of your time and energy and attention to become internally focused. So the coordination tax, the cost of how do we create alignment, how do you get everyone on the same page to rally, to do the same things, to do the briefs, to share the briefs, to review them, to check with all the other teams. And that is both important. So it's a good skill to cultivate and figure out how to embrace, but also something to watch for, because if you're not paying too much attention to it, it's very easy to suddenly not be spending any time actually talking to your customers or outside the building. So that's one of the things, as you scale is making sure you still find those ways to spend time with the people who are not. As Bill Joy once famously said, the smartest people don't work here. Your customers are the people who are somewhere else and really focusing on them.

Two quick things I'd add, because I echo everything that these ladies just said, Especially if you're in a larger company. Don't lose that hunger, don't lose that hustle. The fact that there are processes don't take for granted, that's the only way you get things done. And I think that's a change that even large companies would really love to embrace is just that entrepreneurial spirit and that hunger to actually keep innovating and keep challenging yourself in spite of or even with a process. And I think that what's really interesting is as a company grows, how it changes. And the things that made you a really great PM when the company was 10 or 20 are very different when it's 20 or 40 or 100. And that happens very quickly. And so just because you're doing a job a certain way doesn't mean that in six months or a year, you would be doing your role the same way, even if you were in the same role you were actually in before. So I think just to always look for what your company needs and not to lose that edge for when it was five of you, you sat around a table and you could just crank something out. When it's 50 of you or 500 of you, how do you still have that fire? That's a really important part about helping larger companies stay competitive and stay innovative.

Do you guys have any tips for how to minimize the communication overhead and keep people aligned, and then also for how to maximize your sort of innovation and your constant, like, talking to the customers? What are some of the practical things people can do?

These things are so top of mind. Okay, so there's a. I'm just going to pepper you guys with a couple of different examples. So one is good org design. And as much as you may or may not be the people designing the org, but you can certainly have a voice in how does your team have the maximum autonomy to really own whatever it is? And ideally, owning a problem rather than owning a feature or a product or a specific thing, because when you do that, you can actually minimize some of the cost. Because it's like, this is our swim lane. We're doing this thing, we're going to go solve that. Someone else can solve something else. You get much clearer touch points if you can figure out. And you may have an org, but you can still define for yourself what's your charter and how do you communicate that. One of my favorite books in a form of management is called Turn the Ship Around. And it's this Navy captain, and he talks about the power of signaling, of just being able to say, hey, I'm going that way. We're taking the sub down and no one objects, and you just do it. So finding those ways where you can let people know, you can just go. So instead of being blocked on approval, agreement to buy in and everything else. Sometimes it's about, hey, we're going to tell you what we're going to do. No one hollers, we're going to do it. So I love that piece of just thinking about how you fit into the broader org. And sometimes it's also taking that small group that you have and running away somewhere. I think, like, off sites are totally underused in some ways, but not the offsite where you sit in a room and you whiteboard for a day, but the thing where you go and you talk to each other. We had a great example a few months ago. We brought all of our leadership team together, and in those couple of days, we were able to talk about some very hard things that otherwise, if we hadn't had everyone in the same room at the same time, we never would have gotten to a few big decisions and some big changes in some of our products, which was great. So figuring out how you bring the team together, are you in the Tahoe Manifesto off site? That was before your time, right? We worked together once upon a time and we took a whole bunch. We took 16 people to a house in Tahoe with a bunch of Zachary's pizzas. And the thing that came out of that was amazing. So that's just one of those small examples of how do you reduce the tax is you condense it all into a very short period of time. So there's two of them. And I'll let you two add a whole bunch more.

I'll add. I like those a lot. I would like to go to Tahoe.

With a few seconds.

What are you doing tomorrow? I have a couple of tactics to share. So first, on the question of how do you share the tax communication overhead, and I'm sure you did this a lot as a CEO, too. I think you have to figure out, as Warren Buffett says, what your core competency is. And that goes for communication, too. So, for example, when it comes to team coordination, you absolutely do not have to be the person who is setting up every meeting and taking all the notes and all that stuff that all of us product managers do from time to time, because we're so used to filling the white space and doing whatever the team needs to be successful. And that is a great attitude to have. But you also need to train your team to be really used to sharing that load. And I am always like, oh, engineer, tech, lead designer, what? Who can do this, who can do that? So try to outsource as much of that as is kind of reasonable and helpful. For your team. But you have to know that talking to customers is of course not really. You can share that load and you can bring people with you, especially if you're doing design research or UX research. But you, it's very hard to replace that as a primary communication understanding tool. So you have to be out in the field basically talking to your customers. Regardless of what level of product management you're at, you will always learn things. So the first is to know your competencies and to try to maybe spread around some of the communication tacts internally. But externally, think really carefully about how much user exposure you need for every particular product piece of the product. And the second one is to, depending on your company culture, rely on formal communication like written communication. Stripe happens to be a very sort of written communication heavy kind of culture. And it can be really helpful to just write down, you know, what is it that you're trying to solve. As Jeff Bezos said, there's no way to write a six page paper about a product that you would like to build and not have clear thinking. So you are forced in written format to say here's exactly the problem I'm trying to solve, why here's for who? And that can be really helpful. And it is very little cost to add more people, more names and email addresses to a doc that you share with them. Ask your collaborate, your stakeholders for feedback. It takes a lot more time to go and try to chase that feedback down in person and sometimes you have to do that. But it's more okay to rely, I think on written communication in some of those cases and or on your teammates to help you go and circulate and round up the votes that you need to help you with your initiatives.

Can I ask you a follow up? I have a follow up for you on the written comms because I've seen we struggle at this all the time because we like to write things too. This has happened at a bunch of companies and this idea that if you wrote it and you sent it, therefore people are bought in and your job is done. How do you defend against that in the like, well I sent it and then you sitting there with like 150 of these in your inbox that you're supposed to have read and may or may not have done that at midnight.

Yeah, that's the flip side of having a lot of email or transparent communication. You get a lot of emails or slacks or whatever it is. I think it depends on who your audience is for something like an important product change. That's probably something we would communicate to the CEO and founder beforehand and probably go to a product review to make sure we get all of their feedback. And probably the same for your kikski. Sometimes we just make checklists of these are stakeholder functions that we need and people and this is what they said. Everybody else is kind of nice to have.

I'll add a couple other tidbits. They're really just tactics. Don't underestimate the value of a daily standup. My peers and I, we actually lead a team about 350 in 16 countries. We do daily standup every single day. Some days are 15 minutes. Just like, here's the game plan, here's what changed, here's what changed overnight. Are we all set? We're going to announce this thing. Sometimes it's an hour because we're working through something much harder. But the value of even having at every level having that regular sync, make sure that if one person heard something from their manager, you actually have an opportunity to get all of that clothes tied up. I think that's a tactic that I think is just helpful. I think in addition to the written, I would encourage you, depending on your team, think about all the mediums available to you. So at our last company where Olivia and I worked together two companies ago, for her, our team was actually spread into multiple countries all over the world. And written was hard because they were just getting email after email after email after headquarters. So what we did was we started recording videos, three minute snippets once a week. Here's what's on the mind from the product organization and it was changes the sales team needed to know about or launches that were coming up or a customer fire and how we are dealing with it. And it was short and consumable. Salespeople on the road could actually just watch it from their phone while they were on their way to a customer. So you think about the medium that you actually can use to reach the audience and then that is the best way to communicate with them. And so it might take a little adjustment depending on who your stakeholders are and how they prefer to consume information, but absolutely over communicate whenever possible.

So I just want to say the video idea is so great, I'm stealing that.

It was called clarification.

That is amazing.

So most of you, I think all of you started your careers at larger companies and we've kind of talked through big company product management, talk about the transition to smaller stuff, startup life and what's different about being a PM there. And was there anything you had to specially Learn or unlearn. You know, I definitely found that your scope of responsibility grows tremendously, and there's just not enough people to do all the things that need to get done. So I found myself doing things that, oh, I didn't know product managers were supposed to do this, and, oh, this is kind of fun. And the role just kept growing. But I'd love to hear your. Your perspective on what. What it was like to make that shift to a smaller startup life.

So I can only tell part of the journey because I went from 400,000 people at IBM, where I'd spent 11 years, to 400 people at Jive. And at that time, I thought that was a crazy bet, going to a tiny, tiny company. Jive was public, to be clear. So, I mean, like, my index of what a startup was at that point is like, like, very different. So I can tell you from, like, 400,000 to 400. A lot of the things that were described earlier by Olivia and Gloria, I think really hold true. I went from learning how to be a PM when we had, you know, concept checkpoint, progress checkpoint, availability checkpoint. Like, every single one of those had a process and a template, and it was all kind of laid out for you. And I went to a place that had none of that. Like, we didn't. We kind of did, but with certain groups and not consistently. And so it was not so much I'm just here to execute a process, but I'm here to build the process. And you start having to take ownership. And there was one point where products started shipping features very, very, very quickly. And the support team was like, whoa, stop. We cannot keep up with all the changes you're making because we can't keep up with our customers. And you're like, well, we're innovating. Deal with it. That's totally the wrong attitude, because at the end of the day, you have to make your product successful. And if your team can't support it and they can't tell the right message to your customer, then you're really not. You're doing your company a disservice. And so I think when you go from super large to at least in the 400 size. But I would guess a lot of the problems we have are fairly common. What you're really looking for is what's causing the company to flex, and how do you actually apply just the right amount of process so that that amount of flex isn't there? And I think the approach that I found that's really helpful, it's not about the perfect Process, it's about setting expectations for people when there is a process, when their input is involved and when they will be informed, when they need to know. And getting that process dialed in is really the secret sauce. So even at Airbnb today, we have relatively little process, but the expectations are set. We do eight week plans and you get to put global teams give us input. Week six, week seven, week eight, all of the week eight of the previous cycle, all of all, the leadership team agrees on what our priorities are. And then week one, the teams are planning and executing. And so everyone knows every eight weeks, this is when I get to say my piece. And it's a different week for every person, but that's all it is. The details behind how every team executes is still completely autonomous. And so maybe that's how I think about that transition.

I'm just going to riff on the process piece because I love this idea of I don't know who to credit for this one. Just enough process and the idea that whatever size you are, it's like just enough where process isn't a dirty word. And also that at every doubling in size is a good moment to rethink what your process is. So I actually started in two different companies that had like six people. They were very small, and then couple hundred and then couple thousand and down. So back and forth. And it was actually when I got to yahoo at about 3,000 people at that point was the first time I learned formal things around product management. Like, I remember going to a pragmatic marketing class and being like, oh, oh, some of these things make so much sense. I'd been like, reinventing the wheel and first principling my way into how to actually do anything. But there it was even more like a startup. And it depends somewhat on your teams and your resources. And I had four products and $80 million and eventually two engineers. And so most of my job was saying no to people, which was really quite depressing. So you can have that at a startup, you can have that at a huge company. It's not like resources are magically there or time is totally different. So I think it's a lot about the job. You have, the size, what you're trying to get done and some of the things available to you. So taking advantage of the ease and lack of overhead in some ways, when you're super small and when you're really big, that there are people to learn from and people who've been there and done it and who can mentor more. So just finding the best of whichever size you're in and appreciating that. And hopefully, like me, if you ping pong back and forth between big and small because the grass is always greener on the other side, you can at least start to see those differences and take advantage of the best of each size because there are great things and hard things that will continue to change as you grow.

Such great answers. I don't know that I have much more to add. I think at a small startup you have a lot more opportunity to stretch, like you were saying, Jess, beyond much more, beyond traditional product management roles. And so the learning curve can be insane, insanely great at that in that way. Whereas at a larger company you're really learning how to scale. So at a company like Stripe, which is doubling every year, you're very quickly running from hundreds to thousands of people. And at that stage, you better love developing processes because you can design a great process and it was probably going to expire in about nine months, so you should probably love designing a new process for that new stage. And scaling is a whole area of learning. But when you're at a really small startup, you get to stretch in many different dimensions.

How many people here are managers of other product managers? Okay, how many people want to be managers of other product managers? So can you guys talk a little bit about that transition? I think there's a point where every PM and engineer actually decides, do I want to go the individual contributor path and be the PM architect type and just not have reports, or do I want to be a people manager? Can you talk through that decision and what it was like for you and when you knew and give guidance to this group on whether more of them should raise their hands or not.

Okay. I actually love that you didn't all raise your hands. Because when I think back about mistakes early in my career, one of them was probably just thinking that there was always something bigger, better, ambitious title, growth, something, something. So I love that there's clearly thoughtfulness in this group about what you are actually trying to do. So kudos on that. There's a book, what Got yout Here Won't get yout There. And it's the idea that the job is very different when you move into management than that job that you were so successful at. And most places don't actually teach you that there's a different skill set. I sucked my first couple of years in management. I'm like still apologizing. They're good friends but like still to these days I'm like, oh, oh, those things And I've loved that there are some amazingly thoughtful people and great resources out there today to learn how to be a manager if you're going to do it. But it's also, I think in product, not black and white, it's very rare that you are actually just a people manager or just a product person. So we've actually worked at Dropbox on eliminating some of this distinction of the IC track or the manager track, because I have people who are very senior and responsible for a product and have one or two junior people on their team who do report to them, but together they're trying to make this one thing successful. And it's almost like they're super ICs. And it's how they're getting scale. It's also how they're growing the team and the skill set in the team. And that's also a path. So for product especially, it's not the black and white. And you will always be doing some amount hopefully of mentoring, coaching, teaching, actually making the product better, whether you're managing or you're in one of those bigger influencer roles.

I also think there's in product management, in particular our profession, what you do every single day, the influence, understanding what people are coming, where they are coming from, how you best communicate with them, how you motivate people. There's actually a lot of the fundamentals of doing the day job well that translate really nicely into management and also broader cross functional leadership. So I would say also don't be scared of it. Definitely similar to Olivia. When I got my first management role, I was like, yes, now I'm a manager. And I had no idea what that meant. And in that time it was actually managing in the design side of the house. And I was like, wait, I'm not designing things anymore. Wait, what? I was so sad because I didn't get to create in the same way that I got to do all the time when I was in ic. And that took some learning. And the fact that you are now delivering amazing product experiences through other people. You have to think about your role as a manager, as a teacher, as someone who's going to coach and inspire your team to be the best product manager as possible, that was a hard transition for me. But I actually love the mentoring and coaching side almost as much as I love the product creation side. And so that's why the balance works for me. I will tell you though, even today I miss creating. And so I will always have one project that's kind of like my thing. I get to work on. And there's like a few people that kind of help me with it. And sometimes it grows into something big and I have to hand it off. And sometimes like, well, that was terrible, and we put it away. Sometimes I'm just covering when someone goes out on leave, I'm like, oh, I get to work on this for a couple weeks. You don't lose the love of doing the day job. I think, like Olivia said, there's a great balance. But just remember, the skills you're building every single day actually make you a strong manager as well. And so if that is something you might be interested in, I'd encourage you not to be afraid of it, but find mentors and coaches who can help you make that transition. Because it can be a little rocky because you used to be the person who got to just do everything all day and now you have to help others.

Clara's answer was better. You should keep that one.

Echoing. Both Olivia and Clara, I definitely agree. You can be a very successful product manager without having reports. So I wouldn't feel too constrained. If you're not sure if you want to go into people management, I think it's much more about scope of your product surface area and the impact that you have. And that can be really powerful as a product manager, individual contributor, and you can be very senior at all sorts of companies doing that. One of the unexpected things that I learned when I became a people manager of other product managers is just how much weight your words carry. And of course, this is already true for product managers, who are often at the nexus of teams that are building and selling and so much important activity for the company. But when you progress in the level in your career, this becomes more true than ever. Everything that you say or reflect on to the team, even an offline comment can come across in a way where you're like, oh, she said this, or she thinks this about our product. It's like, oh, well, that was. So you have to be really careful. But the good news is that you can practice that because you are all product leaders today, and you can practice that and practice just using your influence in really powerful ways and be really mindful of it. It's powerful.

Okay, so I want to make sure we have time for Q and A. So I'm just going to ask one more question and then you guys please come.

I know you're trying to cut us off, but I want to say one.

More thing on the beach.

Yeah.

Oh, yeah, yeah.

You just said something.

I'm like, no, no, no.

That's far something really important is that transition. I think if you are a great product person, one of the biggest temptations is you, you can do it better yourself. You can almost always, you're like this project, like, ah, I can just do that. Because you have the experience, you know a bunch about it. So when you're mindful of that, and that's part of that, being careful what you say and how you present it is it's very easy to take things over or do them yourself. And so being very intentional in what space you create, in what you communicate for other people to learn and grow into it, because it actually can take more time to let someone else do it. But that's also how you'll get the leverage longer term. So if you're looking for lessons as you're moving into that learned the hard way, hopefully we just saved you a few painful conversations.

I think I would actually add to that that the difference between being a junior PM and a senior PM and a manager is when you're starting out, your job is to define the solution to the problem. Then as you get further up, it's not about defining the solution, it's about defining the problem problem as crisply and as clearly as possible and getting other people, the people who report to you to really think about the solution. And that just gets further and further until at some point no one tells you what the problem is you're solving and you're a VP and they're just like, make the company better. And then you have to come up with a problem statement. So that to me is one of the big differences. So I want to make sure you guys have time to ask questions. So get your questions ready. But in the meantime, if you could go back in time to your younger junior PM self, what's like the biggest piece of advice you would go back and tell yourself, and then I'm gonna pass this mic around to whoever it is. If you have questions, raise your hand and we'll get the mic to you.

I'd say that mine is ask the dumb question. Like, you sit in these rooms, especially as a pm, you get to be part of strategy sessions or decision making sessions. And you're sitting there and this discussion's happening and you're like, what the hell? This doesn't make sense. Ask the dumb question. If you have the opportunity, you see something that doesn't make sense, have the confidence in yourself. Don't just assume, okay, I don't know what I'm talking about. I'm not going to Ask. There's the right channel to ask. Sometimes it's in the room, sometimes it's a follow up. But ask the question because it's possible that it hadn't been thought about before. And I think I would have saved myself many years in my career being frustrated if I had just taken, taken the initiative and ask the question sooner.

Be really, really clear on what you're solving for, what you're trying to accomplish, what you're solving for. If it's a product, what problem are you solving? I think Dropbox has actually done that better than anywhere I've ever worked and it's probably one of the most valuable things I will take away is this idea of don't even talk about solutions or anything else. What problem? Why, why now? Why is that important? And that's true in a meeting, in a conversation. What are the goals? What are you trying to do in this? And if you can get really clear on that, you will save yourself so much pain down the road when it turns out there was all of this false alignment or misalignment or stuff that you hadn't really quite gotten to because it leads you to ask the questions up front and be very explicit about what it is you're trying to do. So that's probably one of my good ones.

One area that I'm always working on, still am working on is improving my communication skills. I think you just cannot be too good at communicating, especially in a role like product management.

You.

And so I think that's something to think about. What are the areas that you really want to develop? And do not be afraid to invest in yourself and your skills. Early on. I remember early on I was a very young head of product and I just went to my CEO and I was like, I am not great enough. I'm not good enough at doing this thing. I'm not good enough at presenting in our board meetings. And I was like, I want to hire a communications coach to help me. And I was like great, go do it. And I was just like ok, cool. So I think that you should look for opportunities on how to develop some of these very tangible skill sets and, and just practice, practice, practice.

All right, so why don't we go to questions.

Ok. Hi.

Thanks for all your advice and stories so far. My name is Amy and I want to know what does the ideal product Org look like to you and how has that idea of the ideal product Org changed over the course of your careers?

Stumper.

I don't even know where to start with that one.

I actually have an answer. So I think in the very early days, it is actually easier to organize your product and engineering team by back end, front end, because there's so few people that you can all sit in one room and you can communicate and it's just easy to assign like front end, back end. But as you grow, you have to kind of switch away from. You often have to switch, switch away from that and organize your product team and your engineering teams around the business goals. Right. So you might be a retention team and an acquisition team and a monetization team is one way to do it. But people, when teams are cohesive and they have a clear mission and purpose, they just tend to do better when they know that they have one thing they need to do and one metric. And it's better if that thing is tied to the company goals. So I found that once you get larger, you need to start to shift to that. And it could be maybe at Facebook. I think a lot of it's related to the key features in a marketplace. It might be supply and demand, but to me, that's always been one of the better organizational principles. And then you want, I think a lot of times, PMs and engineers to gel and be working with the same people. I think it's really hard to have teams where there's 1pm that works across many, many different teams and doesn't have their team, because people just bond better and get to know each other better and become more productive.

Thank you for that seed. I'm going to add a couple more. So one is there's the ideal organization and then there's the ideal meets reality. So it's also thinking about the people you have and the strengths. So I love when you have particularly engineering, product and design sort of triads, if you're in that model who are close, who work together over time, and who complement each other really well. And sometimes you do kind of funny things to make that work. The other one is thinking about the pace and culture of a team. So when you think about a growth team that might be experimenting and shipping things several times a week, that's a very different culture and pace and style than a team that's working on a foundational effort that's going to take a year. And so one of the things I like to do is think about how that team operates and have people together who are going to be in that same kind of style and mindset. We recently moved a team from one org to another and it was like night and day difference of how Successful they were how happy they were because they were in a place that didn't match with the style of what they were trying to do. So they were always pushing against that part of the organization. And we moved them to a place that fit really, really well and it had a great impact. So thinking about the culture, pace, style, values, operational cadence can be a good one too. And having different ones across the organization.

When it comes to org design change is the only constant. Every six months you might find yourself in a situation where you're reorgang and the eternal functional horizontal, it'll probably go on forever. But I think what's really important to achieve at any given point in time is kind of you have this pyramid, right? So you need clarity of purpose and like here's our mission and then after that you need to be able to find okay, well based on our mission and purpose, here are the metrics that we really care about. Here's what will happen, here's what success looks like for our team in qualitative quantitative metrics. And then after that you need clarity and responsibility. Like what does our team do? What are the interfaces between our team and another team and how do we work with them? So there's probably an answer at any given point in time and that will probably not stay the same.

Amen.

I actually don't think there's ever an ideal org design, even the moment that you do it. I just don't think every org design has trade offs. And so it's really about what you're optimizing for in that moment. And you're willing to get more from A and less of B because of the design that you've put into place. I think there are a couple principles about nuclear teams if you think about it, that I try to stick by PMs, designers, data scientists, heads of operations, whenever possible co located. There's nothing quite the same as being able to look at each other in the face somewhat regularly. PMs who have to fly to meet their teams, that's a really hard place to be long term, especially if you want to be shipping with velocity. So I think about colocation, I think about strengths and weaknesses of the leaders you're putting across every function and creating a little bit of balance. And yeah, I think that actually I love what Jess said about the focus on a mission or the business metric and how you're actually you and you and your team can actually influence that over time. So that you're not married to a project, you're married to a set of ways in which you might solve for that goal. And I think that encourages a team to have a little bit more creativity.

Hi first, thank you for your insights and your great advice. My name is Jennifer. I recently moved from a 20 people product team to being the only PM in a small startup. And what scares me is before when we have a product line and being the product manager on one product line, we have a lot of covers. So even when some features there are mistakes or things not being perfect, we still have a lot of covers. Being in a startup, what I've been constantly thinking about is it's not about feature wise, we make mistakes, it's direction wise. If we step into a wrong or a not so ideal area that we're losing the computations or things that we can do wrong. And how first, how can I identify it as quick as possible and do you have any examples or advice for that? And also how can I change course right away? Thank you.

I guess I would One framework I use in my helpful to you. I think about one way doors and two way doors. A two way door is a decision that you can make, it might be wrong and you can reverse it and it's not a huge deal. We launched this new feature, we move this button here, it's now blue or green. These are two way doors. You can launch the feature, you can see whether you're getting the results and if you don't like what you have going back is kind of not the end of the world, then there's one way doors. These are really, really hard things to take back. Once you've said something right, you've launched a new brand and you've completely rebranded your whole company. But it's like really offensive in some language somewhere in the world. Like these things happen, right? Those things are hard and you want to be a little extra careful and maybe get some extra feedback or slow down just a little bit to make sure you're getting whether it's user feedback, you know, just asking a friend even for some advice, checking with your upline management, I think about one way doors and two way doors. And with two way doors as much as possible, I want my teams to be fast and to run as hard as they can. And it's okay if we break a few things because we'll fix it one way doors. You're a lot more thoughtful about that. I think that when you think about early indicators it's going to be a little bit different for every part of the business. And I'll give you a couple of examples. So at Airbnb, we have metrics. Everything's an experiment, you launch it and there's basically numbers that say, is it doing what it's supposed to be doing? But we also have hosts who actually tell us more subjectively from a qualitative perspective, what did it make them feel like? And although the number might initially be positive over the time period of six months, a year or a couple years, it might actually erode trust or perception. So how do you actually make sure you're looking at both the immediate feedback of the numbers, but also the feedback of your users? And maybe the contrasting example is like at Jive, we were a large enterprise, we were enterprise company that served large customers, and our large customers had a really strong voice. And when we'd launch new things, sometimes they would love it and sometimes they wouldn't like it. But just because they liked it doesn't mean it was going to be the right thing for the industry where the world was moving, because they had a very different worldview. So you always have to trust your take a look at your sources and decide how much you want to trust the actual feedback they're giving you versus what feels right and what the numbers are telling you. And it's a triangulation of your gut of the qualitative feedback and the quantitative.

Okay, I'm going to add one as a tactic. So I think all of these things, yes, plus one, figuring out what success or failure looks like. But if there's something you're doing that is a bigger risk and the sort of two way doors are the irreversible choices. One of the things that's worked really well for a bunch of teams I've got been in is to do these things called pre mortems. And a pre mortem is like a postmortem, but the patient's not dead yet. And it's like, so it's actually great because there's no blame, there's no sense of like, who did that thing, who killed them? It's like before you do it. So when you make the decision, we're going to go ahead and we're going to try this thing and this thing is going to be big and you can do it on any size thing. It's like brainstorming what are all the ways. If we were sitting here a month from now, six months from now, a year from now, whatever the timeframe, saying that went terribly wrong. Why? And you can do this in five minutes with post its, you can do it with a group just Sit there and figure out what are all the things that might have gone wrong? Because then up front you can actually figure out, well, which of those can we change, which can we guard against or which ones should we just be on the lookout for and how might we front load some of those risks to figure out really early or before we've actually gone down the point of no return if that thing is going to be fatal. And you can often find a bunch of ways if you get yourself in that mindset of like what's going to kill it or what will make it wildly successful and you can set up for that. Hi, my name is Tiffany and thank you again for all of your insights. My question is, have any of you thought about how you would, whether you would do your own startup and if so, what would inspire you to make that leap? Because you seem to be incredible product leaders making an impact at your respective organizations. And so what is the perfect set of conditions? Not necessarily perfect. That board doesn't really exist. But you know what I mean in terms of when to make that leap, A problem you can't let go of or a vision of a thing that needs to exist in the world that could be a culture, a team, a thing that you just can't let go of because it is hard. We've all been close to it. I've been in my house close to it for a long time and also investing in startups and it is just hard. So it's got to be something you care enough about to weather those things that you are so convicted that it's a thing you just have to do. I think that's at that point and I've come close. I toyed with one for a couple of months at one point before I actually found jive and fell in love with that. So when you find that thing, that's a good time, at least for me.

Exactly my answer. I think that's spot on. That's the right reason to do it for some people. It can also be a cultural thing. So depending on exactly the organization and the kind of cultural fit, bizarrely, it can actually be more. I've had friends who've started companies, some of them are women and they really enjoy the empowerment that comes from being the person who sets the culture. The culture starts with the CEO and that is just a different experience. It comes with a lot more hardships and challenges too. But being able to be the one. The buck stops with you. And you say this is the culture and the people organization that I want to grow that can be very powerful.

Plus one to both of them. But maybe a slightly different version of the story too. I've actually seen somewhat risk averse by nature. I'm the daughter of first generation Chinese immigrants. When I left IBM after 11 years and a great career there, it was like the saddest day of my dad's life. He's like, why you have job stability? I was like, no, no, I'm going to go to this company called Jive. He's like, so risky, right? Remember, 400 person publicly traded company. At one point in my life, that was the craziest bet I had ever taken. And I tell that because I think that sometimes you can forget how hard of a leap that can be. And it's much easier for me to sit here in this chair and be like, yeah, I think about it a lot and there's an idea that's percolating and at some point that might pop, but until it hits the phase where I can't stop thinking about it, it's going to stay there. But this is after many, many years of experience of getting to work with people, getting to learn what my strengths and weaknesses are. But like 21 year old me would never have considered it because that just wasn't the way that I grew up and the value system that I learned as a child. And so I think some of it is also, be patient with yourself. If it's something that's there and you're excited about it and you can't stop thinking about it, believe in yourself. But if you're not quite there yet, that's okay too. There will be a point when that is the right thing and you surround yourself with a great, you know, ecosystem. Whether it's investors that you're going to go partner with, whether it's your co founders that have actually had different experiences, or whether you know what you're like, I'm just gonna go for this. But I think all of us have slightly different journeys. And I would just say that for me it took many years to even think that that would be something reasonable to do. Ration. It's not rational really, but like to think that it would be a responsible choice, that I could just love doing something. It took a lot of time to get there, so maybe I'd share that too.

Yeah.

So my mom was an entrepreneur. She didn't run like a fancy tech company or anything. She just ran an interpretation and translation service out of our apartment in Hong Kong when I was growing up. And she would always tell me when I was growing up, she's like, oh, it's great to be your own boss, right? And she just ran a very small company where she got autonomy. So people start companies for different reasons. They don't have to be massive like Airbnb, Dropbox scale companies, but they can be smaller things. They can. Sometimes they start as lifestyle businesses and grow into something larger. But I would say if you have this problem that you can't stop thinking about or you want to try and you have a little bit of the means to be in, you know, to not get paid for a while and do it, I would say, like, think about when you're 80 years old and you think, oh, should I have done that? Should I have just tried it? I would urge you to err on the side of the going for it, right? Because the other thing is if you're good, you can always go back, right, to what you were doing before. It isn't necessarily a two, you know, the one way door, unless you raise like $100 million in revenue, then you're like kind of committed, but. Or I mean any amount of money really, from friends, for family, from, from seed investors. So just think about that, like, will you regret it? And then I remember when I left Google to go to Polyvore, I had a conversation with the VP of product and I was very scared and I was like, oh, I'm sorry, I'm going to the startup, what should I do? And he was like, you can always come back. And I was like, oh my God, yeah, Google is always hiring lots and lots of people. They probably would take me back. And that really just freed me to be like, you know what, maybe I should try the startup thing. So anyway, my bias would be to go for it.

But yeah, can I add to that? So I'm going to counter myself and plus one that and say there's. So a bunch of companies actually have a thing called Boomerang program where if you leave, they actually will try and get you to come back. So sometimes we're like, oh well, if their startup doesn't go well, maybe they'll be back in six months. It sometimes works. But there's also, and this is where the difference of maybe where we sit in our lives and where some of you are is sometimes it's just fun and you will learn a ton and maybe don't go raise VC money on that. And there are a lot of really great non VC funded businesses that you could choose to build in the world. And like my Little Brother is 24 and starting two companies. And it's partly because he knows the people he wants to work with and the lifestyle that he wants to have and a thing that's going to be fun and how much he's going to learn and that's enough. So it's different for each of you, but figure out what it is you want to learn about yourself, what you want to do, what you want to not regret.

Hi, my name is Divya. So I work at High Fidelity, which is a VR company. So the infrastructure for VR is pretty complex. I product manage two engineering teams which are engine and server. So they're both like infrastructure teams. So anytime we launch a feature, it's not entirely user facing. It doesn't get celebrated the same way until the front end team builds out the content that uses all this infrastructure and then I feel like all the celebration happens there. I try to do my own tips and try to do things to motivate my team, but I was wondering if you guys have faced a similar problem and how do you try to get that celebration going even if you're an infrastructure team? Infrastructure teams, very close to my heart. 11 years at IBM, lots of middleware. Even my first year at Airbnb, I actually worked all on platform and infrastructure. So production infrastructure, data, developer tools, et cetera. I think that a huge part of it is creating celebration for your team, as you mentioned, but not underestimating the value of what that is. Because at the end of the day it's nice if like a CEO says like yay, good job team. But it means a lot when the people the team actually really looks up to celebrates them. So it might be you, it might be your manager, it might be their second line engineering manager. Creating a culture of recognition within a team, regardless of front end or back end, I think is really important. I think second, and this is a really powerful opportunity that PMs have is making sure the value of infrastructure is actually well understood, right? Service oriented architecture projects. Why should we invest in soa? Okay, it just sounds like a term, right? But explaining to people, actually by modularizing our software, we can deliver with more velocity. We are going to have higher quality, we're going to deliver faster, our customers are going to get more. It's going to be easier for every team not to step on each other. You have to tell the value of what it is you're doing in addition to actually just delivering the product. I would say third, maybe in some cases tie your launches with the external facing launches and actually make sure that when you celebrate the user facing launch. Part of that celebration is the enabling infrastructure that made it possible. So one of the things we try always to do if we're launching a new feature, it's not just what the host sees or the user sees. And thank you to the infrastructure team who built the video service so we can now do this. And thank you to the superset team who built all the dashboards which we can now power. Host facing data and information, you have to make sure that you are giving the sound bites to the team that is doing all the recognition and celebration to advocate for your team to make sure that their value is recognized. So I'd say it's a little bit of all those things.

I work at an infrastructure company, so a couple of tips here. First is around metrics. So a lot of I spent a lot of time on fraud risk, which is kind of the dark side of payments. And it's very metrics driven. It's a system, it's very metrics driven. And so you might be working. People working in that system are maybe not necessarily getting the glory of a new product launch in these areas most of the time, but you can definitely tell when there's been more or less fraud or we've been better at our machine learning systems have been better at detecting and actioning that fraud. So metrics can be very helpful. I know Claire has spent a lot of time on this at Airbnb too, so sort of sisters on that. Second thing is getting really crisp around your company goals can also be very effective. So you know when you're at a very fast growing company like Stripe Air maybe or Dropbox, scale is top of mind for execs. And there's simply no way that you can scale to 100x the host or 1000x the amount of files that you're storing or any of these other things, or 10,000x the amount of payments that you're processing in your system without thinking about scale. And in order to do that you obviously have to have an infrastructure and so it really benefits. It's helpful if you have a management team that's very oriented around the long term and it becomes very apparent in these kinds of situations that you really need to build for scale. And infrastructure is always a key investment when that's the case. Hello everyone.

Hi, my name is Oluse.

I'm currently working on Project Wooomli, which.

Is to enable a more inclusive work environment for women. So my question is how have you approached as project managers, I've. You're guided By a problem, you're not too sure what the solution is. You have some ideas, but the problem is really fascinating to you. It's something you need to solve. How do you approach really breaking down that problem? Getting feedback from users, I think would.

Be really helpful for me.

So I'll give an example of. Actually, one of the things my team is working on right now. One of my teams is looking at diversity as pertains to our host and guest community. When you look at acceptance rate of guests who are requesting to book and whether hosts are accepting them, and how you think about using technology to drive changes in implicit bias in human behavior, it's a really fascinating problem. There's no template to copy. There's no book. Right. And so the way that we at least got started was to say, let's surround ourselves from experts who have thought about this in various ways. Whether it's diversity in tech, in removing bias in the interviewing process, whether it's in fair housing laws, and how you think about inclusion and lack of bias in loans or mortgages. All the way to just a team brainstorm, because you have within your team a gut set of ideas that are worth trying. And then you start experimenting. We worked with academics, people who had done research in this their whole lives. You find different pockets where, where you might find the spark of an inspiration. And I would say include your team. Being a PM is not about you having the best idea and you deciding, here's where we're going. Being a PM means unlocking the best of your team. And so some of my favorite things are whiteboarding sessions with all of the functions. The engineers, the designers like, hey, what do you guys think? And you start putting some ideas on the board, and then you can start clustering them and saying, okay, there's a set of things here around this. There's a set of other things here. So let's remove profile photos. That's one blunt instrument. Let's do this other thing and think about the message with which guests send to hosts. How is that perceived? And you start to break the problem down into at least component areas. And then for each area, you start to think about, what are all the levers I can then use to drive this change. So removing a profile photo isn't about just removing a photo. Maybe we remove the photo until the host accepts, and then you can see the person who's coming. Maybe you actually make it harder. You make it one click away to look at the profile photo and you see how many people look at it, and you start to break down the problem and you can understand with all those different levers did it make a difference? And if it didn't, then you move on to the next one. And if it did, you can continue to go further. Maybe if it didn't, you iterate and you try again. Right. But by basically brainstorming, having a set of problems, that's a way to create a roadmap in an ambiguous world and then you start working down your levers to see what happens. But I think the co creation process and taking inspiration from somewhat adjacent, even if not perfectly relevant fields has been helpful for us.

I love that. And I'll say there's a tool actually some of our design teams use this really well of divergence and convergence. And so when you're looking at a problem, this divergence of think of every possible idea, get all of those things out on the board and then how you start to come back together and you might actually go through multiple cycles of that. Okay, we honed in on this one thing that's super interesting. Now if we explode that out and think about every possible way we might approach that, validate that, do something else and then you start to converge back in. The one tip I'll add is it's really helpful in that to be clear with people on where you are. One of the most frustrating things is when you have someone in the room who's trying to converge everything when you're actually in the ideation setting stage or vice versa of like no, no, no, we're converging and that's like what about if we did this thing over here?

And it's like no, no, no, no.

We'Re not there right now. So as you do those or you're looking at a problem just being clear on where you are and creating the space with the team to do both of those things can help you get to sometimes a better set of solutions or things to validate. I think we have time, are we lightning rounding now?

I think we have time for one more question and then after this we're going to go next door where there's food. We are going to feed you and you have plenty of time to talk to anyone up here. And the other thing is I think it's really important as part of this community to meet each other, exchange emails with another person here, meet folks outside of your org so that you can, you know, I think community building amongst women I think is incredibly important for career success, for everything. So just make sure you talk to some other folks here as well, so we will go and do that. Last question. Who has the mic?

Me.

Hi.

Oh, all right, all right, thanks. Thanks so much for everyone's insights.

My name is Patricia. I'm over at Doordash.

You guys talked a little bit about.

How PMs usually don't have any direct reports. And I was wondering what you guys have in terms of non conventional advice on how to lead with influence.

Regardless.

Of having that power, especially when you're earlier on in your career and you don't necessarily have whole, whole lot of product credibility, how have you gained the respect of the designers and the engineers.

That you work with? Okay, I'm going to give you the.

Two word answer, empathy and knowledge. I guess I have to unpack that. The knowledge is actually know things about your customer that no one else in the room knows. And you'll get credibility really quickly, no matter how young or early in your career you are. And then that curiosity, empathy, listening to people, they will be much more willing to then listen and respect in return.

Yeah, I think the empathy point, Olivia is saying the framework, we actually, my former boss at Airbnb said It's like a 4951 tiebreaker. The power of a PM in the roadmap. Yeah, technically you get to say, here's what we're going to go do in the roadmap, but your vote is like the 51% versus the 49% of, you know, your other partners at the table. And if you're constantly playing the card like it's my card to play, you're probably not going to be a very good PM and you're not going to be on that team for very long because there will be some organ rejection. So when you think about the fact that you actually have this influence, how do you actually bring people in to feel like they're part of that decision and that you're really guiding the discussion and the decision toward the end goal that you believe might be the right answer for the team, but it's not necessarily your idea. And I think how you wield that responsibility is a huge part to how the team feels like they can work with you. And I think that's a little bit of the empathy thing. I think the other side, I would say, is there is no replacement for rolling up your sleeves, doing the work and knowing whether it's your customer, your metrics, the ship dates, your success, the dependencies on other teams when you are there side by side with your team, delivering great products and you're able to remove the barriers and have the right information. To Olivia's point about knowledge, that's part of where that trust gets forged.

My two words here would be direction and alignment, and they're actually not that different from the answers that you all shared. Direction is. It's kind of counterintuitive that as a relatively new product manager, you can provide direction. And it also can be intimidating. When engineers, and we know engineers, there's lots of different engineer personalities out there, right? Some of them are the grumpy CTO and the developer who only wants to work on this part of the system that they really want to fix. There's all these difficult personalities. But at the end of the day, even if it doesn't seem like it, engineers really want direction. They crave direction, and they really want to be pointed in kind of the truthiest direction of what is the right thing to build. And there's nothing they value more than a product manager who really knows that. And you bring that to the table, even if you're relatively early in your career by talking to the customer, by deeply researching that very small, Even if it's a really tiny, small surface area, but very specific product area that you're working on, a market that you're trying to target, bring the data and build your case, you can do that even on your first day in the job. And then alignment is the second piece. So in addition to the direction which people find so helpful, just bringing together your team and making sure everyone's pointing the same way can be so valuable. And I don't think I need to say more about that, but it's just you never can do too much of it. And at any level, you really can't do too much of that either. You kind of just start aligning larger teams or different groups beyond just product management or smaller teams and numbers.

I will add two words as well. The first is earn your stripes. Like, pick the annoying thing that no one else on the team wants to do and do it. Prove your value. Show that you're willing to roll up your sleeves, like in the beginning, because I happen to have a. I have a CS background. So when I joined my very first team, where I'd never been a PM before and never had a job before, a real job, I just fixed bugs. And then they were like, oh, you can write code. And you helped us fix that. Oh, you're kind of useful. Maybe I will listen to you.

So then you just.

I started there, right? So whatever it is, just prove your value. The other thing, this is the approach I took when I was a little bit when I was younger was kind of make it fun, right? Work is, work can be a drag sometimes, right? If you can be the one if you have that kind of personality like where you can be the fun one. I was a little bit of almost like a mascot maybe but like, you know, make it fun for your team. Your team really appreciates that. Right? So those are two small tips for especially when you're younger and you're starting out. But yeah, okay. Thank you guys so much. This was an incredible wealth of knowledge from this amazing panel of women who are incredible product leaders at fantastic companies. So thank you guys. All right, so now we're going to go next door and grab a bite to eat. Please circulate, please meet each other, please form your circles and your little communities to help each other going forward. Thanks.