Think Like a Product Manager: Straightforward frameworks... by Eleanor Stribling

Speaker 1: Hi everyone, my name is Eleanor, she mentioned. And my talk today is really intended to be some things that you can take away with you to your job on Wednesday or whenever you leave here. Sort of think of it as product management in a box And what I've tried to do is take some frameworks I learned in business school and condense them down into very sort of product-specific things. So I'm hoping by the end of this talk that you'll have a few things you can take home with you So to introduce myself, my name is Eleanor. I've in my eighth year as a PM, I've been in the tech industry for more like 12 at this point. In the San Francisco Bay Area mostly. I've been both a manager of PMs and an individual contributor PMs, so kind of had both of those experiences.

Speaker 1: I've worked in companies of 10 people and 100,000 people, so and some things in between. So I've I think that what I'm going to show you today is applicable in a lot of different environments. I've also worked on a lot of different different kinds of products. So I've worked on ad tech products, on HR analytics products, on customer experience products, pretty broad range and this still works. So if you work in software, I think there's probably something for everybody here. I've also been on this stage before. I spoke at DjangoCon in 2016 and 2018, both on technical topics, on side projects I was doing with natural language processing, and my first one was, my very first one was about user So it's pretty exciting to be talking about my day job for a change.

Speaker 1: So who is this talk for? So the genesis of this talk was actually when you don't have a product manager. And the reason I say that is I have engineers come up to me every so often and say, I don't have a product manager for this interim. internal tool or for this this very like super back end technical project that has to do with you know like replatforming the whole application or something like that. But I want to I want to understand what it is you do so I can kind of get in the important parts. So that's what I was trying to do with this. But I would recommend having a product manager because fun story, I became a product manager because a bunch of inside built something that we couldn't sell, so I went and fixed it. So I recommend having a product manager wherever you can. If you need to support a product manager, so oftentimes you We've seen how we are, we're frazzled, we're haggard, we're in a thousand meetings.

Speaker 1: If you need to help somebody, and definitely I've fallen to this category before, you need to help someone, hopefully you'll find some good fodder for that too. Or if you want to be a product manager I mean, I'm not sure why, but you ca if you're in engineering, I think it's a pretty good gig. But um if if you do want to transition to product management, um some of what I'm gonna show you is actually probably pretty useful for interviews and sort of getting yourself in that mindset. set. And then finally, if you have an interest in developing product management skills in your current role, sort of how it's useful for me to have written code before and done a little bit of design because I kind of had to, even though I was terrible at it. it is helpful for you, I think, to as an engineer to understand what's what's going on in our world. And what I've tried to do here is focus on things that go on in our world that you don't necessarily see or see all the time

Speaker 1: So this isn't a talk about how we write a spec because you've probably seen us write a spec and you've worked with us in writing a spec. It's all that other stuff that takes place sort of away from design and engineering that I'm going to really focus on today So here's what product management is to me and the way I'm going to focus this talk. Again, this isn't a talk about writing good specs or you know how to fill in for your product manager doing that. To me, product management is really about building a vision around what customers need, what the market needs, whether they know it or not, figure out what that vision is, rallying the organization behind that vision, and then finding a path to value. So basically you have to build stuff that makes sense that people will buy. And that's that's a lot harder than it than it might look.

Speaker 1: sometimes. So what we'll cover today, originally I was going to shape this talk around parts of the life cycle, but as I was writing it I realized that that isn't necessarily that helpful. And actually the most useful frameworks are useful at all of these different points. So and these I mentioned these not because this is the whole life cycle, but could but because this is where I've seen us really screw things up. So I think these are the places where you should pay attention. Developing a new product, cutting scope, that's a big one, launching and then evaluating what you just So as we go through the talk, keep in mind like those parts of the cycle as useful moments to come either do these things or come back to them. So I'm going to cover three things, and I'm going to give you framings for each, which is, I'll be honest, like sort of like a table that you can fill in.

