YC Women in Tech: Breaking Into Product

All right, hi everyone! It's uh thanks for joining us today. I'm Captain Yala. I'm excited to have you join us for our work at a startup panel on getting into product. We have three PMs with us today and will be joined also by YC alumni Helena Merk, and we'll have some time at the end of the panel for questions.

Um, but if you have questions throughout, I'll be monitoring the chat, so feel free to leave them in the chat as well. After the panel, around 5 PM, each panelist will be in separate session rooms where you can meet them, you know, and ask them more questions.

Um, but let's just jump straight into it. I'd love to have the speakers join me, and we can have them all introduce themselves.

That sounds good. Thanks, Kat! So hey everyone! I'm Sylvia. I'm currently a PM at Brex, leading our identity team, which owns everything onboarding, both from a user experience standpoint as well as all of the decision-making that happens behind the scenes. So as you can imagine, it's probably a pretty complex space.

Um, I've been at Brex about eight months now, so relatively recent. Um, prior to this, I was at Facebook for quite a stand. So most recently, I spent a year and a half out in Facebook London, where I was leading growth on the Audience Network team. And then before that, I was more on the consumer side of things working on growth across Instagram, across Messenger engagement growth, and to some extent across news feed as well.

So more on the consumer side of things. Before Facebook, I actually spent a few years at Workday as a product manager, more on the technical side, so working on platforms and frameworks in the enterprise space. And then before that, I was at school, so I started out more from an engineering background, studied engineering in university, and then actually moved straight to project management right out of college.

All right, all right, Colleen, you want to go next?

Happy to! Um, let me know if you can't hear me; I'm not getting a ton of feedback from Hopin. But I will assume it's working. Uh, I'm Colley Barkoski. I am a PM at Burbix, which is a Y Combinator company. Um, we are also doing identity verification. So Sylvia, you and I should talk sometime.

Um, and I've also been there for about eight months, so that's my current home. I'm the first PM there, so that's its own whole bag of tricks. Uh, prior to Burbix, I was at another Y Combinator company called Ironclad, which does contract lifecycle management. Um, and I was there for about two years in a role called legal engineering, where I also got to do a lot of product work and was very early there as well.

So I can talk about that ride. And before that, I did a— I didn't study CS actually in undergrad; I studied philosophy. But I did a Ruby on Rails boot camp, and that was kind of my technical training. Uh, prior to that, I was a journalist in DC where I covered the Supreme Court. Wow, very timely!

Um, Helena, you want to go next?

Yeah, I'd love to! I love both your backgrounds, just kind of a cool story how you got to PM. I'm excited to hear more about it through this panel. Um, so I got into more of the technical things actually from loving products a lot. So I taught myself to code back in middle school, mostly because I loved app design and building things.

Um, and then got more and more involved in tech and like moving down the stack. Um, and eventually dropped out of college to work at an API company, um, and that lasted only a few months until I left to start my own company, largely driven by, you know, Y Combinator accepting Glimpse into the match, uh, and that we just completed actually in March.

We were in the winter 20 batch, um, and our platform Glimpse matches people for one-on-one speed conversations with an advanced matching system that'll pair you with people that are relevant. So that's kind of how I got to here. Um, and I think, unlike both of you, I am, yes, product, um, but also product and engineering and a CEO and all the things.

So very, very excited to learn from both of you in how to get more into product because I'm new to this. Um, and I'm excited to be here. Thank you!

All right, and I think we're having some technical difficulties with Wild, but we'll have her introduce herself as soon as her video pops on.

Um, but yeah, let's— I'd love to talk a little bit more about your experience. Um, you know, what is the product manager's role in an organization, and what are your key responsibilities at your current company? And um, and then we can talk a little bit about how that has changed, depending on, you know where you're working or, um, or what type of company you're focused on.

But right now, um, Sylvia, can you talk a little bit about, you know, what is the PM's role in your organization?

Yeah, so to your point, this has varied a little bit depending on the companies and teams that I've worked at. But right now, the way that Brex defines product and what the product manager's role is is essentially there's kind of three parts to this triangle of building product.

So we have PMs who own the why of why are we building a product, why are we doing something, what is the strategy in the vision, and then we work very closely with design who owns the what— What is the right product experience to actually then solve for the solution or solve for the problem that we're going after?

And engineering owns the how of how do we actually build out the solution? And so that's typically how we work together as this triangle to be able to launch product and build the right solutions for any problems that we're going after.

Um, high level, what this translates to is that on the PM side, we essentially own defining the vision and the strategy. We need to be able to work with anyone within the team—so design, edge, but also any cross-functional partners—to figure out how we can collaborate across all of these roles and be able to define and build out the right product experiences.

And at the end of the day, we also just own generally the success of whether or not we can actually solve these problems properly. And so anything else that comes up, we kind of take on and figure out if we can solve for this problem or blocker, or if we need to work with someone else to be able to do that.

And uh, you went from, you know, Facebook as a PM to Brex, right?

Yep, and so how has that changed between working at like a very large company like Facebook to an earlier-stage company like Brex?

Yeah, so I would say the biggest thing is around scope, and what I mean by that is typically at a larger company—and I will caveat this with also I was in more junior positions earlier on in my career—so typically they are a little bit more execution-focused.

