 Great hi everyone. Welcome to this week's product school talk. I'm Cassandra really excited to have all of you here with us today As you know, we teach product management courses coding and data at our now 14 campuses Today, we have a very special guest with us. She's been in product management for quite some time now So I'd like to welcome joy garen former product manager at AT&T. Hi joy. How are you doing today? Hi? I'm doing well How are you? Great. Thank you and thanks for being here with us No problem If you want and I'd love for you to take a second to go over your background And I know you just recently got into a new role in product management. So I'd love to for you to tell everybody about that Great. So just to give a brief overview of my background in product management So I started off in my first kind of official product management role at AT&T Working on our ATT net property, which was a really interesting partnership between AT&T and Yahoo at the time Where a lot of the revenue was driven off of search and advertising revenue And then from there I moved into product management at career builder where I was most recently I started off working on job search So more of a backend product that served a lot of different customers and moved from there into a role Supporting our growth marketing SEO digital marketing efforts and then also looking at how we could leverage our Market data to provide better information and insights around salary and skills and all of those sorts of things And most recently I just moved into a new role at Park Mobile here in Atlanta And Park Mobile is a mobile payments provider for lots of different venues and on street parking So really excited to be starting that new role as well Awesome and congratulations on the new role So I know you have a presentation prepared for us today So I'll give you a couple seconds to set that up And guys while she's setting that up. I'm just a quick reminder We're going to take questions following her presentation So you're welcome to type in your questions in the comment section on Facebook and we'll get to those right when she's finished All right, so I hope everybody is able to see my screen. I'm going to go ahead and go into presentation mode Because Sandra does everything look okay on your side. It looks great. Okay fantastic. Thank you So I wanted to talk a little bit today just from an informal perspective about delivering value for products and To talk a little bit about what that means to me. So as a new product manager Come when I first started I think you read a lot of information about what product management ideally should look like And kind of all of the different frameworks and considerations and different things that you should be thinking about in order to really be an effective And and great product manager, but I think that the real world sometimes presents opportunities that and situations that are a little bit different And you have a lot of different stakeholders often who all have valid Concerns and different features that they need added and things that are important and it's really difficult sometimes to prioritize and you have to figure out What is your true north and what's your north star? What's the most important metric that you're really trying to drive and stay clear about that Even though sometimes it's hard with a lot of different people who are who need things from the product and who are looking to have their work prioritize So to start off the first thing that I wanted to talk about was this pragmatic marketing framework So I don't know if all of you have seen this before but it's something that I've used quite a bit In my time as a product manager and as I continue to grow as a product manager to really try to quit into context What are all of the things that I need to be thinking about and where my stakeholders may be coming from and what they're thinking about So if you look here it ranges from strategic to strategic to tactical and there are a lot of different columns here that really highlight a lot of those different concerns So if you're looking at strategy there's different concerns versus the technical sides and things coming from marketing and sales And even in a product management role sometimes depending on the type of organization you're in or the type of product that you're working on You may find that sometimes the work that you do day to day may be more leaning toward one of these areas And sometimes it may encompass all of them So it really just depends on the situation, the customers you're serving, kind of the nature of the product partnership Any partnerships that you may be managing as well as part of your product roadmap So I wanted to kind of place this here just as something to think about and as a good reference point to go back to So from here I want to give a couple of examples of situations that I have found myself in where different organizations and different products Have really provided an opportunity for there to be a few challenges for me trying to figure out what's my North Star and where should I be focused in order to really deliver value for the product and to the users and also to the business So case one here is a white label portal. So this is kind of an illustration of the product that I worked on, the type of product that I worked on when I was at AT&T So we were partner A and partner B you could say was who we were working with and our key revenue driver was search and display ads We had five and a half weekly user, five and a half million weekly users that were looking for relevant personalized content They were looking to easily and effectively manage their accounts and manage their email communications as easily and simply as possible So that's a pretty clear need is the list of needs from our users. But if you're looking at partner A which represented my side of the product Some of the things that we were looking to accomplish and that really were guiding my true North were to increase visits and searches per user We wanted to promote our own licensed and original content and also advertise core products and promotions But the partner that we were working with also had their own set of performance indicators and objectives that they were looking to achieve as well So we were aligned on the first one. They also were looking to increase visits and searches per user, but then they also had unique content for their articles and videos that they wanted to drive more views to because there were advertisements there that they were looking to get more views for And then also they were looking to drive sign ups and downloads for their own sets of products as well. Now, just to give an example of why this particular case I wanted to call attention to it is because It was a little bit nontraditional I think that often you know we think of product managers as the people who you may be sitting with your engineers and your developers but in this case the partner actually owned all of the technical resources And I was really if you look at that framework more responsible for the strategic part of managing the product. And so I needed to understand the differences between my users and their users, even though the product was a white label you know we needed to figure out how do we customize to meet our user needs you know their users were a little younger our users are a little older So how does that affect the user experience and what we need to provide. Additionally, we had a lot of partnerships as we're looking at promoting our licensed and original content so our licensing deals might have been different than licensing deals that they had, and our content providers may have had rules around, you know where we can display this information or the data, the content that they had given us, whether it was able to be displayed with our partner and all of these different things. And so I wanted to point this out because as you're thinking about how do you deliver value for the product. These are some of the things that you may run into that you have to navigate depending on how that product and the business around it is structured. So to move to another example here. Case two was marketplace search so this is an illustration of the types of issues that we ran into at my time at career builder so working on a back end search product that really served a two sided marketplace. Really looking at. First of all, you know we have to serve our clients who pay us they are key revenue driver so client advertising fees are really the driver that keeps us keeps this product in business. Be aware of the fact that our clients need to feel like they were getting value from really advertising on our search or on our website. But at the same time, our users also had particular needs so to talk about the client needs their needs were around like optimizing ranking, you know all of our clients who advertise with us want to show up first for any particular keywords so just like in a Google search we'll think about SEO. If you're, you know, if your product or your organization, your company that you're working for has search as a major component and that's how users find products or find information, then optimizing ranking and SEO is going to be a big deal internally for your site as well. So those were some of the things that our clients were looking at they also were interested in how do they increase the number of relevant applicants that they got her posting. And then also we had some white label clients who were very concerned about customizations and how they could really meet the needs of their users. So on the back end for search. We had to be thinking about not only the search performance and relevance for our own site, but also for white labels and the different needs that they had for their users so in this case you know for the white labels we would be very similar to the partner that I explained us to be working with in my last example. Also looking at you know the stakeholders from engineering who are also very focused on maintaining and upgrading the back end, you know, oftentimes if you're working with more technical products. Technical debt is created. You know there are upgrades that need to occur patches, lots, lots of things that need to happen on the infrastructure side. In order to support and continue to make the product run and if you don't take care of those things and ultimately you'll run into performance issues so those are some things that you have to balance when you're looking at the roadmap as well. And then lastly, thinking about, you know, sales, you know if anything went wrong or if a client was dissatisfied. You know we heard about it often from sales, and their objective was really to drive renewals. You know, and obviously our users they're just looking for relevant and personalized postings, and the ability to filter and, and, and, you know, eliminate information that's not relevant to them. You know our algorithm doesn't get it right. So there were a lot of different stakeholders and almost masters that we needed to please as a part of managing this particular product as well. So I showed you those two cases to really kind of move into this next part of the discussion which is really about, you know, how do you actually define success defining success is really the key to how you navigate all of these different combinations of challenges or situations that you'll find as you journey through product management, having a clear north star and really being able to say okay, you know what are the, the business that are going to be most important that are going to not only say that okay we released on time or we pushed a new feature, but we actually added value to the bottom line. You know we drove more users to the site and those users transacted in a way that we wanted them to, or they came back how we wanted them to, and you know those are the things that you really have to ask yourself and get clear on. So how do you do that. The main way that I would say that you really find your north star and can really define success in a powerful way is by asking the right questions and also asking the hard questions. So for yourself kind of every day or you know, or whatever cadence you think about it you need to really be clear about do I know what my users want today, you know, a lot of times product managers and organizations will find themselves in the place of saying, we did a lot of research two years ago. So we already know what our users want, but in today's economy I mean the market is changing so quickly, particularly with technology products that understanding and knowing what your users want is an ongoing discovery process and you need to always be talking with them always be creating feedback, you know, really understanding their behaviors both through looking at the data, but also through qualitative research as well, and you know understanding their buying behaviors and who's contributing to the bottom line. Secondly, do I really understand what drives my business. You know as a product manager, it's very important not only to understand your product that you're managing, but also kind of the broader business, and you know what's driving that what's important to your users, and what's really going to, you know, move your company forward, but also your product obviously you need to understand, you know, is it more important for me to get new new visitors or new users, or is it more important for me to increase the number of transactions or, you know, the users that are already had, and then those things may shift as you go along. You know you may be trying to acquire new users up to a certain point, and then your strategy will change so really asking yourself, do I understand what's driving your business today. And then lastly, what percentage of my roadmap is delivering value to users versus accomplishing other goals. I think this is always a very delicate balance and something that we have to always be thinking about. You know, sometimes, like I said when you're getting a lot of requests. You know, really, you know, you may look up and everybody, you know, your CEO or or your VP of product, you know, there may be top down direction that's coming to you that says we need to do these things. You know, and you look up and your roadmap is filled with things that don't necessarily contribute to value for the product, and they're not driving what your users want, or your, your business value either. The questions that you need to be asking your leaders when those sorts of directional directives are coming to you is, does the work that you're asking me to prioritize a line with the measures of success that we've defined. And if there's a pause there and everybody in the room realizes that we're not all on the same page about the measures of success that we define, then that's a problem and you need to keep asking questions. You know, I think that this is probably one of the hardest things for product organizations to do sometimes depending on your environment is to really, you know, take the time to lock down the strategy and say what are we actually trying to accomplish here. And then lastly, you know, if you're getting requests from sales and finance, or you know, for instance, if there's a partner who's asking for a particular feature, you need to understand how does this request affect the bottom line. Because sometimes what you'll find is, you know, you have a partner who everyone believes is a huge part of your business. But if you actually sometimes look at the sales numbers, or look at what they're paying you every month. What they're contributing to the bottom line may actually be quite different than the assumptions that everyone is making based on historical information. The reality may be quite different. So asking the right questions and really understanding your business understanding the numbers behind your business and all of those different things is very important. And then lastly, as you're asking these questions, knowing where to find the answers. The best thing about product that I love is that you get to partner with so many different organizations and teams and stakeholders around the business. And all of them actually have the answers that you'll probably be looking for. So, you know, your user experience partners are key. And for me, I found them to be extremely valuable and helping me to not only understand, you know, the design which sometimes I think is what a lot of people think of when they think of UX, but they really are very helpful by giving voice to the data that you're seeing in your analytics and tracking by supplementing it with qualitative feedback and then translating those insights into design features, which they are experts at doing, you know, if the data and if the qualitative feedback is telling you that a user needs a certain thing they're trained and really turning that into an experience or flow that will optimize that user behavior in the way you want. And customer care, for instance, you know, and account managers, they really provide valuable insights about user requests and functionality issues. So, you know, they're able to answer different questions. I would say, you know, sales can help you understand the actual value value of client accounts which is what we mentioned a little while ago, and marketing can also help you understand things like which user segments are really driving your growth, which user segments are really driving your revenue. And then those things can help you make the decisions to say like okay this is what we should really be defining a success. These are the segments of users that are really where we found product market fit and all of these different things. So, in my opinion, you know, looking around at your partners and really keeping those relationships strong and not being afraid to ask the questions to them and bring them into the process as a product manager. The great thing is you don't have to have all the answers. So just knowing where to go to find the answers and being able to partner and collaborate across the business in order to translate all of the information you get back into a great and successful product is really what what the objective is. So I know that we are, that's the end of the presentation I've prepared. And I have, I don't know if I'm still sharing but there's a bio and some information about me and where I work my contact information is there and my LinkedIn. If you have any questions or like to talk further. Thank you so much joy thanks for a great presentation as well. A few people were asking for the slides so the slides are available guys will show them on the link that that we provided in the in the comments so you'll be able to find them there. Thank you again joy. So, let's check and see if we have some questions coming in here. And also, one thing I would love for you to talk a little bit more about is, I know you mentioned working well with the team and being able to, you know, ask the right questions and communicate well. What's some advice that you would have for handling conflict among a team, for example your UX or engineers or customer service. I think that for me what has worked best in terms of managing conflict. I like robust discussion and conversation so I never really try to look at things as conflict. What I try to minimize as a product manager is ego. I think that sometimes, you know, we may find that, you know, there's conflict around, you know, who has decision rights or, you know, someone thinks they have the right idea and someone else has, you know, information that's different and so it becomes conflict about what's the right decision to make. I'm always looking for consensus so I think that really being a consensus builder is extremely powerful as a skill for a product manager because when you recognize that the people around you aren't necessarily competing with you for power at least this is the way I like to look at it. They're experts in their own right and you're all trying to make this product as great as possible so you'll all like sink or swim together. That's really the optimal way to do it. I bring my engineers, you know, my UX partners, you know, whomever is valuable and has information that's relevant I try to bring them into the conversation and then we look for consensus. Awesome. Really great advice. Great. We had another question come in through Slack. Can you share what what some of your favorite books are that you that you've been reading lately. You know, the interesting thing is, one of the books I've been reading, which I'm sure is a really popular book is called hooked. I've been making my way through that one I think that's, you know, everyone is looking for what's the way to, you know, drive repeat visits and repeat uses. Those sorts of things. How do you hook a user. But one of the things that I've been doing a lot from a leadership perspective which you know, also, you know, as a product manager we have to do. I've been watching a lot of documentaries on diplomats and presidents actually people who have to really manage a product if you will I look at everything as product management I'm always looking for insights about how to work with people. How to understand the needs of, you know, whether it's a group of people or users or whatever it is, and then, you know, working with lots of people to kind of move, move forward and provide value so that's what I've been doing to kind of advance myself in that area lately. Yeah. No, that's awesome and we always say to be a lifelong learner as a product manager that's that's how it goes. So awesome. Great. And then we have another question here from Gloria and in your view should we prioritize tasks related to users over the business or the other way around. It's situational so I think that you should have a roadmap and a vision, like to start off with, you know, for where you're where you want to take your product and you know what's going to be important to your users you know your roadmap should should look at those things. And then I think that as things from the business come up. I think you have to look at you know how important are they, you know what are going to be the impacts, if you don't deliver those things within a given time, and then you try to make, you know the right decisions based on that. I think that, you know, oftentimes those decisions are dynamic. So, I would say though, your roadmap should be driven and your vision should be driven for what the value of the product provides to the user in my opinion. And then from there you look at what you know what what the needs of the business are and usually things will start to line up and make sense because your business values should ultimately, you know, align with kind of what your users are looking for to Right, right. Exactly. Here we had another question come through this is from Siddharth. What are the best practices and prioritizing your product backlog. How do you prioritize which user story should go in the backlog. And how do you deal with unfinished and overestimated user stories. So there are a couple questions there. Yeah, these are good questions. So I would say in terms of prioritizing the backlog. What I often try to look at is, I would say like yesterday at work we had this come up so we have a product, you know, a set of features that we need to deliver on. And the one of the things that we asked ourselves are, you know, do all of these things have to go at the same time. You know, do they need to all be packaged together. In that case, then you might, you know, prioritize them in terms of, okay, what do we need to know first before we do the next things So if there are, you know, dependencies, or if there are certain things that are going to be roadblocks then we would prioritize those in a particular way. In terms of overestimating or underestimating. We try to be really realistic about, you know, our capacity, and also, you know, if we don't if we really don't know. If we don't have enough to make a solid estimation, you know, I would say always be comfortable with putting in a spike card. So if you need to gather more information and, you know, just so I'm not being jargony so a spike card is, you know, a card that you can put in so that your team has time to go and So that they understand a little bit better like what is what's going to be required to even do this work. And so when you're grooming and you don't necessarily know yet I would say, you know, feel really comfortable with putting in a spike card so that you can learn before you actually estimate the work and then, you know, you won't have to deal with. Oh, we gave it a five but it was really like a nine or an eight. You know, and then you're stuck so yeah. Awesome. Here we have time for one may. Yeah, maybe one more question so this one is for and from Andrew said thank you for your talk joy. I was wondering how you've communicated value when addressing technical debt, particularly when it's conflicting with working on new user features. To be honest, in my experience that has been an ongoing challenge, you know, and organizations is really, you know, I feel like sometimes that has to do with organizational culture. I've been in organizations where the culture or the leadership is less technical and so the understanding of the value of taking care of technical debt or prioritizing technical debt isn't there and and so sometimes you have to really kind of fight those battles and and advocate and, you know, ultimately, you own the roadmap so you know, sometimes you know you may have to disagree and do what you know is best for the product. And, and you know that can be a little scary and challenging sometimes, but but it's also like a good way to stretch yourself and grow to. I would say in organizations that are more technical, you know when I was working on search, people understood the value a little bit more of like okay the search engine has to work so you know, there was support for, you know, tackling technical debt in whatever way, you know, you find best to do it. Sometimes we would do tech debt sprints, which I don't know is the the greatest way to do it you know some there's agreement and disagreement on both sides about how you manage that but there was at least support for taking that on but you know if you if you build it in or you know just yeah I think it's just a cultural fit organizations different organizations handle it differently. Okay, great. Well thanks for thanks for taking the time to get those questions answered. Before, before we finish, could you share your advice for aspiring products managers. So I'll share it quickly. My background is not an engineering it's not. I was a music major in college and yeah, and then I went and got an MBA but I have always been interested in coding I started coding in middle school and freelance in college and other things like that. I would say just, you know, don't be afraid to really learn, you know, did like learn and dig into some of the more technical details. A lot of what has I think helped me is my ability to communicate with developers and, you know, really convince people that I understand, you know, the domain or technology, even though it's not as obvious. On my resume. So I think that anything that you can do to really kind of learn about different technologies, and not just at a surface level but understanding kind of what makes them work, not saying you have to be able to go out there and build it. But yeah I think that those are the things that are really important, and then also just being able to understand markets understanding the business understanding the numbers. You know really being able to analyze data. Those are the things that to me I have found to be extremely valuable and increasingly valuable I think people want to know that product managers are comfortable with large amounts of data and and the ability to really work with those engineers and and leverage that data to make a better product. Definitely great advice to it is it is good to have some kind of ability to communicate with your team and understanding of what what they're doing, essentially. So great thank you so much joy really appreciate it was a great presentation and thanks for getting to all those questions. Of course thank you guys I appreciate the time and hopefully it was helpful. It was great. And thanks to everybody who joined today. Guys if you type book in the comments you'll get a free copy of the product book just for joining us today. And of course you can find more about us at product school calm so thanks so much for every, everyone being here today and have a great rest of your days. Bye.