Speaker 1: So keeping it product manager in a box. keeping it really straightforward so this is something you can take and use pretty easily. But there are three things customer value, containing complexity, and balancing time and opportunity. So let's talk about customer value because I think that this is this is somewhat misunderstood from a PM perspective by engineers and designers. designers. So from a designer perspective, usually it's I'm definitely not paying enough attention to it, I'm not spending enough time on research, and generally I'm making them go too fast. But for engineers, you probably see little bits and pieces of this come through. So I want to show you a couple of things that you can use in this part of the process to refer to, especially if you don't have a PM.

Speaker 1: So I use this quote because I think that this really captures what you need to think about if you're trying to replicate product management work somewhere. And I've highlighted these parts myself, but the desire to make someone's life easier or simpler and give them what they need. So just keep thinking of that. Easier or simpler and give them what they need. need. So that means not it would be cool if we had this thing, right? So to I always have to ground myself in that because I'm one of those PMs who knows enough to be a little bit dangerous. with this stuff. So the way that we often talk about this is through something called an empathy map. And I've got three examples here. So I think I'm going to preface all of this with I think empathy maps are a little bit misunderstood. Because I I want to empathize with customers and a lot of the time my role is to understand what customers need and to convey that to the organization.

Speaker 1: I don't need to know everything about them though to do that. I think for design having that context is much more more important than it actually is for me. So I'm going to show you three examples of empathy maps and talk about each one a little bit. So the first one is I'd say a pretty traditional one. And the whole idea with these things is you work with a user and you talk to them. Hopefully you watch them use your product. And then when they've done that, you as you're as they're doing it, as you talk to them to them later you record their feedback in these boxes so what they say as they're using it what they think what they do what they feel makes sense right and then you take this away and then figure out what product to build The middle one is Peter Bogue's update of this. And as you can see, some of it maps pretty clearly, right?

Speaker 1: Like you've got fields and feelings. That's you know, simple. Does and tasks, those match up, but then it gets a little bit different. So influences, I think, is a really interesting one So influences is about other factors that are affecting your user. So I think that's really interesting because it makes you think beyond your own. own product, right? So I think that's a great addition. And then you've got at the very bottom, which these are the parts that I really like personally as the product manager, overall goal, which you see there on the right, which is what are they trying to do? Which I think the first one is missing, right? Like what are they overall trying to do, not the task, but what what's what are they trying to accomplish? And then the last one, which is absolutely my favorite, spoiler for this section of the talk, is pain points.

Speaker 1: So why is this hard for them? Why why is this not necessarily physically painful, although I suppose it could be, right? But why is this emotionally painful? Why is this frustrating? Why why is this unpleasant for the person doing it. And it could be something about your product that's unpleasant or it could be something about the role, the job that they're working on. And the final one, all the way there on the right, is my personal favorite. So this one is a little bit different. It's You can find it on a website called strategizer. com, which is actually great if you're doing business plans and stuff like that, if you're starting your own your own company. We had a presentation about that earlier. If you're doing that kind of work, they've got a lot of great templates. I really like this one though because it highlights to me as a PM the three most important things. And that's on the far end, what are the jobs?

Speaker 1: What are they trying to do? On the top, what are the gains? What makes them feel good about this? What are the benefits of doing this thing? And then on the bottom, the pains. So why do I like this so much? Well first of all it appeals to my PM soul because it's pretty straightforward. It's short, it has lots of bullet points. I like all those things. But I think that it really captures the three most important things to me when I'm trying to evaluate what to do Because remember a lot of what PMs do is about setting priority and saying, no, we're not working on this thing now, we're going to work on this other project, and everyone yells at you and hates your decisions. That's most of the job. But the reason I like it is this. It speaks a lot to what you can sell, what people are really going to care about. And

Speaker 1: way back when I first started working in tech in Boston, I had this boss who's the general manager of our business unit. He was really good in sales. Like he could sell anything. I swear to God, this guy was amazing. And I asked him, how are you so good at like what do you do to sell this?

Speaker 2: Oh, yeah,