But what I have seen is the main difference between larger companies like Facebook and Workday versus what I'm experiencing here at Brex is around the scope. And so a lot of times, at Facebook, on the teams that I've worked on, the strategy at a high level has already been pretty well defined. There are already existing products; there's kind of a playbook, for lack of a better word, around how we're going to execute on these strategies or what even is the best strategy.

So as an example, Facebook, part of the competitive advantage there is scale, and so you can kind of just use that to hammer things through, even if at a smaller company you can't quite do the same thing. And so a lot of this has already been predefined; there's a lot of structure. And so it's more about how do you execute well within that structure.

Whereas now that we're at Brex, where we are trying to solve some very complex problems, we don't have a single defined way of doing things. You have to figure it out.

And so you're not just thinking about, okay, here's an existing product, and how do I optimize it, or how do I kind of execute along a predetermined strategy; you are part of the process to figure out what is the right strategy? And it's not just necessarily the product strategy; it's the company strategy, the business strategy. And so you have to think about not just what are the right product solutions, but really what is the right solution, period.

And then whether that involves your go-to-market team, whether that involves other product teams, whoever it is, you figure out what that solution is, even if it's not specifically a product solution.

Cool! I think this is a good time to ask Khali about—so you're the first PM at Burbix, right? Can you talk about what the role of a PM, you know, at Burbix is, um, and you know, how that perhaps is different from, you know, working with other PMs in a team?

Sure. Um, well, the biggest difference is probably just that you're—in that size of a company, we were a seed-stage company when I joined, for now series A. Um, everybody is wearing a lot of hats.

So I think the biggest difference is that you're not just kind of the opposite of what Sylvia was just saying about having a really limited scope as a junior PM at a big company.

Um, like one person contains multitudes, as what Whitman would say: you contains multitudes of functions within yourself.

Um, so as a—you know, I'm helping with support; I'm helping with integrations. Um, there's just a much broader swath, I would say. And then those things have like great synergies in a lot of ways because you're getting a lot of direct feedback about what you as a company should be focusing on.

Um, in terms of your—you don't even have to go to somebody else's desk to get input from the market; you know, like you have that because you're there. Um, so that I'd say that's like one big difference is just that you have—for everything's just in one big soup.

Um, and then in terms of like the role of product and how that might be different—um, I think this is probably consistent, but it's at the early stages too—like you, as Sylvia was saying as well, like the things that the way that you do things, the playbook, even kind of your thesis as a business isn't well defined.

So I think a lot of the work—and this is a metaphor that I find helpful just because of my background in journalism—but I think if product really is like the editor in a lot of ways of like how do we create focus?

Um, what should we cut? What should we double down on? And, uh, that's at least my working model for how I aspire to do product.

I should say, I think that's a great analogy. Um, Helena, as a founder, how do you think about it?

Oh good! Um, so I'll let you finish with that and then we'll, uh, I'll introduce myself. How do you think about practice?

Um, as an early-stage founder? Yeah, so what you, uh, Coli and Sylvia were both saying towards like comparing large companies to small ones.

We're at the very extreme of small right now; it's myself and my co-founder full-time. Uh, so product and defining, you know, what our company is doing and strategy is all on both of our minds all the time.

There is definitely no playbook, and it's definitely not ironed out, uh, so very much in that iterative MVP stage, which is so much fun. Um, and part of, you know, why I love the early stages of a startup.

Um, so much of it is just speaking with our glimpses with our users, um, and getting feedback from them, implementing that, and figuring out how do you take quality feedback and turn that into, you know, a consumer social platform, where feedback you get isn't as direct as, say, in a B2B company where, you know, these are the criteria you need?

No, it's like, you know, I want the button to jiggle this way. It's like, is that really what you want? I don't know.

Um, so it's definitely interesting, definitely a learning curve. Um, but I guess the way we think about products because of us being so early-stage is definitely very different.

Um, and it's less about like editing and fine-tuning; it's more just like going full forge on one thing and then trying the next thing until something sticks and then tweaking at that, um, and doing everything from that initial design to, you know, scoping it out, uh, and then actually implementing it as engineers.

Viola, I'd love for you to introduce yourself, um, tell us a little bit about your story, how you became a PM, um, and you know, your role as a PM, you know, currently at, uh, Airbnb, correct?

Yeah, cool! Sorry about all the technical difficulties. I started tech. Um, so my name is Vile Chain; I'm currently a product manager at Airbnb, uh, focused on data products.

Um, so I started my career as a software engineer and then went to managing engineering teams, but I moved into the data space um, pretty early on after that.

Um, before I'll call like data was sexy. Um, my first role in the data space was as a data engineer, so I was building pipelines. I then moved into being a data scientist, so analyzing all the data that I was creating and then finally ended up as a product manager, um, which, you know, kind of straddles the role across all of those, um, areas.

So yeah, that's, um, that's what I do right now. Um, yeah, I will let you know; you continue moderating. Sorry, this is like very interrupted!

No, no worries. And, and can you talk a little bit about your role at Airbnb now and how that sort of your role as a PM has sort of changed based on, you know, the company, various companies we work at?

