 Cool. How many of you said it was your first time here? Okay, I decent amount. I've been here once before. I'm really excited to be back. I think this is really cool that there's a place to come and learn about product management that did not exist when I started in product management. So I think it's a really unique opportunity to have a place to be in New York amongst other people and learn more about this. So I'm excited to talk to you and be here tonight. So thanks for coming out in the cold. And yeah, today I'm going to talk a little bit about decoding product management. That's my pun of the evening. But really the selling point here is working with engineering teams and not being a technical product manager. So tonight I'm going to cover a couple things. Pretty basic. I'm going to talk a little bit more in depth about my background because that's really at the core of this presentation. I'm not a technical person. I don't have a computer science background. And it's something that you're probably interested in learning about my path into product management. I'm also going to break down what product management is because it's kind of a slippery definition depending upon who you ask. And I think it's really important that we kind of get on the same level before we talk about dealing with product managers in engineering capacities. I'm going to demystify tech a little bit and engineering a little bit and talk about some of my past experiences with engineering teams and things that went well, things that didn't go so well and what I've learned at the companies I've been at. And then I'm hoping that I'll give you some actionable strategies. I don't know where you are at in your career today if you're just starting or if you're in product and you're just coming to kind of learn a little bit. But I'm hoping that there's something for everyone in this room to learn a little bit more about. I've been in product for six, seven years in New York City. So I've been around the block in a bunch of different kinds of companies which I'll talk about in a second. So I'm hoping that you can take something away from this and there'll be time to ask questions at the end. I'll just stick around at the end. You can bother me and whatnot. So thanks again. Cool. All right. So me in a nutshell. I am from Chicago. I'm a Chicago Bulls fan. Big question. I am a big deep dish pizza lover, but it is different than New York pizza. It's not comparable. It's a completely different breed of food. So don't ask me that. Yeah. So I hail from the north side of Chicago and I went to school at the University of Wisconsin Madison. So I'm Midwestern or through and through. I studied journalism. I had a really big passion for writing and I was focused on strategic communications. So advertising, marketing, public relations, that kind of breed of work. I think it's really important to note here. My internships during college were not at big tech companies. They were local. I think I worked for the make a wish foundation one summer writing children's stories about when they got donations and got to do their wish, which was really sad and cool at the same time. And I worked at Chicago athlete, which was a magazine covering local athletic stories in the area. So I really didn't have any flashy internships at all. I wanted them. Don't get me wrong, but I didn't have them. And I was staying local and just getting some writing experience. And when I graduated from college, I was just dying to work at an ad agency. I was dreaming of, you know, that mad men kind of life, but like in real day where you get to work on a Super Bowl ad and come up with like a really big sexy campaign. And it's glamorous and, you know, you get to work with like great people and celebrities and you get to write all that stuff. And that's kind of really what I was focused on. I also had a fixation with New York City. I don't know where it came from, but I always knew it was somewhere I wanted to be. And so when I graduated from school, I was like, well, I'm going to take a job that takes me to New York, whatever that may be. So through a connection, I got in touch with a recruiter with a recruiter from the Huffington Post. At the time the Huffington Post was associated with AOL and there was a writing editorial job. I've been doing a lot of writing in college and through my internships. And I'm like, I'm really interested in this. I can move to New York, you know, if I get this job. And she said, this isn't going to pay a lot if you want to move to New York City. We can all laugh at that because New York is insanely expensive. I have this role on the AOL side. It's a production role. And I was like, okay, you know, what does that mean? She's like, you know, like, there's a product manager who's going to be helping, you know, building some editorial sites. I was like, say no more. It's a job. I'll be able to like move in and move to New York right away with a salary. So I took the job as an associate producer at AOL. AOL, you know, AOL Mail, AIM is, they're killing AIM this year, which was really sad. But on the AOL homepage, there's a bunch of different editorial sites. And so I was working on one of those editorial sites as a producer under the product manager who was in charge of the site. So we had a handful of engineers and a handful of editors who were producing news content that will go up on the AOL homepage. So pretty straightforward. You can imagine six or seven years ago. It was a little more basic than it is today. It's easier to understand now. But I was kind of just doing, you know, whatever they needed me to do, whether it was kind of explaining things to our engineer, you know, the issue the editor was having with our CMS when they were trying to write a story. I was working with our sales team if they were trying to pitch an advertising package. I was just doing random stuff. And I was just happy to be in New York. And so my manager looked at me one day and he said, you know, you're on track to become a product manager. And I said, okay, like that sounds great. What is that? I have no idea what a product manager is. And so he said, you know, it's what I do and it's really building a product roadmap. You know, how I've been working with the engineering team and telling them what to build and, you know, kind of the strategy and what we're trying to do. And I was like, that's something that you can do as a product manager. And I was like, okay, I think I can do this. I've been in this role. I've been working with this team. So I was basically the point of that is I stumbled into product management. I came into this producer role because it paid more than an editor role at the Huffington Post and I just wanted to move to New York. So it was completely happenstance. I didn't have any technical background getting into product management. I was at AOL for about two and a half years and Rolling Stone reached out to me. Winter Media, which owned a weekly men's journal and Rolling Stone at the time. And they are this, you know, big print brand that's, you know, a historic music company and I'm passionate about music. I'm like, oh, this is great. We're trying to go digital. You know, this is like 2013 or something like that. We're trying to like make our websites flashy and like establish a web presence and you're coming from this big tech giant AOL. So you're going to come on our team and help us do that. I was like, great, awesome. So I went over to Rolling Stone where I was working as a product manager on all three sites, mainly focused on kind of helping them build their mobile presence because they had maybe one broken mobile app and they had mobile sites, but they didn't really understand what it meant to build SEO, search engine optimization. Again, they had advertisers chomping at the bit to work with Rolling Stone. It's such a great flashy brand, but all their money is in digital. Money is shifting to digital. What does that mean? Like how do we build these things online? And so I had a little bit of experience with that from AOL. I was helping them kind of establish a marketing and advertising strategy for those websites. I was there for about two years and a dream job came across my desk to work at SoundCloud. I mentioned I was interested in music and this was a music streaming service. I had been in digital publishing and digital news for a very long time and I wanted to like understand what platform development really meant. What does that mean to like build in a mobile app? I have no idea what it takes to get an app into the app store and for you to listen to what I'm working on like I just had no concept. And they had a really interesting role that merged my experience with advertising in college and even throughout AOL and Rolling Stone with product management. And I became a product manager for ad products and monetization in New York City. So I was working on ad formats. So if you're streaming music on SoundCloud, you come across an audio ad or a video ad making sure that video ad plays, making sure that advertiser gets paid, making sure the ad experience doesn't suck that much even though we all don't really like ads. But really understanding like what it meant to build on a mobile platform, what it meant to work with Apple and what it meant to work with Google and submit an app to the app store. I had no idea what that meant. So it was really a great opportunity for media to really understand platform development in a really technical way that I had never learned before in digital publishing. So yeah, I was there and kind of like digging in and I was at SoundCloud. You'll see a pattern here for about two, two and a half years. And then recently this fall I joined Spotify. So I joined as a product manager on the creator team. Very different from the ad side, but again really in line with like my passion for music, passions for artists. The stuff I can't get into too much detail about what I'm working on, but I am working on tools for artists and helping them use Spotify and really make sure they're getting the most out of our platform. We launched Spotify for Artists in early 2006, 2017. Yes. And so we're constantly iterating and giving musicians the right tools so they can maximize what they're doing on the platform. So you can see this common thread of music throughout everything, but you can see also that there wasn't this moment where I said, okay, I need to kind of like understand this tech space, but I'll get into that. So this is really where I became a product manager at AOL and this is me today at Spotify. So I've had the fortune of working at a lot of different kinds of companies with a lot of different engineering teams, both here in New York and remote engineering teams in Europe. So I've had that really great experience of getting to work with lots of different personalities. And yeah, I'm here to kind of share some of those war stories with you. I think it's kind of funny. So why am I here to talk to you about something that I can't do? Normally when people come in and do a talk, it's about something they're really confident in, a subject matter that they know back and forth, and you could argue that I guess for this, but I'm telling you that I don't have technical experience. So why am I here to talk about that? First and foremost, it's something I'm really proud of. I used to be incredibly self-conscious about the fact that I did not know how to code. I felt like I was an imposter in this world. I kind of stumbled into a product manager role at AOL. And I started working with engineers and they started speaking about agile development, which I didn't understand what that was, sprints, what's a scrum master, like all this stuff was brand new to me. I would sit there and write things down and then go Google it after our meetings because it really didn't make any sense to me. So it's something I was recently, I would say in my time at SoundCloud, became really confident in and I'll tell you about that turning point later on. But another big thing is product is growing. I mean, you guys are all here. There's a place called the Product School. That didn't exist when I was in product management in New York City six or seven years ago. There was maybe a general assembly or something a little bit more broad, but the fact that there's a place that people can come and learn about product is super exciting. And the pipeline of product managers is sourced from everywhere, and I'll get to that in a little bit later, that product managers are coming from untraditional backgrounds and really finding a place here. And so I think it's important to celebrate that and to highlight that product managers without that technical background. It is the second most question. The second question I get asked the most, the first one is what is a product manager, but the second one is, oh, so you know how to code. You work with engineers. I get asked all the time and someone mentioned, they get asked all the time too. So it's a very relevant topic in this field. But I would say of all these things, most importantly, I wish that someone had told me this and someone had sat up here and told me it's okay if you don't know how to code and you're going to be able to be a successful product manager without those skills. I think it would have really helped open my eyes earlier on, and so I'm hoping I can be someone for you to kind of give you a different perspective, not to say that coding isn't valuable. It certainly is. But it's not the only value you can bring to a team. So I want to highlight that and make sure that you walk away really feeling that because it's something that I had to learn through years and years of product management. So like I said, I want to step back and kind of define what is product management. We can't really talk about the relationship between product and engineering without defining product management. So does anyone want to give me like the first thing that comes to their head when I say what is a product manager like right off the bat? Any brave souls? Yes. Yeah. Plan and decide the product. Cool. Anyone else? Any brave souls? Yeah. Someone that's a liaison connecting a lot of different departments. Yeah, a liaison, yeah. A person who creates a scope for technical people. Creates the scope. So it's like a planner kind of. So I kind of went from lowbrow to highbrow here. I'm going to read these off but I think it's interesting to kind of look at these you know generic definitions. Wikipedia says the product manager investigates, selects and drives the development of products for an organization in line. Mind the product which is a global product community if you're looking to kind of seek those out. It's the intersection between business technology and user experience. And then on Google's product management homepage they say the architecting the future of our products by bridging engineering and business as you manage a product's full life cycle from strategic planning to development and launch. So not that far off. You know like a lot of these buzzwords but also like so pretty different in terms of like how they're thinking about it. I think it's important to kind of take a further step back to get really meta and say you know why are all these companies and places defining product management so differently? Like why isn't it super clear? Why is it that I still can't explain to my parents what I do? Like it doesn't make a lot of sense. So I really tried to take a step back and think about it. And I think like I kind of said earlier product is still emerging. The product school is amazing but it's new. There's not a lot of places that acknowledge product management as a trade. And so I think because it's so new and because it's transient it's harder to pin down. Engineers have code that they can deliver. Designers have wireframes or high fidelity designs that they can deliver. Product managers don't have that tangible. I say tangible with air quotes because it's all software and it's all in the cloud. But product managers don't have that tangible deliverable that they can necessarily deliver and show in a portfolio per se like an engineer or a designer might. So it's harder to actually show the product of what you're working on. You can say I product managed this product. Oh did you code it? Did you design it? It's like no I you know I scoped it. I managed it but it's it's harder to like just holding your hand. It's different everywhere you go. I personally experienced this and we've just seen this in three different perspectives. Different perspectives. It means something different to different companies. I can vouch for the fact that I've done different things and had different responsibilities as a product manager at every company. The perspective and the hierarchy and who reports into who is just different. It's not very clear which is exciting because there's a lot of room for growth but it makes it challenging when you're trying to pin it down. Some other common themes. So I took another step into looking this and doing some research at the big four. The big four there's a lot of text on here. I don't expect you to read this. The big four I talk about our Facebook, Apple, Google and Amazon. Like let's get the most generic product manager description on the table. Not senior, not associate just a basic generic product manager description. And you can see some common themes emerge here. You can see in some of these words that we were just mentioning. Launch, vision, execute, prioritization, business, requirements, competition, priorities. Like there's a lot of those like key buzzwords in there with really action driven verbs like develops and creates and plays really flashy that come in any job description. But a lot of these also talk about the role of engineering and how you have to liaise on with engineers and how you have to communicate with them. But they don't really say oh you need to know how to code. I will caveat there are certain job titles in certain places that are looking for a technical product manager but they will say technical product with a CS degree or knows X, Y and Z language. So it will specify but these are generic from like the top tech companies that don't necessarily say you need to learn how to code. My clicker is broken. There we go. Qualitatively in my experience product managers say you need to know enough to work with engineering. But what does enough really mean? Does anyone have any ideas of what enough could mean? You need to know enough to get by. What would enough be? I think understanding the intersection of the business from how in my case like a music app understanding how the back end talks to the killer, talks to the front end app, talks to the website and other app APIs. I think having an understanding of what's going to work and what's not going to work and knowing the limitations and capabilities of the engineers. That's a really great answer. Better than mine. Yeah. Just to add to that, I think another aspect of it is sometimes with larger products you have different teams working. And it's important you know how one change impacts everything else. The impact. Totally the downstream impacts on other teams and the dependencies. Anyone else? Yeah. Sizing. Yeah. Totally. I like to call that first thing concepts not code. And this is kind of like one of my core principles when I start with the tech team is understanding the tech stack. So the tech stack is the different systems that your engineers are working within. I'll give you an example at SoundCloud. I was working on ads. So we had an ad server that delivered an ad from the server to your phone. So I had to understand the different blocks and the different places down the path that my ad went from server to phone. I didn't have to understand how exactly it got there, but I needed to understand the journey that it went on. I needed to understand the impact and what was going to happen if one of those systems broke down, but I didn't have to understand how to fix it. So it's really about mapping out like those different concepts and not necessarily mapping out the code itself. You have to know enough to ask the right questions and say, well, what's the impact of this? I think one of the best examples is really understanding if you can build a whole feature versus half of a feature and get it out sooner. So whole feature, get it out in a long time, half a feature and get it out sooner. What's the business impact of that? Is that going to improve my bottom line? Is it going to really put my business behind? Really understanding the business impact and the sizing of that is really important. And then you need enough to inform decision making. If you understand how hard or easy something is, you can understand the sequencing of how to order certain things. If we do this work first, it will unlock this in order to launch this sooner. So these three concepts are really important to me when I start thinking about not necessarily knowing the code, but knowing enough to ask those right questions to make informed decisions and give my opinion in a way that engineers will trust. Because at the end of the day, engineers are looking to product managers to prioritize and guide the team. So what do engineers need if they don't need a code? Because sometimes I joke around and say, we just need to speed this up and I could just go and code because this would be quicker, but they don't really need that. Engineers need a business owner. They need someone who can really understand the bigger business goals. So as an engineer, they're working and they're coding in their terminal and they need to understand how what they're doing is going to impact the bigger business as a whole. They need the voice of the consumer. So something that we do at Spotify I can talk about is we do something called sound checks. We'll bring consumers and artists into the office and we'll do that whole testing thing where we watch them use the app and we get to ask questions and see what works and what doesn't work. The engineers don't have time to do that and so me as a product manager, I need to represent the consumer in that experience and be able to go and explain a use case and a pain point to an engineer that this isn't working. I saw the artist trying to use this functionality on Spotify and it's not working. We're going to need to fix that. They don't have time to go do that and so I need to represent and kind of form the context for them around the consumer's voice or the constituent's voice. And I always say a context is king. They need to see the bigger picture and how these different pieces kind of fit together from a downstream perspective. If we don't do this, this won't happen for this team or if we choose to go with this strategy or this architecture plan, these are the implications that are going to happen down the road. They need that bigger picture context and they need that from a product manager because they're not going to be the ones to be doing that. In fact, technical product managers can be a hindrance. A personal story for me, like I said earlier, that really was a turning point was at SoundCloud. So I got to SoundCloud and I was really open when I interviewed for the job. I said, listen, I'm not super technical. My manager, eight-year Google veteran CS degree could get into the code if he needed himself and I'm like, I can't do that. I'm going to be really open and honest with you, but I'm really, really excited about music streaming. I'm really excited about the product and I'm going to do what I need to do, learn what I need in order to do well at this job. So you can imagine I was super intimidated coming into that job. Mind you, his background, me, my background, being a female product manager at that, playing into those stereotypes as well. It was just imposter syndrome to the max. And I always felt that my team, my engineers, they had an issue they would go to him because it was a quicker answer. It was like, well, no, I don't have to explain all these concepts to her. Like I was so self-conscious about that. And at one point my engineering manager said to me, Jory, I need you to really lock down these concepts. I need you to understand, for example, how an ad gets delivered back and forth. I need you to understand the different components that are happening. But then I kind of opened up to him and I was honest and I said, listen, I'm super self-conscious about the fact that I'm never going to be able to give you the kind of technical detail that he can give you. And my engineering manager said to me, he's like, I don't want that. I need a partner, not a prescription. Because if you know too much and you know how to code, you're going to tell me how to do it. And I don't need you to tell me how to do it. I need you to tell me why I should do it. And that really stuck with me because it really gave me the confidence to realize that I don't need to know the ins and outs of exactly how to build this. I need to be able to make those decisions, get the context, form the bigger picture. And he said, if you knew too much, you'd tell me exactly what to do and I wouldn't be able to do my job correctly. And that really just like lit something in me and I was like, I don't need to know how to code. It would be helpful, but I don't need to know how to code. And perhaps my team can be more creative and empowered if I don't know how to code because I'm not in their space. So it was really something that was motivating to me and I thank him every day for kind of giving me that pep talk, but it only happened because I opened up and I was vulnerable about it too. So, okay, I hear you. You're listening to me and you're like, I don't know. It still feels like I need to know how to code. Get introspective. I'm not here to tell you not to code because I think at the end of the day coding is a super valuable skill and it's going to bring you a lot of success. I think you have to ask yourself, do you want to code? Do you want to learn how some of these languages is that important to you? Because if it is, you shouldn't stop yourself. You should explore that. I've known a lot of product managers who are just drawn to that and they go and take classes and they find that they really enjoy that work. And if you enjoy that work, you should do that. But I think the broader goals and the broader strategy is think about your five-year plan. Think about your ten-year plan. Do you want to be a CTO, chief technology officer where you're managing engineers? Do you want to be a general manager or a chief product officer where you're maybe managing designers or other product managers? Look at those types of roles and try to understand what you're trying to achieve because I think at the end of the day, your answer will become very clear. It's something you're excited about and something that you kind of just need to push on, like you're going to go and take some classes and really dive into that. But I'm here to tell you you don't need to and you can bring a lot of value to a team without knowing how to code. Not that you shouldn't know how to code. Okay. So I've convinced you that you don't need to code, but what do you need? So without technical skills, what can you bring to a team? Kind of like we talked about a little bit earlier, that's really valuable. I can't stress enough I'd write it as many times as the line would let me. Communication, communication, communication. If I go all the way back to my background, like in school, writing, email, vocal, whatever types of communication is the key to being a product manager. One of the easiest metaphors I used when I started was I would tell people I'm like an air traffic controller. I stood in the middle and I told people where to go at what time and made sure that no one crashed. I made sure everyone had their, I guess you could say a flight attendant too if we're going with the airplane metaphor, but everyone had their seatbelts on and everyone had like their drinks and their food and everything was like perfectly aligned. And that's kind of what I did. And that takes really strong communication skills, especially if you're working with different types of people. A designer is a very different mind than an engineering mind. And you have to know how to speak to both different types of minds. I've had the fortune at three different companies of working with global teams, getting to travel around the world and work with internationals. And over communication from like a cultural perspective is super important. From a language perspective is super important. I am always erring on the side of over communicating because it's more important that people have everything they need than hiding things from people. It's my work style, but I think it's important, especially working at big tech companies to kind of overshare if you can to the best of your abilities. User experience, like I said, you are the representative for you're the elected representative for the constituent at hand, whether it's a B2B, B2C business, you are the eyes and ears for designers and engineers when it comes to understanding who they're building products for. You're getting, hopefully, getting to do research and talk to some of these people and understand what their goals are, understand what they're trying to do on the platform. They need that because they can't do that and be knee deep in code or knee deep in wireframes. They need to really have someone representative on the team of the people you're trying to build for. And finally, they need business strategy. They don't need someone with an MBA would be nice. I have no intentions of getting an MBA. I think it'd be really great, but I'm sure that everyone who has an MBA here or in the future would benefit from it, but you need just the business strategy. What is the larger context for what you're doing? One of the most motivating things at SoundCloud when we were building an ad product was, well, this is attached to a multi-million dollar deal. And so giving that business context and understanding of, well, we need to get this out June 1st because the movie, for that movie trailer ad that we just sold is coming out then, helps them really rationalize what they're doing and helps them really feel confident in the team. And then you kind of exchange that mutual trust as well. So communication, user experience, business strategy, much more, but those are kind of my three big points when I say you don't need tech, but you definitely need this. So this is where we get to play Choose Your Own Adventure because I have no idea where you guys are coming from. So where to start when I've never worked with engineers before? Has anyone never worked with an engineer before? That was me. I was that at AOL, if you remember. This is a really fun one because people think, oh, you just need to get that first experience working with someone. How do you do that? Check out project management. Project management and product management are very synonymous, but project management is usually a bit more admin focused and a bit more agile process oriented. It's a great way to kind of start somewhere, especially now if product management jobs will say you need some kind of product or engineering experience. Project management is a really great stepping stone to that. I always say hackathons. When I first started in product, I'm also very passionate about fashion, and there was a fashion hackathon in New York City, of course, a couple of years ago, and I was like, great. That's something to put on my resume. And again, as we talked about, product managers don't really have a craft. So I went to this hackathon and found a team of engineers and designers and kind of went with it and had a whole weekend experience. And it was another way for me to really interface and understand what engineers do on a day-to-day basis. That hackathon being on my resume got me an interview at Refinery29 because they're like, oh, so interesting that you're participating in hackathons and working with engineers in that capacity. So I would definitely recommend that as a stepping stone. And then finding a mentor. I can't stress this enough, whether you're mentoring someone or being mentored. It's a great way to kind of understand how people got to where they were offered to take someone out for coffee. Hey, can I have 15 minutes of your time? I'd love to swing by a coffee shop in your office and understand how you got to work with engineers. I'm trying to break into this as well. So it's a really great way to, a low-touch way to kind of engage with people who are in a position that you're trying to get to. Anyone interviewing for a product management role or soon? I've done it a lot, yeah? Okay, cool. Do your research and learn how to talk about your technical experience or lack thereof. I was really open and honest about this when I was interviewing at SoundCloud, which had a really strong engineering culture. I said, I don't have a technical background. And you can take me or lead me as I am. I'm open and excited to learning and kind of getting in that experience, but I'm not going to over promise you that I can code. There's a sense of fake until you make it as well, obviously, like, you know, kind of understanding some of the basic concepts, not the code itself. But it's really important you just kind of own what you don't know, rather than kind of just say, all right, I work with a million engineers, this and that. Be really honest and be really open when you're doing this experience and learn how to talk about the other assets that you bring to the table, and focusing on what you don't bring to the table. Because as we talked about, it doesn't have to be code that you bring to be valuable on a team. Is anyone just starting a new product job and they're working with a brand new team of engineers? That's literally me right now. I'm three months into a new job. Yeah, cool. This was really intimidating. I had been at a music streaming service at SoundCloud for two and a half years and I started at Spotify and I'm just like, oh, bigger company, maybe better engineers. This is so overwhelming. I had a team of like 10 to 15 engineers I'm working with now. Where do I start? And one of the biggest things I didn't do at SoundCloud that I did do at Spotify is understood and pulled someone aside and I said, let's go over the tech stack. You're going to draw it a couple of times and then I'm going to draw it a couple of times and I'm going to really understand how our systems work. Find your go-to person and really hammer home and learn materials for yourself. Some companies will have that and that's amazing but most companies won't have a packet of, here's everything you could ever need to know about these systems that you're going to be working with. So I can't stress enough, find that person, the gentle soul who will sit down with you and really talk about how everything is lined up. Find a person or find a place to ask questions. Someone recently suggested this to me and it was the best thing I did. Interview your team. So similar to mentors, find time 15, 20 minutes with each new engineer or with each engineer on your team or each person on your team and sit down and ask them, what do you expect from me as a product manager? What are you not getting right now? What are you looking for? What do you need? And kind of help engineers feel supported because at the end of the day, product teams are stronger when they're giving people the right kinds of things that will help them do their work better. So interview your teams and do not try and change things on day one. This goes for any new role. Do not step into a role and say, this is great but we're going to change everything tomorrow. And it's really hard. It was something that I had to bite my tongue on when I started at Spotify. At SoundCloud I was working in a really rigid agile two-week sprints. We estimate every story and we measure our velocity and we have a burn down rate and we know exactly when we're going to deliver and it's good. It's a great exercise and I don't knock it at all. I think it's really important. But I got to Spotify. There was no estimations. This is my team. So Spotify works in a squad by squad team basis and I can talk about that organization as well. But each squad, each team kind of organizes itself and its tools, its agile development in different ways. And so my squad does not use JIRA. It doesn't do estimations. It doesn't do any formal scoping exercises. And then I was like, this is crazy. How do you know what you're going to be able to do? How do you know when you're going to be able to deliver? I was in awe. So I sat down and I was ready down all my recommendations. I'm like, this is not going to work and this isn't going to work. This is crazy. I was ready to send it to my tech lead on the team and I bit my tongue and I'm really happy I did because there's nothing worse than someone coming in on their first day and saying, you got to change all this because something is obviously working for the team. Something's working in the right way. The hardest thing you can do in a new job is sit and watch and not say anything and take notes but really allow yourself the time to do that. It's really important. You'll really gain respect from the team by doing that. I got to say from personal recent experience, that's one of my biggest pieces of advice. And where to start when you need support? Join a product group. Like I said, we're at the product school. This is a great opportunity to connect with people and different organizations or whatever kind of thing but there's a lot of different groups today that really offer product support, really niche product support. I'm in a couple of women and product groups outside of the office, inside of the office. It's really great. There's so many different opportunities. We're in New York City, like Silicon Alley. There's so much here. It's a really exciting time to be here. So find a group and spend some time and really share your war stories. Connect. Go to a networking event. Come to an event like this on a really freezing night in New York City. Really put yourself out there and you'll get some value out of it, hopefully. In fact, when I was kind of thinking about this presentation and how I was going to organize this, because this question is always looming over as a product manager. Should I be more technical or not? I pulled the women in product slack groups. So there's a global slack group where you can join and get support on a local, global level women and product managers. And I was flooded with responses. I said, hey, you know, is anyone like me without a technical product experience? And it may be a testament to the camaraderie of the group, but I also think it's a testament to how many product managers are in this space without technical experience. So pulled out a couple themes. I know these aren't kind of small, but I, you know, underlined some things. So an editor at the Daily Beast turned product managers. So she was writing and she said, you know, I understand the needs of editors really well. I want to do product management. So you switched over. She said translating high level tech jargon to regular people speak is something that, you know, you really need to be able to understand. An analyst turned PM and ACL. You need to be an excellent communicator. Communication was super key for these two women who I reached out to. I think that this is the strength of non-tech PMs. We can expertly explain the what, but trust our dev team on the how. This is exactly the story that happened to me at SoundCloud. They're going to figure out how to do it, and I'm going to tell them why it's important and provide, you know, all the context and fill in the right gaps. That's from someone who went right into product management, similar to me at Indeed. She's pretty high up over there. Teams need to complement each other. So your weakness and technical abilities needs to be made up with the strength and other PM skills. So other value can bring, such as user research, data analytics. So business oriented, really thinking about the business strategy, marketing strategy, and something, some other kind of value beyond the technical value. This one I love, and I think she phrased this really well. I just own the fact that I don't have a technical background similar to what I did at SoundCloud. Thinking about user experience and being mindful of the universe of things is super important. Be creative, obsessing about and understanding your customers' problems. These are from a consultant turned a product manager at Pillpack and a marketing comms person similar to what I was doing turned PM at Clio. So really focusing on the user experience. Bring that user experience home and really be an advocate for your users, whether you're, you know, working at a legal tech company or, you know, a news company like the Daily Beast. So it was a wide range of experiences and I said, I had to be like, okay, I have a lot of responses already. I had to like put the kibosh on it. But I have to say the biggest blocker when getting into product management and kind of thinking about not having technical experience is you. You're the person who needs to kind of psych yourself up and feel confident going into interviews, going into a new team, walking into a room of engineers to go through a scoping meeting and feeling confident that you can talk and learn and follow along on that conversation. It may take a little bit more work than someone who has a computer science background, but it's not impossible. And it's something that you can really do if you commit to it and get past the back, get past the imposter syndrome that's so obvious to have if you don't have that background. Thanks guys. Do you have any questions? I think I ended right on time. Yeah. You mentioned about your experience at SoundCloud where you're managing all the technical, you know, to bring in that aspect. But how did you, I mean, sometimes when you're working with engineering teams you still, even though the engineering team wants something you still have to deal with the team. Yeah. You still get that resistance. How did you get over that? For me, it's really about building those one-on-one personal relationships with people. And that's something that I feel like is one of my strengths. I have a communication background. I'm a people person. And so for me, like, I can't walk into a room and just start speaking tech. But I can ask you if you want to go to coffee and reason with you and say, listen, this isn't one of my strengths. Would you be interested in spending a half hour with me once a week going through this to make sure I understand it correctly or just pinging someone on Slack? Hey, I know we just finished that meeting. I wrote up my notes. Does this make sense? And kind of validating on a one-on-one level because if you think about it as a big block of people, it's very intimidating. But if you reason and just think about how you build friendships or relationships, going one-on-one is a much more approachable way to do it. Yeah. Yeah. Yeah. So agile development is just a way and like a framework methodology really of doing software development. So the most basic example is like every two weeks we sit down and we decide what we're going to do and we size that work and we say what we're going to deliver. And then at the end, we see if we said yes or no, we delivered it or not. And we grade ourselves basically on that. In its most basic foundational capacity, like you've done that work. You have planned work. You have said, you've sat down with the team and said we're going to do this, X, Y, and Z. And we've committed to this. And then at the end, we said we did it and we didn't do it. So if you really break down agile, I know agile is like such a buzz word, but like if you break down the foundation and the framework of what it really is, it's committing to something and completing it. And I think for the most part, all of us have done that in some capacity, whether it's in like school or whether it's in a job. And I think it's okay to be open about, no, I haven't done this two-week sprint thing, but I've read a lot about it and I've learned how to commit to things and how to report on that. And I want to learn more about it. So I think you have to like broaden it a little bit by definition because if you stick to those buzz words and get really like zoned in and get tripped up on it, you just trip yourself up. But I think at its core, you've done that kind of work already. I think you have. I don't know you, but I think you have. Yeah. Yeah. Like the tribe mission. It's actually very similar. So I'll explain that. The first thing I would say, we don't really have a dedicated agile coach. We have a mission level agile. So let me answer the second question. So at Spotify, we have a research and development organization. It's split up into missions. So each mission has like a purpose. My mission is the creator mission. Within each mission, it sounds, the verbiage is so funny. Within each mission, there's tribes. So a tribe can be like 100, 150 people. Within a tribe, there are product areas or squads. So each squad has a trio of people, a product designer, engineer, as it's like trio and each at the squad level, at the tribe level, at the mission level, there's a trio that's responsible for delivering stuff. And so for me, because there was no, there's an agile coach at the mission level. So I didn't really interface with the agile coach. Although I did meet with the agile coach when I first started, just to get like a lay of the land, which I, if the company has that, I would definitely do that. So I went to my attack lead because he was the most, he was the closest person to the work and the closest person to our team's rituals and could give me the why we did this and why we decided to do things like that and how it got to be because a lot of times you need the historical context and then you're like, oh, that's why we don't use JIRA or that's why we do things on Wednesdays. You know, there's always a reason. So I think also getting the context rather than just throwing things over the wall, suggestions over the wall is really important too. Sorry, what was the second part? I don't know. I mean, yeah, my, it's like a couple hundred people for our mission, I would say. Yeah, it varies though. Still no three months in. So don't quote me. But yeah, that structure is copied at a lot of different companies too. It's a really interesting structure that gives you autonomy as a product owner to make decisions and move quickly. So you don't have to like wait for your manager to approve things. You can kind of just go, which is really great and exciting environment to work in. Yeah. I'm curious if you have any tips for finding companies that are open to non-technical teams. And you know, as I've sort of thought about bringing the product management, I want to find a company, you know, like Spotify or Google that has good training in place. But there's also like the concern that, you know, those rep people with great big tech companies may not want, may not be as open to people trying to break in. Yeah. So please, I'd love if you taught me where a good break-in entry point is. That's a really good question. I think, like I said earlier, I think project management is a really great way to, a great stepping stone. I also think it's a great career path. I don't want to say that it's like an entry level position to product because it's not, it's certainly its own thing. But I think you can learn a lot about product by being in a project management role, which is really cool. I think when you're interviewing, you know, I think it's important to ask those questions and be honest about your experience and say, you know, I don't have a technical experience. What is the training like here? What is, you know, the capacity for you to mentor me and really teach me some of these things if I don't have that experience? My time at Rolling Stone, I would say was probably like the most equivalent of them not really understanding what a product manager was. So I was one of two product managers on like a digital team of like 50 people and they didn't really understand it. And so it was really hard, but it was also kind of fun because I got to learn on the job and make it what it was on my own. So that's another way to do it, like a company that's not super technical that's trying to understand digital is an interesting way to get in there as well. But if you're really trying to learn product, I would try and stick, I guess, with the tech company and be open to different kinds of roles. I would say that so many product managers at SoundCloud and at Spotify transition from other roles into product management. So don't close yourself off to a product marketing role or a customer support role. I'm trying to think of other teams, but we had so many people just shift over into product management. It's always easier to transition, especially if they need that technical experience. Sorry, not technical. If they need that product experience to kind of come in as a transfer rather than like a new hire. So that's another way. If you're open to starting with something else and then saying, you know, I'm interested in this path, is there an opportunity for that in this company? Yeah. I have a good question. Yeah. Why can that be said with sound checks? So what are the best practices for user interviews and user video testing? And how do you make sure that the sample size of the customers that they are interfacing with is enough? Because I, as a product manager, you know, it's 50 enough, it's 30 enough, it's 100 enough. Yeah. Yeah. I mean, it really depends. So I can't talk too much about the product I'm working on now, but it's something we're experimenting with. So it's a really small group because it's not very big. I think depending upon the scale and the size of your actual user base, you can base it on that. It also depends like at the stage if you're exploring versus if you're just doing like play and usability testing. I'm trying to think like my time at AOL, we were testing like an AOL TV mobile concept like would people use their phone as a second screen and like play games while watching TV. It was one of like the best user research experiences I've ever had. We spent months designing something. We get in the room, we get behind the wall, they can't see it. They're like, this is so stupid. Like we hate this app. This is crazy. And I was like, oh my God, we've been spending months on this. But I think, I don't know. I mean, that was like, we did like three groups of like 30 people like testing like, you know, testing a concept. We really, we work with research teams to kind of help form those groups. I've been really fortunate at AOL and then it Spotify to work with a UX research team, UX researcher to kind of organize all that stuff. There is a tool that I used at Rolling Stone that we did AB testing on. I would always say if you don't have that support of a research team, there's many different companies. The name of it is slipping me right now, but you can kind of do on the fly AB testing that's a little bit more scalable if you have a major user base. So it really just depends if you're in exploratory mode, if you're in usability mode, AB testing is a really quick scalable way to get results, sound checks and in-person interviews. If you're doing exploratory or if you want more qualitative feedback. Yeah. When you create scopes, how do you know like when to stop creating your scope? Because that's like a problem that I have. Like I'll start something. I'll be like, here we go. Here's this idea. This is what I need to do. And then I'll be like, okay, this is what I need to do. Each of those things. And the next thing, you know, I have like this massive tree. Right. Every single last detail. And I'm just like, well, why didn't I just do it then? So like, where do you stop with your scopes? It's a really big question. So are you familiar with like the concept of MVP minimal viable product? A lot of times. And I can really relate to this because when you're building a product, you kind of want all the bells and whistles. You want everything to be perfect. And, you know, you want it to be the best product that it can be. But many times you don't really need all the bells and whistles. I meant like on how something works. Okay. If you were to go like, how does this laptop work? One simple thing is like, it's clamshell thing. There's a screen here and there's keyboard there. But then what if I started to dissect things like, like writing product requirements. So that really just, yeah, I understand what you're saying. So that really depends on the team. So I used to do things called PDRs, like writing product requirements, like literal books of requirements on like writing this button clicks like this. It turns blue on hover. It turns gray. And I'm like, this is crazy. But some teams, depending upon if you're working in a waterfall environment need that because in many cases, engineers are out of house. You're working with an agency and they kind of need everything there. So in cases where you're working with remote or out of house engineering teams, I would say, err on the side of more detail. If you're working with in-house teams and you're collaborating on a daily basis, or if you're working with a great designer who can do prototypes and save you the trouble of writing out product requirements, less scope is usually easier. So for me, it really depends on the team that you have. So if you have people here, you can show, ask them, what do you need for me in order to build this? I think that's kind of your best starting point, rather than trying to guess and drive yourself crazy because I've done that too. I'm like, how detailed do I need to describe? How thin is this line? How, you know, like stuff like that is insane. From the design side, a lot of the wireframe software, like Sketch, or no durability experience, like you don't have, like, the hover animation things. Like, how do you usually annotate those things if you do want to put them? Like do you usually put some sort of caption or just... Yeah, I would usually caption it. I don't do a lot of wireframing anymore because I work with a designer who does just high fidelity, like she'll do straight high fidelity designs. But if you're doing that, like captioning is usually fine. I would say if you're working with any kind of designer, just, or engineer, say what is the easiest way for you to go because at the end of the day, they're the one who's going to be reading it. They're going to be the one who's really having to figure out what you're saying. So make it about what they need.