Speaker 1: So and his answer I'll just yell for a second. His answer was um that there are really two things you can sell people. You can sell them vitamins or you can sell them eating. And these are your vitamins. These are the things that make you feel good and awesome and are great to have. But the painkillers are the things that look at the sale. Painkillers are things that are immediate and urgent and that hurt. And if you think about how you buy products and services in your own life, that probably speaks to you, right? Like you want to solve for pain. You want to solve for things that are hurting you, that are heal urgent. So those are the products that you can always sell.

Speaker 1: And so sometimes you can reposition a product to address pain and do it successfully, but it's a lot easier on your sales team, which is definitely a stakeholder for me. Thank you That was amazing, I just want to say. Um So that is a really important stakeholder group if you want to sell stuff. So always think about pain. If you take nothing else from this this talk, think about customer pain and how you can solve it. So containing complexity. So this is a really tough one, I think, actually. And I struggled a little bit, because I think it's a really important aspect of product management that I don't think a lot of engineers and designers see that much of. frankly.

Speaker 1: But it's really hard to kind of contain it all in one single framework, but I try. So I love this quote from Deep. I'm not sure if if uh the speech of a diplomat part was was how deep intended this, but I'm going to run with that because it really did speak to me for this. section. So much of this role is making sure the rest of the organization is on board with what you're going to do. Because you cannot launch a product just as a product team unless you're in a tiny company in that like 10 person company. we could totally do it. But in a bigger company, you need all kinds of people. You need sales who I've already talked about. We need the advocacy team, the support team. They need to be on board, we have to get marketing on board. We have to get um all of these supporting organizations that will fix the bugs, SRE, like all of these people need to be in a

Speaker 1: agreement. And that's really challenging. So I was thinking about how did I do this at first? Because when I first became a PM, as I mentioned, it was because I was sort of fixed fixing something that had already been built and it was basically because I complained about it a lot, so they were like, you can be a PM now. Um That's how you get the job. And yeah, so I thought a lot about how I did it, and I realized I went back to my business school time quite a bit, and I used the b the balance scorecard. So the balance scorecard has been kind of maligned in the last while, but I think there's some good stuff we can pull out of it. The idea of it was that the big fancy expensive consulting firm space We go into these companies and tell them what they were doing wrong and how to fix it and how to measure it. And they'd use this

Speaker 1: framework to do that. I think it was smallline not so much because it isn't useful, but because the consulting company sometimes didn't come back and uh explain you know what the results meant or decide what to do. So it's kind of gotten a bad rap, but I actually think it's pretty useful. So it's got these four sections, customer perspective, innovation learning perspective. internal business perspective and financial perspective. And the idea is you sit down as a management team and you're dealing with some like big like existential question for your your gigantic company with its consulting firm and you would go through each one of these and pick out goals and measures. So my my favorite one from financial perspective is survive is the goal and the measure is capital. Cash flow. So we're not going to quite do that for product. So let me start with customer perspective because that's where we kind of came from, right?

Speaker 1: We were talking about customer pain. For me, what this really means for product is how does this address customer pain? it all kind of comes together there. And then for innovation learning perspective, to me this is really about how can this product move the whole business forward. I think this is something even PM's don't think about enough. We get so like kind of intensely like we love our products, we really want to deliver stuff for users, but what does this mean for the company? I think that that's a really important question. And then internal business perspective. Why does the rest of the organization need to care about this? Why should they care about this? And you might say, well, that's answered by the how that moves the business forward. And that's actually that's not really true. Some cases it does, but in other cases it's like they've got more immediate concerns, like what is this great product that's gonna

Speaker 1: revolutionize the business? What does this mean for my team? I actually shipped something where it had a a product that had a ton to do with billing. And one of my biggest mistakes of my career was I did not talk to the billing team. I didn't sell it to them. We we launched it. It was awesome. But then they came to me and said you've really effed us over because we we're working like 80 hour weeks now because of your your product. So don't don't skip the billing team. I guess this is my my big advice there. And then financial perspective, what does growth look like and how does this product help? So I think this is another thing sometimes So we skip over a little bit and we're like, oh, you know, we can use these resources, build this thing, but how does this contribute to the bottom line is a really important question for PMs that we're definitely asked to answer. frequently.