Yeah, definitely! So I was also on Facebook, um, you know, a while ago, so I was there for about six years, back when, um, Facebook was not public yet. Um, and then I was at Lyft probably around like three years ago, um, and then now I’m at Airbnb.

So, um, you know, it's really interesting working at a larger company. Um, you take a lot for granted. Um, you know, there's a lot of process, a lot of tools already set. So, you know, as a product manager when you have an idea, you have a vision, um, it's very easy to actually get something out to market because everything is already there; the—you know, there's grease on the wheels to like, you know, pave the path there.

Um, and what I found when I moved over to Lyft was that there was none of that, and you know, we were reinventing everything, like how to test, you know, like, and we had no like QA testers.

Um, and so, you know, definitely flying by the city of your pants, which makes it very fun, um, but also, you know, a lot goes wrong.

Um, and so just, you know, learning to manage, you know, all the emergencies and the fires has been very interesting, to say the least! So for all of you, um, you know, what are some of the most common misperceptions of what a PM does?

Like, what is basically what does a PM not do? Um, I’ll keep that over to you first, Sylvia.

Okay, so I think the number one thing that I've heard is around how, like a PM is, it's kind of like the CEO of their product and owns all of the decisions. And yes, that's kind of true, but also, it's not as easy as everyone makes it out to be.

Like, yes, you are there to drive the vision and the strategy and the product direction, but you also don't really have direct influence over anyone. And so your job is more to make sure that everyone else is bought into that before you can actually get anything done.

Kali, go ahead.

Yeah, I mean, I thought that was the one that came to my mind too. It's just like you're—I can't think of a— I can't think of an—I don't know, a cat. Are there like common perceptions that come to your mind and maybe we can debunk them?

Oh, that's a good question. Uh, that's actually a really good question. And if folks in the audience, if you have like general ideas of what you think a PM does, we can try to correct them.

But maybe going on that question, what is— So how what is your process in terms of getting that buy-in from all the different stakeholders and the various like groups that you work across?

Like how does that—does that end up being the vast majority of your work or… or talks through a little bit about that?

Yes, so I’m happy to start and then I’m curious to hear what everyone else—like what your guys' process is. And I think this actually leads to another misperception that we can call out, which is that there is no single framework to building successful product or being a successful PM. It's just—it's a toolbox, and you learn.

Um, but specifically around driving alignment, a lot of this is one, starting with doing the groundwork around understanding a problem space, being able to understand yourself like why this is important, how it aligns with potentially the business vision and mission, um, and why we would invest in something to begin with.

And then once you have a good sense of that as a PM, then it comes down to making sure that that context is clear to everyone else. And this has worked differently across different teams that I've worked with.

So at Brex, for example, um, a lot of the times I'll start with a close collaboration with a smaller group of people, but then when it comes to broader communication, we have a very written culture, especially in the time of COVID.

And so it's a lot of memo writing and then kind of sharing it out, getting feedback, setting up individual meetings and chats and conversations to make sure that any concerns are kind of closed out. Or if open questions come up, figuring out how you can reconcile any potential problems and then just making sure that there's visibility into these decisions that you're making, whether it's managing upwards or managing downwards and outwards.

Yeah, I'll actually jump in. Um, I think, um, you know, from a PM, I actually do everything and it really depends on the situation.

And then a lot of it depends on the maturity of the product that you're working on, um, in different stages of where the product is, right? Um, you know, I think a common misperception is, you know, a PM is like a project manager, you know, and you're there to like drive execution and Gantt charts, which is totally not what we do.

I'd be fired if I were to do that. Um, but yeah, in terms of like the influence, um, you're right; you know, nobody actually reports to you and nobody actually needs to listen to you, right? But, um, you know, one of the things that we’re talking about is, you know, if you do have an engineering background, it is very, very useful

because a lot of times engineers do respect that, you know, their trade, if you will, and when you prove to them that you know, you can talk their language, they are definitely more open to some of your ideas.

Um, and that helps, you know, just, you know, influence, you know, just the rest of the team and driving alignment to one vision.

Yeah, I like that! God, um, I was just gonna say I think one perception that is probably true is that it's kind of the PM's job to say no to stuff too.

Um, like just people are coming to you with at least in my, uh, sort of more enterprise-y world, customers want stuff and it doesn't always make sense for the company.

And I think that the PM is kind of the linchpin there of making sure that things that do end up on the roadmap, like, are things that are going to make sense for the broader strategy.

So that's one that I would just say is a—is an accurate perception, I think. Um, Helena, when you are, you know, as a founder, your own PM, how do you prioritize, you know, feature requests from your users and, you know, and to develop your roadmap?

It's a great question and kind of relates to what Colly was saying with like, you know, you being the no-sayer. So I'm the yest-er and the no-sayer, so it was this internal conflict of like I want this feature built, but I know it's not focused enough.

Uh, we're in this interesting position where, you know, we could be building our platform for schools, we could also be building it for companies and employee kind of happy hours and those are very different products and they have very different end users.

Um, but we want to do both; I'm going to do everything! So I catch myself telling myself no all the time, and for us, it's easy to get excited about new features and easy to kind of jump into building things, especially with backgrounds in engineering.

So our default is like, oh, this is cool, let me build! Um, but in reality, it's like, no, let me kind of validate and think about how this fits into a greater puzzle.

