 As mentioned, you know, today's talk is scaling product management. And one thing I was fascinated about giving this course is the opportunity to present it. I see a lot of material here and even outside on how do you scale product, how do you build infrastructure for scale, how do you get more users? I think it's more of a rare topic to actually hear about how do you scale yourself or how do you scale your team when considering product management or product management organization. So I'll spend a little time on that tonight, a little bit, not so much about myself but those interesting we can discuss afterwards. I spend most of my career in product management for a little context but have done a whole bunch of other things. I'm going to go through my resume but really provide context that I'm doing this from slightly different angles. I think we all do over the course of our careers. So as we go through this discussion, even afterwards, you know, happy to share whatever perspectives I've learned over my career. And at the end of the day, it's really what this is, just one point of view that you get happy to share and discuss, happy to hear from others as well what you've learned and you've seen over your respective careers. So tonight, we'll kind of start off with, you know, what are thoughts on scale? Like, why are we talking about this conversation? Why is it relevant in the product management domain? And then really two big angles, one, scale and you. And when I say you, I mean more of the individual contributor or product manager, you're in your day-to-day, you're in your responsibilities. How do you scale or manage the decision around that? And then ultimately really scaling with the team. That's either if you're a manager or product manager or a leader in your organization, how do you tackle that from both sides? How do you get the most out of your team but likewise, how do you understand what to work with your team to get the most out of them? So why should we care about scale at all? What's really the big deal or why are you even worth? It's been a little time digging into this. And in my career, one thing I've seen, particularly in early PMs in their careers, right, as you get established and you're all eager to jump into things, right, you want to take on your responsibility to start delivering things. And you deliver things and that's good. And then you want to deliver more and you want to deliver more. And the bar goes up for you to deliver more, right? It becomes in many cases, something that you grow with experience but also can become somewhat of a vicious cycle, right? And as you continue to do more and more, take on more projects, deliver more features, work on more releases, at some point you can hit a wall if you just keep grabbing with both hands, right? And the thing that I really like that too is the more trap. You can keep doing and doing and doing but at some point that's going to break down. There's only so many hours in a day. There's only so much you can do. Either as you grow with experience, there's a certain threshold you're going to encounter where that model no longer holds water. But what's interesting about this analogy is we think about scale and why it's important is, certainly you've heard you can work harder. Obviously you can work smarter. But I think part of it is really what is the more that you're trying to do or what does the smarter get you, right? In this case, this rider's being smarter about trying to win a race. It's a very clear objective or a goal that he's trying to follow. But I think that's something you have to ask yourself constantly when you consider scale in the context of your day to day. At the end of the day, what are you trying to do? Like going to the office and saying, well, I did 12 reports last week. I'm going to 24 this week. That's great. But really what does that get you or your organization, right? So part of this discussion is going to be around the mechanics or tips around scale. The other is how to really think about what does that get you or deliver to you professionally, your organization? Really what's the value at the end of the day you're providing? And how do you keep that kind of frame of reference in your head as you make these decisions or evaluate your organization? At the end of the day, it's all about value creation for yourself, value creation for your company. So doing the more, doing things more efficiently in and of itself, may not be the answer to what you want. So let's keep that in the background as we go through this discussion. That's really one of the key things we want to drive. So scale on the PM, right? Why scale? Kind of looping back to your later point. My view of the world could be different than any others, but increasing the efficiency of value creation, right? Give you a few key items there, right? One, certainly the value you want to derive. And it's also about efficiency, right? It's not just do more with less, it's not just do more. But how do we get better about it and more efficient about that end goal? Not just the reports and piling things on. And one way I'll go through this, kind of my top ten. My goal for this talk, by the way, if you can take two or three key nuggets out, I think it's a success. So we'll go through that in that style and see where we end up. One, and you've probably heard some of these before, you can't do everything. No one can. You can't just take on more until you can crush yourselves. But also, not all problems and solutions are the same, right, really? What are you picking and choosing and delivering, but also, where are you spending your effort? Where do you make investments that are ultimately going to pay off down the road? Some things, maybe need a very strong touch or high touch. Others, maybe not so much. You can still get the same net result. I think it's important to take a step back and understand when you're evaluating your scope of work, where are you placing those bets? And again, not everything is the same. One example that I had received in a prior position that really reflect on, actually relates to UI. And I view a spectrum of how you can come to UI decisions or constructs. In some cases, you can spend a lot of time and build really high fidelity, pixel perfect, super accurate wire frames of your flow. Everything's figured out. You spend hours and hours and really go and nail that. Sometimes, it's maybe a rough idea. You iterate on very quickly. You can go to the whiteboard. You can generate some ideas. And you learn a lot and can move forward very quickly. But also, enough granularity to get to the next level of what you're doing. Another level I view is the cocktail napkin, which I have done this. Go to a developer and say, well, I need a box. I need to capture this. Here's the idea. Go run with it and come back when you're done. Now, the interesting point about this illustration is there are areas in which this makes sense. If you're thinking about the new homepage for your website or that critical killer feature or that new business you want to go into, you probably want to think about making those strong investments and really figuring out every little detail. But if you're on, let's say, a release notes tab on your app, you're probably not going to want to spend hours and hours cranking through every pixel perfect design. So the key thing to take away is really think about, again, where you're making those investments and the context of what you want to get out of it. You always want example. Think of product requirement docs. You go to the right specs. Think of working with new product ideas or working with marketing. Same philosophy applies. Take a step back and you can understand what you're going to get out of your level of work and doesn't really pay off. Because if you're spending a lot of time on one thing, you're not on something else. Again, that's the limit to your ability to take on more things more efficiently and continue to deliver value. One thing I've seen a lot of product managers do very well is we've seen this kind of trade-off graph, this kind of chart, impact effort. If we do this in feature analysis, sure, it's like a common thing in figuring out road maps or what you want to build next. How many people who are familiar with this do it with your own work? All right, a couple hands. But same philosophy applies. I think we're very critical as product managers on where the debit resources are going, engineer, design, QA time, and we make these trade-offs. But we take a step back and say, well, I only have eight or 10 or 14. How many hours you work in a day? How do we kind of view the work in the same way? I think it's a paradigm we're all familiar with, but just looking through a slightly different lens and has enabled you to focus on things that really move the needle. Consideration number two, what I call calling the play. Sorry, I'm a Notre Dame guy in his college football seasons, had to slip one of these in. How many people here have found themselves walking to the kitchen, getting some coffee, and a marketing pal grabs you and says, hey, can look over this press release. And then sales gets you and wants to pull you to a call and QA finds you and says, hey, I got a defect that I want you to look at. How many people get randomized or hijacked as like to call it throughout your day? Some people? Okay, I'll say everyone, myself included. I know definitely you. You know, here what I call is calling the play is how do you control that? Because the more things that come in through sideways channels or that kind of get you off guard, you know, they pile up and they start eating away at what you can do. And sometimes you lose sight of where is the value that you're really driving or how you're making those trade-offs. I'm 100% guilty as to by the way. I have a hard time saying no to people. But no is not always a bad thing, right? No in the context of I'm doing something more important. No in the context of I can do it when to set expectations with individuals. But there's a trade-off there and something to be aware of. Another consideration is how do you use tools or processes to help drive that funnel of that process? Again, I'm not saying that you should engineer the world but similar to how do feature requests come to your door? How do defects come to your door? Why is work that comes your way any different, especially something that takes up your time? Are we product managers who've used trail image easily, put little submission forms in? I mean, you can even take it offline on a white board having a discussion with people. But it friends a little differently, right? Instead of a sprint for developers, it's what's your sprint? What's the work you're doing and how you're making those trade-offs? But also providing visibility to those outside of your immediate world of what's going on, which helps to the no but when discussion. So some of the thing about navigating this is certainly tricky, depending on the size of your organization. Everyone can work closer or farther apart. But something to be mindful of is you take on more and more things and fight the urge to make everyone happy all the time. Consideration three, war on meetings. Anyone here read Dilbert, not dating myself? Anyone know who this guy is? No? Oh, look up. All right. Pay no attention to the AOL.com email address. It tells you how this is. If you have a few moments, look up Dilbert, you're probably laughing at your day, but we're having a meeting discuss employee retention. Tell the employees quit because there are too many useless meetings. We won't be getting into reasons at the first meeting, right? How do people get sucked into meetings that just aren't worth your time? Okay, I'll make you stop raising your hands now. Don't worry, as you go through. But I do it as well, right? And this can become a time suck, really, and we just do it. I think there's a great TED Talk video on just mindlessly getting sucked into the counter invites that pop up on your Outlook, right? Oh, sure, I'll go with these 12 other people and spend two hours and not know why I'm there and have no action items and just keep moving on. This becomes a big time suck, right? This is something that eats away your productivity and even makes it harder to figure out what's a priority or not. And again, a lot of this, I think we think about it on a regular basis, and it's hard to drive organizationally, but really only use it when you have to. Really, it's like, what's the point of doing it? Like anything else that you're working on? Like, unless there's an explicit goal and outcome and things to follow up with, you should actually have, like, why are you there? And I found, as much as people talk about or think it's a great idea, unless you do it and enforce it on others, it's usually hard to get traction. It's easy to fall into the trap of, yes, let's have a war on meetings, let's not do it. I'll book three things tomorrow and we can talk about it, right? It kind of ends up working backwards and it's a hard thing to adjust to. Last thing I know, there's many philosophies, whether it's two pizza rules, the mid-people, how many you can count on your hand, but think about how expensive these discussions become. Like even think of this room right now, if you know we're all employees in a company, how much that's costing and what you're getting out of it. Same for every little meeting you have, right? You're burning time, which burns money, which takes away value from something else you could be getting. If it's really not the highest priority item or the most value you can get. You really try to think about that lens when you probably tomorrow get sucked into meetings like I'll be bright and early in the morning. So that's a few points on the individual contributor side of it or things that you can control on your own. Scaling is a PM manager. Now this can really apply to any manager. I know some are managers today. Others maybe aspiring or will be soon, but I think some takeaways here are very valuable. Think about your own organization, both if you're managing others, but also how do you fit into that equation? Some tips and tricks to actually bubble up or maybe key takeaways that you can incorporate into your day-to-day or working with some of your peers. So in this case, as a leader, your scale is a function of your team. And again, a lot of things you've heard in the past, but you get as much done as your organization does. And the more you can scale your organization, that's really you can start to gain true amounts of scale and really impact value across the org. That being said, I'm sharing most new manager training if you haven't come across it. Letting go is hard to do. You can't do it yourself. You can't get hands on. These are very things you encounter a lot, but it becomes true. And the more you hold on to things, the less time you have to develop your team and the less time or less ability your team has to actually learn to scale themselves. And it becomes a trap that sometimes you need to get shaken out of. Oh, I can't do this because you can't, my person on my team can't do it perfect, so I'm gonna step in and help them or review it or work on it. Then they don't get that opportunity. And then it's harder for them the next time. And then you're caught up and you can't think about how to scale down the road. So it becomes, again, another vicious cycle, more so from the manager's perspective. But again, it just eats away and it's hard to kind of build that momentum or gain that scale and independence that a real organization that moves forward needs to grow with. So with that, consideration five. Think of your team every day. By the way, when I say think of your team, this could be the team you work with horizontally, it doesn't need to be vertically. But I make it a habit of every day I spend at least 15 minutes, if not more, thinking about my team. And I have a team member in the back too, so I'll hold me to that, I'm sure. What does my team look like? What is my org? Where are they gapped? What happens when someone leaves? How do I grow people? What are new challenges they can undertake? It sounds like a lot of focus on that, but the team is evolving every day as well and the challenges around the team are evolving every day. The org evolves around you. There'll be new challenges that the business needs fulfilled that maybe some of your team can step up and do or maybe they're not in a position to do and you have to figure out how to fill gaps. This is something that requires a constant amount of attention, one for the plus of it, growing people, taking on new things, but also the flip side of managing the risk in the work. All right, so great, I can scale, I can take on new things. What if Bobby, the one database guy decides to leave? Well, does that leave a hole or can I work that through? So understanding how you can plug holes or plan for things is very important because if you do have a catastrophic event on your team or you're left with a hole, backfiring that can take time. Then other people are scrambling and they limit the ability to move forward and really scale with your organization. So it's something that I think is a critical part of the growth of any team and it's not just a manager's responsibility. I think anyone who's working with an organization can see where the gaps are, can really understand where there could be certainly opportunities but risk areas and how do you follow up suggestions to mitigate that or backfill or provide insights that those are really issues that one needs to work through. Situation six, failing locally versus globally. People generally only learn when they have the chance to do so, right? But doing it in a controlled manner so they could help you and the team you're trying to grow, right? If someone in your organization is, let's say, learning to present or has a business plan they wanna propose, going right to the CEO with that is probably not the best first chance to do that. Maybe some group in the team, maybe a smaller part of the organization. How do you control that experience so that one has the room to fail but also the risk of that failure is manageable, right? And finding those opportunities is key so that people are one less afraid to do it but also take a true learning opportunity from that failure. Obviously with more risk or the higher up an organization, one goes and encounters failures or big projects or very visible things, it can create a lot more stress, may not learn from it as much, may be very critical of oneself. How do you, again, provide that nice middle ground where there is room to take those risks to extend and push the boundaries but also in a way that's not gonna be, again, catastrophic to the org or the business. And as people get more comfortable and they learn more, you can expose them to more and give them more opportunities and keep driving forward. Going back to the prior slide, understanding the org and the opportunities is also very important to see where do you push the boundaries or where do you align those individuals up to take on those new opportunities. Number seven, look for blind spots. This could be a tricky one, both introspectively and within a team. Do we know what we don't know? Are there questions that we haven't asked yet that are gonna come back and get us? How does this relate to scale? When you do wanna take on new challenges or you wanna cover your bases and really move ahead, these are the surprises that come up and bite you. It's like, oh, we're building this great new feature, we're relying on this infrastructure. Oh, we never bothered to instrument for test coverage. We don't know our uptime availability or we didn't even talk to this whole set of customers. These are things that you don't wanna come and surprise you. That oftentimes are just the due diligence of product. But oftentimes too, if you don't ask the questions or think about it, they can sneak up on you and just become a surprise. And again, those surprises become things that need to get backfilled, that you have to think about how it fits into your organization, how do you really plug that whole? I'd also say this is something that everyone should spend time and think of themselves. Everybody gives you growing your respective careers if it's product or somewhere else or looking within your team. What don't you know? Is it technical? Is it UX work? Is it your customers and marketing? One of the things that, again, I'm gonna sneak up on you and potentially impact you in a very negative way if you're not aware of it. It doesn't imply we have to know everything all the time. Maybe you just need to know that it's a gap and you can go to the right people to figure that out. But it's really taking that step back and understanding the landscape and really seeing if we are exposed, what do we do about it now? And let's say a week from now and a year from now as your organization and even your own skill sets evolve. Number eight, go offline. This ties back to the kind of death by meetings philosophy but whatever can be taken offline, really think about taking it offline. Everything doesn't have to be drawn out discussion. Everything doesn't have to be at the whiteboard. How do you kind of parallelize things and get whatever you need done with the least amount of interaction or effort? One thing we rolled out at MakerBot, not a very exciting name, called it a product decision memo. But I thought it was an interesting example. Within our leadership team, we're actually finding we spent a lot of time bringing people in, explaining issues, having five or six people have to sign off and understand what was happening. When a lot of times people knew what was going on, they had a pretty good sense of the risks, they had a position already defined that was usually aligned because these things would come up again and again in these topics. So rather lightweight, just create a process, right? Outline the main points, tell me your recommendation, who needs to sign off on it? Send it to this group. There are no questions that they sign off, it goes in archive and you're done. This actually gave us two really big benefits. One, we took a lot of those discussions in meeting time which would inevitably an hour or two a week of a very, very expensive meeting. Think of a C-suite of a company meeting just to discuss things. One took it offline to recapture the time. But two, another added benefit we found was sometimes the ambiguity of these decisions, particularly in meetings, was taken away. You know, have an actual snapshot in a repository at a time when people approved it. Because sometimes memories get fuzzy, right? Oh, didn't we talk about this and agree to that? Oh sure, but now it's different. Or maybe something changed and they didn't communicate to everybody. Now we can go back in point and say, well, we can revisit it, but this is what we all agreed to, right? So again, if you think about the process of decision making or cataloging or working through things, let the process work for you if you can. And again, it's a simple framework. It doesn't have to be complicated. I just use Google Docs and a shared folder. It doesn't have to be a big JIRA setup or a sauna workflow or anything complicated. That's usually a good way to start this type of scenario, by the way. You don't have to over engineer the world with lots of tools and lots of infrastructure. Again, just like any good old agile project management, right? Have an idea, what's my MVP? How do I test it, iterate? Same philosophy internally. Same with process, all these things. You kind of gain a lot of knowledge, see what works and if you need to, you can make it more robust. And again, this is just one example, but I actually ask all of you, as you go through your day to day and think about scenarios that could benefit from something like this. Do you really need the discussion? Do you really need the meeting? Is there a way to short circuit that entirely? Say again, going back to those trade-offs on where you're spending your time. If you're not sitting there for an hour explaining this to the five people who already know the answer, what else could you be doing? And where their value could be deriving and has that help you, again, continue to grow and get ahead. Number nine, priorities and your team. Different color scheme, same feel. Importance, verges, urgency. The Eisenhower decision matrix from way back when, guess what, it's still actually very applicable, right? It's designed in a world way before we were dealing with these kind of problems. What's the importance? What's the urgency? Urgent important, do it now. Important, but not urgent. Figure out when to do it. Or if it's not important, you delegate it out or don't do it at all, right? More on the magic side, but I think even from our day to day, I find this to be a very interesting decision matrix on where you spend your time, right? What's the ROI on your day to day as far as the things you're working on? Obviously, something comes up and is on fire, you wanna handle it, but how do you make the decisions on what to delegate out? Or more importantly, I find this one, how do you not even do it at all? This goes back to the how do you say no scenario and maybe you don't come back to it. This is, again, another tool that I think most of us probably do very well if defects come up, if there's feature asks, if something in the business is on fire. Sure, we have a process to figure it out, we can slice through the requirements, but how do we do that for ourselves? Again, how do we evaluate through a different lens? A lot of common tools that I think everyone's used on a pretty regular basis. But yes, Eisenhower decision matrix, you can look it up, probably find 1,000, hit sign it pretty quickly. Consideration 10, scale starts with you. I think we spend a lot of time here talking about it's the nature of scale, but how do you roll this out or how do you really do with this at the end of the day? I think a lot of this is really just the mindset for ourselves. And how do you champion or think about that through your organization? I mean, these things just don't unfold organically most of the time. It's something of, again, take a step back and think about some of these attributes. Where does it make sense to use these things? It's not, again, about it's the latest LinkedIn article, so let's roll it out or some new hot methodology just for its own sake and want to try it. It could be married in that, but go back to the top of the discussion. Think about how to increase the efficiency of value creation. How do we get scale out of an organization? Where are the questions we ask ourselves to consciously move in that direction? And I'd be probably kidding myself and others that it's not always easy. These things oftentimes encounter resistance or people aren't bought into it or it's hard to change process. But if you think about little by little where do you kind of sneak those things in? When you try them out? Where do you put your MVP process-wise to evaluate is this really gonna move the needle for the organization? Is this really gonna get us to a better place? And sometimes you'll get wins and it'll be great when people bought in and other times it may just crash and burn throughout any process that you encounter. But if you think of the end state, I think it's something very sellable to any business or organization. How do we get better about delivering the things that really matter and how do we get focus and how do we build an organization that can do that because the effects compound? We think of even this room, right? I can scale, if everyone here scales in the same direction that's a massive multiplier. And it's the same philosophy with anyone's day to day and your organization can have the same benefits ultimately. So when do we go about this? Again, I kind of go back to the earlier point like there's no magic formula. You're not gonna find some earth shattering event more than likely it says this is the time we're gonna turn it all on its head. But again, these questions that come up, right? Where are you spending your time? Is your organization operating efficiently? Like, has a team actually become stagnant, which is another one? You're gonna get stuck in your ways and you're on like a smooth course and no one's taking on more. How do you get more efficient? How do people learn and kind of grow and have those opportunities put ahead of them? Because that's again gonna lead to scale downstream. It's good to have those reflective moments kind of similar to looking for those blind spots, right? Where the blind spots are your org or your process or how you're working that you can take those lessons and move ahead. So a few points, for you scaling as PM about value efficiency at the end of the day. How do we derive an increased amount of value? Not just doing more and not just only doing it smarter but thinking about that value and where we're going. As a manager, it's gonna be about your team, right? Again, I would not just product team, engineering, QA, the whole org, right? You're gonna grow with them and how do you give them the opportunities to do so? This whole process by the way again, in many cases it does take patience and practice, right? Something you're gonna try, you're gonna experiment with, you're gonna find what works. It's not gonna happen overnight. It's not gonna be, oh great, we're all 500% better the next day. Usually it doesn't work out that way. Again, you'll have probably fits and starts of things that work well or the things you wanna revisit. And again, there's no magic formula here. Every team is different, every company is different. Similar to just rolling out agile in organization. I've yet to make two places that do it the same way. I think it's similar in this scenario, right? It's what's gonna work best for how your teams are structured, how people are working, what are the challenges you have? What are the challenges you have yourself? Where do you wanna make those investments and make those trade-offs? A lot of the frameworks that they apply across the board but the way you'll go about it, the nuances of how people interact is something you have to be thoughtful of, right? Because this is as much about process and decisions as is about people and personalities and how it all comes together. Can't just force this on everyone expected to work. There are ways to introduce it that can ease people in and really hopefully reap the benefits downstream. So look at that. That's a lot for a talk.