Speaker 1: We have to worry about things like costs and an actual revenue that comes out of these projects, or you know, does it prevent something like churn? We need to be able to answer that question. So you might be asking, how does this have to what does this have to do with containing complexity? Basically, if you don't figure this stuff out and you start a project, it can die just because people don't get And not because they don't care or they're not as smart as you or whatever, it's because you haven't clearly articulated it. And if you start with this stuff, it makes it a whole lot. lot easier. But we can actually like narrow this down even a little bit more because remember I wanted to keep it simple. PM in a box. There are a couple areas that overlap. So one here is really communicating to P So we've got customer pain and why should the rest of the organization engage on that one diagonal.

Speaker 1: And then on this other diagonal we've got things about the business, financial health, kind of growth of the company, strategic direction, whatever. have you. So if we take those out and group them together, once again we have communicating stakeholder value and delivering business results. So these are the two things that we need to focus on when we're trying to contain compliance We need to make sure we've got a really good message that we can clearly, clearly communicate to everybody. It might evolve a bit, and frankly, it almost always does, but the important thing is that you have it from the start so that you can you can move forward with it and you can tell a good story because so much of these especially big projects is actually having a good story internally that you can tell

Speaker 1: to the rest of the company about why you're doing this and why it's worth their time to care. So Ta-da. This is this is my little framework for this. So as I said, it's like a lot of tables. But here's the idea, and I'm actually using this now, so it has been road tested. I've got a really big initiative going on where I work right now. And for each customer I have and each group within the company, I'm going through this exercise with myself. and my team of how do we explain stakeholder value to these different stakeholders. So we've actually got multiple lines in this. So there's multiple groups of customers that we're talking about um and then multiple groups within the company and so we go through each one and we say okay

Speaker 1: how does this have value to these customer groups does it have value because it could be that in some cases someone won't care. And then it's probably better that we don't like shove it in their face, you know, something they don't care about. And we can we can concentrate our time and attention on customer groups that do care. care or groups within the company that do care for whom it's relevant. So that's really useful. The other part is delivering business results. So again, I think this is one of these things that in in engineering design you may not see quite as as much as we actually are exposed to it. Because what we should be doing here is saying to customers, if we build this thing, this is how you'll know it's successful and it worked and it's great. and you could spend you should spend money on it. So we need to find a metric that's important to them to change.

Speaker 1: So that could be something about the efficiency of their business or their cost or their time to deploy. I mean whatever it is, we need to be very cognizant of of that and really understand what you know what the benchmark is. Like if we improve something by 10%, is that actually significant? Is that actually a problem for people? We need to make sure that's very, very clear. And the business result should of course be a manifestation of the stakeholder value. So if we're saying this product is going to make your team more efficient, we better have a metric to back that up, right? So just thinking through all of those things is really useful. And again, going through it for every single customer group that you think is important, just kind of existentially to the business. business and within the company and being able to either either say that yes this is an important group or no this isn't is incredibly valuable as an exercise

Speaker 1: and whenever I've skipped it I mess up. So strongly recommend going through that that process So I kind of filled those in a little bit. All right, so making the most of time and opportunity. So this is probably one area that most of you, if you're an engineer, you're very familiar with. This is where we have our biggest disagreements, you and I, product and engineering, because this is all about figuring out what we should ship. and when. So this is how I think about it, and maybe this will give you some some insight into what's going on in our collective heads. So the way I decided to look at this was from the perspective of this other framework like the balance score cards been around forever. It's called the GE McKinsey nine box matrix.