Um, so in an ideal world, you know, I would be scoping things out and figuring out like a longer product map and working backwards, um, which we try to hold ourselves to, uh, with COVID, however, everything changes.

So rapidly, especially being a video platform, um, that while making like, I don't know, three-month, six-month roadmaps, all of that kind of changes on a moment's notice as well.

Um, so I—I don't know if that really answered your question, uh, but, but this idea of like being the PM and then the people who like playing all parts of the puzzle, you're like internally trying to take different roles and challenge your own ideas, um, and really be thoughtful about, you know, why are these ideas that we should pursue?

I'm going to go to, um, one of the questions from the audience that was also on my list, but um, the question here from Athena is, uh, what would you say are the crucial skills to becoming a successful PM? Like if you could name one or two skills that you absolutely need to develop, um, what would you say?

I think one of the most important things is just being able to tell a story. I mean, at the end of the day, we're all humans, and we all love to hear stories. And if you can tell a very compelling story and communicate your ideas in that way such that it resonates with people, whether it be, you know, engineers, you know, designers, data scientists, or your customers, that goes a very, very long way in terms of getting buy-in and alignment.

Um, and you know, the other thing is, um, you know what I look for a lot in interviews is I look for people who are curious, which is not exactly a skill, but it's more of a trait that you you definitely need to have to practice.

And, you know, natural curiosity just, you know, helps with the whole vision and strategy aspect of a product, because if you don't question things, then you'll never, you know, get other ideas about, you know, what you can do.

So, so yeah, I was going to say plus 100 to medication and being able to tell the narrative.

There was a question also from the audience that's related, but do you also have to be a good writer?

Yes! You know, it's actually kind of funny because, um, this is also cultural. I felt like at Facebook, I did very little writing. Um, it was mostly bullet points and that was fine for most of the teams.

At Lyft, I had to do a little more writing, so I felt like I was back in high school, like always cramming for like essays writing product specs.

And then at Airbnb, I feel like I'm an author because, you know, the expectation, the culture here is that when you write volumes and volumes of documents, um, which I'm actually trying to change that a little bit because being a good writer absolutely helps!

Yes, I would say that it also does depend on the communication style that your team or company has. So I've worked on teams where people are a lot more visual, and so decks tend to have a lot more impact than writing an entire memo.

Is this something that you guys knew going into where you, you know where you're working now, or is this sort of something you figured out on the job?

Like, did you know what the communication style was? Did you figure that out prior to it?

In my personal experience, it was something that you had to figure out. Like, maybe you could guess a little bit. So as an example, Instagram was a very deck-heavy organization, and more specifically, they loved Keynote, not PowerPoint, but I think you could kind of guess that given some of the culture around Instagram being a bit more design-focused.

Uh, but sometimes you just have to go into it and figure it out.

Sorry, Vile!

Yeah, um, I was going to say something that one of my mentors has said to me too is like there's no such thing as the perfect PM; there's only the right PM for the right stage of the company, like for the right product.

So what ends up making you successful will totally depend on so many other factors. Like even if you're not a great writer today, that doesn't mean that you can't be successful as a PM if you happen to have like subject matter expertise on something or um, I think that there's like—don't—don't put any limitations on yourself, I guess is kind of what I would say there.

Like, find opportunities that will fit with your strengths. The only other thing I would add is like, you know, another good skill is being able to learn very quickly on the job and knowing, um, when you've done something that most people are not receptive to and being able to change that like very quickly. So very adaptive.

That actually leads me to, um, another question that just got asked in the chat, but what are the—uh, let me look at it right now—what are, uh, parts of the job that you know you learn through training and what are aspects that you had to learn by experience or intuition?

Um, let's say—so maybe framing it in the way that I've seen Facebook interviews be structured, which is typically there's a product sense interview around just like how do you think about product.

There's an execution interview that's very much about how do you define success and drive towards a specific metric, and then there's leadership and drive, which is just like who you are as a person and your character.

Um, the execution piece I think is the one that can be trained the most, because it's a lot of understanding data—understanding how to apply it or how to get insights out of it, and using it almost as a framework for how you prioritize.

And so that’s, in my opinion, the easiest one to train for. Um, where it's more about experience is around the product sense.

Um, so there are— there is some training that can be done there, and then around the collaboration piece, and this is where a lot of this is around like trying to, trying to build up experience around understanding the situations, understanding the people that you're working with.

Um, this goes back to the common misperception where there's a single framework for building autocorrectly or being a great PM—there really isn't! It's—you have an entire set of tools, you're constantly adding to that toolbox and trying to figure out what the right tools are to apply at the right time.

Yes, totally agree there.

Um, at Airbnb, um, we also, you know, the interview process is also very similar, um, and execution and goal-setting is definitely one of the places where, um, I would say it's the easiest to get training on.

Um, definitely you can learn that by by reading and, uh, to a certain degree with experience, just from, you know, launching products and stuff like that.

Um, but the product sense, the vision and strategy, that is definitely very experience-driven.

And that's where I actually think, you know, curiosity helps a lot, you know, just wondering what you could do, um, with and what you find are deficient in products, and you know that’s how you generate ideas.

So how do you define or measure success of a product manager? And how has that changed from being an engineer in your past roles? Helena, do you want to talk about it first from the founder perspective?

Interesting! Uh, I like the question; it’s—I think a lot of how we measure success—the question was like how do you measure success from the PM perspective of a product?

How do you, um, like how do you define or measure the success of the PM? For us it comes down to like how quickly can we get new products out, essentially, or advance I guess our company's goals.

Um, and sometimes, you know, what we build or we suggest isn't gonna be a hit and that's okay.

Uh, but how many experiments can we run, essentially? Um, how many things can be disproved is just as valuable as how many things can we prove?

Um, and then kind of iterating from there. Um, and for being an early-stage startup, and in most companies, I guess it's like the pace at which we do things ends up factoring into things very heavily, more so necessarily than quality.

So we do try to ship things every week; every kind of spec we have, we try to scope it down to what is like a one-week MVP of this grand vision that we have, um, just so that we can kind of validate things or at least cross them out.

Um, and then being able to execute on that. Um, so I think measuring success, um, really comes down to, uh, how well can you like define the core purpose and then hone in on that.

Um, I will add to that. I think that's great! That's very— a very quantitative way to measure success.

Um, you know, this has actually a change, so I've thought about this a lot, um, and one of the, um, things that I've kind of concluded on is if engineers want to work for you, or they perceive that you are providing some sort of value, that is a good sign.

Um, I would say that, you know, most companies, most founders are usually engineers with like really good product sense, and the fact that if an engineer needs that additional product sense, you know, person, um, I think that's a—that's a good sign.

Sylvia?

Yeah, I would say adding on to that, so not just at a high level around like did you solve for the problem that you were aiming to, but I've actually noticed that over time the additional measure of success that I've tagged onto that is also are you able to do so while essentially maintaining a healthy team dynamic?

So kind of to Vile's point around like would your team be excited to continue working with you, um, and a lot of this is just—it's so integral to your ability to get stuff done that you can’t just launch a product with no regard to how you're getting there.

Tell anything back! Um, I think that... yeah, I think that that's all basically what I would say too. I think the only other nugget that I've maybe noticed is just like making sure that your team knows what to work on is like, like if they always know what to work on and they know why they're working on it, then I feel like you're doing pretty good.

Um, to the point of like storytelling and really making sure that people—like engineers, as you all know, are really putting so much blood and sweat into something, so I feel like there's kind of a more qualitative way of just like making sure that people feel like they're working; they're putting all that work in for a reason that they understand.

What would you say is the biggest challenge of being the PM, uh, day to day?

Okay, I think one of the hardest things to do is to prove that you're actually writing value. A lot of what we do is more strategy-based, and so it's not something that, you know, an engineer—you know, you can measure like lines of code or how many PRs you put out there or like, you know, when did you ship—did you ship on time? It's very quantitative.

Um, as a product manager, um, you know, it's super like fuzzy, you know? If the product is successful, that's great, but you know, what—the engineers wrote the code and the designers need to design, you know, so, um, it's hard.

Um, yeah, I think one of the hardest things is actually just managing my own psychology around like what I think I have to be doing to feel like I'm being successful.

Um, and I think that also kind of influences what work I look because, yeah, I mean, to Vile's point, there's just like an inherent difficulty in showing your work when your work is really to like leave a bunch of stuff on the cutting room floor.

Um, so I think it's, it's a lot of just like first satisfying my own sense of like that I am valuable? So be anything?

Yeah, I would also say another thing that comes to mind for me is probably prioritization of my own time.

And the reason why I say that is just because there's so much that's going on across all of the different SFN members that you might be working with. There's always someone coming to you with questions, and so it's very much around like understanding what is urgent and impactful to figure out now versus what can wait or maybe be delegated.

And it's okay if it's not the perfect answer because it's not the most urgent impactful thing to figure out now. So, like where you focus your attention.

I wanna—I was gonna say that makes a lot of sense especially considering a lot of the work doesn't feel like it has concrete rectangles.

I find myself when I feel like it's not measurable enough to go back to engineering, so when I feel like I'm not being productive, I would go code, and then I'll be productive again, and I'll go back to my PM role, and then I can think strategy and I help between the two.

Um, and I guess how to measure productivity as a PM is something I'm still kind of figuring out myself.

Jumping into a question from chat: um, what is your—now, what is your most favorite part or the most rewarding part in a PM?

I think for me it's, uh, you know, I get to participate in all parts of the product development life cycle. I mean, I have an opinion, and people actually are forced to listen to my opinion when it comes to like design usability, um, even like technical architecture.

So I get my fill of like, you know, understanding everything, um, without having to go like too deep and actually go do it all myself. So, I mean, it keeps things interesting.

Um, and I'm never bored, for better or worse!

I would definitely agree with that; that's part of the reason why I was drawn to product management in the first place, which is you kind of just have these big problem spaces that you get to dive into, and you get to think about all of the different components within that product space and problem space, and you don't necessarily have to dive super deep into everything, but you get a taste of everything, and it's fun!

Like, it keeps things interesting for sure. It keeps you on your toes!