Speaker 1: The idea of this, this is again where big consulting firms would sit with executives in gigantic companies like GE, and they would go through all of their business units and say, okay, well, which business units should be continuing to to do their thing. Where should we put our money? Where should we expect returns? And so what they do is they use these two axes. The Y, roughly, is industry attractiveness. So How much money can we make, really? Usually all boils down to that. And then on the x-axis, competitive strength of the business unit. So for some inexplicable reason, this is like the canonical This is from the canonical article about this. And for some reason they started on the bottom with high on the left hand side instead of the right. So I don't I don't encourage that, but you know, just

Speaker 1: Just so you know, I noticed. Um, but the idea is if you're if you've got really if you've got an opportunity that's really good in the industry in the marketplace and your business unit's really strong, like you've got high performers, you crank work out fast, you think that they're up for the task, then you invest in it. And if you're in the opposite section you will it says harvest or divest basically get out of there it's a bad place for you then you've got the section in the middle which is where well maybe you'll do it it just kind of depends on can you make any money from Essentially. So here's how I interpret that for product. So we've got our two axes: market opportunity, which is pretty much the same, which is all about money. And team capabilities, which is to me

Speaker 1: about time. So this is why when I'm asking, well, why can't it be faster to market? You know, this is sort of where I'm coming from here because I I want to take advantage of market opportunities and I I do think of team capabilities as really our time, our resources. What are we going to spend our precious dev time on? So I use the nine box matrix for this. So if it's in the top and to the right, and I am gonna do the up and to the right is good thing on my version of this. Yes. If it's up and to the right, build it now. Like stop talking to me. Let's just build it. If it's kind of in the middle for either market opportunity or team or team capability, I'd say yes, let's do it. So this one's tricky. Market opportunity is amazing, but our team does not have kind of the right strengths to deliver it.

Speaker 1: This is something to explore, right? We want to see, like, well, maybe if we we gave the team some training, maybe if we added some people, maybe we hire a consultant. You know, there there might be some things we can do to make that possible. If it's in the middle, I'd say find the fastest path to revenue. How do we make this work for us as quick as we can as humanly possible because it's kind of in the middle for everybody. So it's probably not a high priority, but like let's look into it. And then this is a solid maybe middling market opportunity. Our team's not really in a place to deliver on it. It's like, yeah, there's probably better options. So let's it's a maybe. Everything on the bottom is no. Just no, no, no, no, no, no. Um this is where I I have a lot of disagreements.

Speaker 1: with engineering because where there's a case where you know you're really good at something you're like I could like crank that out in like two sprints and it'd be easy. And I'm like, no, I know that's really frustrating, but this is why. Because I really want us to to build stuff that people will buy. So and I don't think we're necessarily doing that. So this is how I think about it and this is how I work through it sometimes with engineering managers. I don't think they love it, but it gives them some insight into my thoughts process. So we're running out of time. Let's recap the three frameworks. We've got identifying customer value, gains, pains, and jobs, with pains being the most important critical thing you always always always forever have to think about if you're interested in being a PM or you work with one. Containing complexity, thinking about messaging for all of your stakeholder groups

Speaker 1: groups, really getting to the heart of what they care about to their pain, and then figuring out how you quantify those results for them, how they will see the evidence that what you're doing is awesome for them. And finally balancing time and opportunity. So this is looking at market opportunity versus team capability and having an honest, probably very painful discussion with one another about what can you do in a reasonable amount of time that will yield the greatest benefit for the business. So I'm going to go back to to this. I think we've covered actually in this definition a framework for each Customer needs is about the pain, that big old circle. Rallying the organization behind your work is really the complexity part, really getting the message down well.

Speaker 1: And then finally finding a path to value is really like how are we actually going to execute on this so we can actually deliver it once we've got, once we know what the pain is, once we know what our messaging is. And then you know how do we get it ready for someone to actually use and buy so we can all still have jobs. So that's the talk. I think we're a little bit out of time. I'll stick around. Feel free to reach out to me on LinkedIn. or Twitter if you have any questions. I'll be posting these slides on Twitter as well after this talk probably tomorrow sometime. So thank you so much.