For me, I think it's a little bit like—if anybody's ever gardened, there's just an inherent satisfaction in like bringing order to chaos, uh, and kind of to what Sylvia's point, there's just, there's just something really fun about starting out with like a really nebulous problem and then slowly bringing more and more clarity until you have something that is working, hopefully, or not working, and that's great too!

I'd say for me, it's definitely the ability to wear all the hats, kind of like you were all saying that there's chaos everywhere, and hopping between all of them.

And for me, I unfortunately—well, fortunately as well—have to dive into all of them deeply and do them all.

One day I will hire to replace myself in those roles, but wearing all the hats is definitely what drew me to be a founder, and if I wasn't a founder, then being a PM, um, 100%.

So, um, I'm gonna kind of combine a couple questions that came in through chat, but how would you suggest thinking about a company to work for? And, you know, and maybe a different way to ask that question too is like how do you figure out if a specific startup or product is going to be right for you as a PM?

So maybe you can even just talk about your own experiences. Like, how did you decide to work at the companies that you're working at now?

Yeah, I can start. Um, I guess maybe because my search was relatively recent, maybe about a year ago.

Um, so at the time when I was looking to leave Facebook, um, I was actually looking to move to a much smaller company—ended up at Brex. But when I was interviewing, I actually took the time to just talk to a bunch of different companies across different sizes.

And some of the things that stood out to me—so high level, what I cared about was, is the product that I'm working on, does it have some positive social impact? Um, is the leadership good? Is there a growth opportunity in terms of like learning new things and diving into new problem spaces?

Um, obviously all of this, it's really dependent on who you are as a person and what you care about, uh, but some of the things that stood out to me were as you go as you talk to different size companies, you'll find different things, right?

So at a much smaller company, maybe C-stage or Series A, you might be coming in as like the first or second PM and you get a lot more opportunity around just kind of like diving in and wearing a bunch of different hats and defining the culture, etc.

But what you potentially lose out on is having more product peers around you to learn from, and obviously there are ways that you can get that from your community externally, but it's a little bit different, right?

And so there are those trade-offs around like are you looking for a slightly more established culture, a little bit more structure? Uh, how—how do you want to balance that against learning and growth and the types of problems that you take on?

Vile?

Yeah, um, I agree with everything that Sylvia said. Um, I think, you know, if you're early in your PM career, it's really good to be at a, you know, large company like a Facebook or a Google or, you know, Microsoft because there's established frameworks, there's processes that, um, you can just add to your toolbox, and they're really good foundations to have.

Um, one of the reasons I left Facebook was I had gotten to the point where, you know, the products or the space that I was supporting, um, you know, they're fairly mature, and you know, it was just like, you know, diminishing returns in terms of being a PM.

And so when I, uh, interviewed around, um, I think I went to the most chaotic company, um, and that was a lot of fun, um, and it was very tiring too, but, um, you learn a lot just different business models, and then you gain more, uh, things to add to your toolbox.

Um, so I think, you know, just depending on where you are in your career, um, if you're more in the learning from like very established, like, you know, educational how to be a PM versus like if you want to brave the wild west and learn on the fly on the job, um, you know, you kind of need both.

And, you know, for me, I've kind of hopped, you know, in and out. Um, I would say that Airbnb is slightly more under control than Lyft, um, but, you know, probably not as, like, you know, structured as, you know, Facebook was.

So yeah!

Yeah, I would—I would second that to you and just say I think so much of it depends on your own learning style, um, and also just kind of like how urgently you want to make this transition too.

Um, if like if you're already an engineer someplace, then there's potentially a way to like lateral into product there, um, if that's not a game that you're wanting to play, then I think you just go wherever he is going to like let you do the thing that you want to do and you hope for the best.

Um, and you know, it either works out there or you've learned some things, and you can apply them in a place that's going to fit better. So I think it, from my own process around this, it just comes down to like something along the lines of like risk tolerance, learning style, and then there's things to wear on top of that.

As you feel more confident like for me, I have seen the kind of super wild west, and the next thing that I will want to add to that is like what does this look like in a more polished environment?

Um, I don't know if that's helpful, but I actually had, you know, one more thought, you know, just talking to the people and understanding who you'll be working with is very important.

Um, as a PM, you know, I—I have my engineering counterparts as like, you know, we're attached at the hip essentially. Um, and so, you know, if you're interviewing and you know who your engineering counterparts gonna be, and you just, you know, it's just not vibing, um, it's gonna be very difficult to, you know, get anything done.

So I would say there's a people aspect to that as well.

Going off of that, I'd say I've only picked roles or—not only, but I picked roles with that being like the highest qualifying factor. You know, if the team is amazing, if the founders are amazing, um, you want to be there kind of regardless of the role.

Um, you can figure out—I'm talking mostly from like early stage startup experience—but regardless of the role you can have, you can kind of expand that role and take initiatives in various places, um, you know, or you can just become your own PM apply to accommodate or be a founder, um, that's always an option.

Uh, but I—I would say kind of like Colly was saying of like you know, figure out what things you care about, and those are the things you should optimize for, whether it's team, whether it's the mission of the company, uh, whether it's you know, the actual project you're working on—the product, right?

So you—that's sometimes a very personal question of like what are you optimizing for and maybe it's how fast you get a job, maybe it's the salary, the compensation that they can offer you.

So, um, that is going to vary for everybody. It's a great opportunity to come up with a framework!

Yes, so if um, I'm earlier in my career, um, what suggestions, you know, do you have for how I can make this transition, um, you know, to becoming a PM, especially if I don't have any prior experience?

I would say that you know with, you know, regardless of what role you have, you know, there's always going to be value in understanding, you know, whatever you're building, who your customers are, and what's really important to them and truly being like empathetic.

I know that's probably like an overused term of like having empathy, but, um, you know, that is like the first step for any sort of like product idea is, you know, is there truly a problem and who who are you trying to serve, right?

Um, and so regardless if you're an engineer, if you're a designer, a data scientist, like that is—that should be like the foundation.

Um, and once you have mastered that, I think it's a lot easier to just show that you are ready to move into product.

Yeah, I think that there's a ton of things that you can do just in terms of training your mind too, um, and like kind of start with the internet.

There's tons of videos on how to—how to just even begin thinking about these things, um, and reading books like the Design of Everyday Things and just some of the classics that are really foundational for how to think about the ways that we do design the objects and experiences in our lives, and just getting those muscles, I think, um, to whatever degree of rigor you want to apply to yourself.

So doing something like starting a blog and just challenging yourself to like write your own product specs for things that already exist, um, it's pretty easy to find information on like what the sort of—as Vile and Sylvia were saying—like what the PM interview is pretty standard.

So just like rehearsing different iterations of answers to those questions, um, eventually like you will get a job if you just keep—you know, it's like going to the gym.

Just to add on to that, I think a lot of this goes back to what I was saying earlier about curiosity being such a big part of being a good PM.

Uh, I remember early on when a lot of my friends were asking about getting into PM, a lot of the training is asking those questions like why is Airbnb's strategy the way that it is? Why is Uber doing things that they're doing? Why are, I don't know, even like doorknobs designed the way that they are since you've got a design of everything?

Um, so it's—it's all about asking those questions, and then thinking through it, thinking about how you would do it, thinking about why it's being done the way that it is, and, and just building that muscle.

This kind of leads to—you—you all talked briefly about PM interviews. Um, a question that Lean asks about what's the best way to prepare for a PM in a row and assume you're talking to someone who's never been on one before.

So I, yeah, I think, um, you know, building that muscle.

Um, there's, there's so many resources I think on the web right now in terms of like, you know, the various skills that, um, they look for as a PM.

It's very nerve-wracking, I would say, because a lot of it is just thinking on the fly because you never know what you're gonna be asked for, but there's always, you know, there's questions that come up over and over again.

You know, if you were a product manager in this space, what would be the next feature that you would, um, build and why?

Um, and so just really being able to assess a bunch of different products, even ones that you use, you know, every day, doesn't have to be tech, but like, you know, Kelly and Sylvia said, you're building that muscle and training yourself to be able to think on the fly.

Um, and, yeah, and I think also like practicing out loud or with somebody else who can—because one of the things that folks are testing for, as everyone here I think has mentioned, like communication is such a big part of the job, so just bearing in mind that you're not really being tested on like whether you get the right answer, it's so much more about the delivery and whether you can structure and articulate your plan regardless of whether it's a good plan or makes sense.

How do you show your work? How do you structure your thoughts?

Adding on to that, um, at least for Facebook interviews, a lot of what we were trying to look for was around how you got to the answer that you did.

What was that thought process? What principles were you working off of to make decisions? And so being able to communicate that, being able to think deeply and talk out loud those thoughts, that's all more important than what the end answer actually is.

I'm going to combine a couple questions from the audience, um, but they're essentially around your background.

So, um, in what ways did your technical background, you know, prepare your camera rolls, and also if you're not from a technical background, can you still break into product management? And like, um, and you know, what advice would you have for non-technical folks trying to get into?

Yeah, you know, I feel like in Silicon Valley, um, it's almost like a requirement for a PM to be an engineer in the past, but I don't think that's true for, you know, any, any other area possibly.

Um, but you know, I would say that, you know, the PM interview process, there's actually really nothing like technical about it, um, aside from maybe some questions about how you would analyze data.

Um, but you know, there's really nothing about coding or like, you know, how you would build something, uh, per se.

So, um, I think some of the best PMs that I've known have had like really interesting backgrounds like musicians or, you know, just, you know, really random.

Um, but you know, it's that drive of like curiosity and being able to think through, um, what you would improve about things and how you would go about it and having like, you know, good reasons of why you choose to go that way.

Um, so I know that's like very generic, but I don't actually think you need to have, um, a technical background.

I think when you're on the job it does help, you know, grease the wheels a little bit with engineers, but, um, you know, I don't think it's a prerequisite at all.

Definitely a common misperception that you need an engineering background.

And let's see, I think we have time for one more question, and then I want to remind everyone that after this, uh, each of these speakers—each of the panelists will be in their own rooms and you can go and continue to ask them questions and talk to them.

Um, but for our last question, um, let’s see. Let's see!

Um, have there been any big setbacks that you've experienced in your, you know, careers either as like a PM or founder and, you know, how did you overcome it or what would it make you do differently?

Uh, I would say that setbacks are like very much in the eye of the beholder.

Um, there's kind of something that I've tried to live my life by is this idea that the obstacle is the way. So if there is something that is getting in your way or that you're seeing as a setback, it might be more useful to see it as something that's like teaching you how to get to the next place that you need to go.

Um, so I would say, no, I've never had any setbacks, but I have had lots of obstacles. [Laughter]

Um, I—if no one wanted to jump in there and answer that, I actually have one more question that came in.

Um, and you know as you know, women in tech, as, you know, women founders, as women PM, like are there important challenges that you think need to be addressed or are there things that you see male colleagues get away with that you know that you have—you can't?

Um, anything to say to, you know, on that end? There's so much to say there, you know?

Yeah, I—I, um you know, so one of the things as a PM, uh, I think somebody said this to me like a while ago, but it's like you basically have to like repeat your story in 10 different ways before people truly get it.

And I feel like as a woman, you actually have to repeat it like 50 times before you will actually get it, where I see it's a lot easier usually with men, especially, you know, in tech where you are trying to explain some, you know, technical details or like engineering concepts or architecture.

Um, I don't know. It—you know, I think there's just unconscious bias there where you're not as credible and so you have to keep on repeating, um, and you know, finding a good—I would say not necessarily a mentor, but you know, somebody in the company who's like a sponsor, someone who's like very supportive of you, um, helps if he is male because, you know, again, lends credibility in some like weird way.

Um, you know who—who has your back, I think that's very helpful, but, um, but yeah, it's you know, broken record over and over again!

I would add on to that. Um, I think the broader theme is just knowing your worth, right?

And having confidence that the opinions that you're surfacing or the direction that you want to push in has credence and that you know what you're talking about.

And so don't let, um—don't let kind of these like different biases bring you down.

Plus one! Yes! I would also say too like don't get in your head about it being a gendered thing and don't assume that if you're—if you're having trouble that it's because you're a woman or you're whatever, a zebra, you know?

Like just don't add that layer on it for yourself even because, um, it's—I’ve been actually having conversations about this with my boyfriend because somebody was like, “have you ever experienced imposter syndrome as a white man?”

And he was like, “yeah, you know?” So I think too, sometimes it's easy and I've definitely been guilty of this to think, “oh, like that's happening to me because I'm a woman.”

And it doesn't—it doesn't even have to be true, so—and for me too that's like an—it's an additional emotional burden that I'm putting on myself.

Um, Helena, anything else?

The only other thing to add is plus one to everything you all just said!

Just like the assumption that I'm not technical and the assumption that I don't know what I'm talking about, and that like is like blatant face pretty frequently.

I'm just like, “oh, let me talk to like your technical co-founder” or “let me talk to like someone on engineering from your company.”

And it's just, um, I mean they're making assumptions, and my role isn't CTO, uh, but just those assumptions just mean that you have to lean into just feeling self-confident and assuming that it's not because of your gender, like you were saying.

Would help, and I would also say I'm definitely guilty of that; you can hear I ran to my co-founder about it a lot, but just, just be self-confident, know your worth.

Um, and um, I guess don't think too much about it.

And last question, I swear just because I got a one—uh, plus one in the chat—um, but let's see.

Uh, what single thing have you done that has helped you prevent burnout in your career or in your work? [Music]

That's assuming we're not burnt out!

Oh sorry, go ahead, go ahead!

I was just saying I frequently like take out an entire weekend and go backpacking. This was before the California wildfires, uh, but like every few weekends, just completely disappear, uh, and go backpacking, and that was a good reset.

Even though my days are usually crazy to get up at like 7 AM and work to like 10 PM, um, but then making sure that there are, you know, hard resets every now and then, um, has been working for me.

Yeah, I would definitely say sticking with your routine.

Yeah, sorry, go ahead, tell.

No, no, you first!

Yeah, I just was gonna say sticking with your routine and making sure that you have those things, uh, to help you reset or refresh and re-energize are extremely important.

I actually had a couple of years at Facebook where I started feeling quite burnt out, and I realized part of it was because I was prioritizing work over going to work out or doing other things that were really just for me and investing in myself, um, because I felt like that was the only way to get the work done.

And I realized that I was just doing myself a disservice because keeping my energy up was just as important, um, in terms of like being successful.

It's more of a marathon than it is a sprint, and so you need to make sure that you're taking care of yourself.

Yeah, that’s basically what I was gonna say too. I think the only other nugget that I've maybe noticed is just like making sure that your team knows what to work on is like—

Like, if they always know what to work on and they know why they're working on it, then I feel like you're doing pretty good.

Um, to the point of like storytelling and really making sure that people—like engineers, as you all know, are really putting so much blood and sweat into something, so I feel like there's kind of a more qualitative way of just like making sure that people feel like they're working; they're putting all that work in for a reason that they understand.

Thank you! All right, thank you to the four of you who spent your time talking and sharing their stories with us today.

Um, so each of the speakers will be in breakout rooms where you can meet them and ask them more questions.

Um, and if you're interested in open PM positions at YC startups, you can always check out workoutstartup.com.

And thank you guys for everyone's great questions in the chat and for joining us today. It was super enjoyable and I learned so much from you guys! Thank you!

Thank you so much! Thank you.