 Hi, everyone. I'm Graham Perkins, and I'm excited to be here today. I'm going to be talking about building a team strategy from zero to one. And this is a topic that is something that's near and dear to me in my experience. I've learned the hard way in a lot of cases how important this is and how I have worked on a lot of different teams in those startups and larger companies, specifically in forming teams where there's some combination of new members joining and a new problem space that we're exploring. And so through lots of trial and error, I found that this is one of the most important things you can do to set yourself and your team up for success. And I did a little bit of looking around online as I was preparing for this presentation and saw a lot of content on setting strategy at the company level, as well as doing vision and roadmap work at the team level. But I didn't see a lot of content out there specifically around forming a strategy for the individual product team. And it's really important because it's something that most of you will need to do anytime you join a new company or join a new team within your existing company. And so my goal is to give you some of the tools and perspective that you need to be able to come into a new team and build a strategy with confidence. So this is meant to be pretty tactical and we'll be talking through what a strategy is at a high level, why it's important and what makes it up and what specific steps you can take to maximize your chances of success. So let's dive in. A little bit of background on myself. So I'm a former senior product manager at Asana. I've also worked at Autodesk, Expensify and some other startups. A lot of my experience has been in B2B SaaS, focusing on products which have a product-led growth motion, but are moving into the enterprise into more of a sales-led growth model. And a lot of the product work that I've done has been focused on the core product experience. And so I've seen a good amount of variation in stage of company. And so I think what I present will be pretty widely applicable, but as always your mileage may vary depending on your specific context. So what is a company product strategy? Strategy is one of the most important but often least understood things. It's thrown around a lot. But what I found in my experience is that there often isn't a great shared understanding of what strategy means. And it can vary quite a bit in terms of understanding from company to company. And so I first want to talk about this in terms of company strategy, but then more importantly talk about what this means for us at the team level. And as a side note, this is something that strategy is something I thought I've understood and then have been in situations where I've learned nuances that I didn't appreciate before. So just kind of one kind of general comment is that it's hard and it's complex. And I think realistically you're always learning when it comes to how to do a better job of setting a strategy. So that's a good way to approach this is that you're always going to be learning new things. There are always nuances that you'll pick up along the way. I'm going to I'll read out a quote about strategy from AJ Laughley. This is in his classic book, Playing to Win. He describes it as making clear tough choices, like what businesses to be in and not to be in, where to play in the businesses you choose, how you'll win, what abilities and competencies you'll turn into core strings, and how your internal systems will turn those capabilities into consistently excellent performance. So that's a lot. But I think like at the core of this, there are a couple of pieces to it. First is making hard choices about what businesses and markets you want to focus on and not to focus on. And both of those pieces are really important, including what you don't want to focus on. And then what your core competencies will be and how you'll differentiate. And differentiation can include better technology, especially in the software context. But importantly, it also includes business model, distribution, product experience, and so on. Another way to think about strategy is it's this idea of a unique insight that you believe to be true that your betting will build in during differentiation. Peter Thiel just drives this in zero to one as the company secret or the thing that the company believes to be true that others in the market either don't see or don't agree with you on. What does this mean at the team level? At the team level, it's the narrative about what the problems are that you need to solve, given your goals and capabilities, and how you're leveraging your unique capabilities to differentiate your area of the product and reach your goals. So I think it's really like understanding who's your core segment or the jobs that you're doing for your area of the product, and what are the principles and prioritization you use to most efficiently validate hypotheses and make progress towards your goals. So it's like, what's the most leveraged path that helps you get from what your goals are in the obstacles to those goals in the most efficient and value creating manner. And so an example of this for a team could be we built all these robust features, but they're not easy to use. And so adoption and therefore retention is suffering. We need to focus on the user experience for early users to help them see value from the product earlier. So that could be like part of a strategy for an individual team. A second example would be there are all these important things that are missing in the product. And so users aren't motivated enough to switch from what they're currently doing. So we need to solve XYZ things before we think users will be motivated to switch. Why strategy important? I think it's really critical before you go into a road mapping process that you have some working strategy in place, even if it's super rough. It's going to change as you shift and learn, but it should be a stake in the ground based on what knowledge you have at that time. And I'd suggest initially coming up with a three month version and then gradually expanding it to a longer time horizon as you get more comfortable in your space. And if you do it right, it'll save you a lot of time down the road, both in terms of road mapping and just generally in terms of buy in and efficiency of communication with your team with product leadership with executives as well as go to market teams. Some of the points about why this is important, it helps you articulate your thinking about what's important, what hypotheses you need to validate and what the risks and unknowns are. It creates alignment and trust with executives, go to market teams and your team. It creates guardrails for road map planning. It helps cross functional teams align around your priorities. And it helps you de-risk and get ahead of challenges that may be three to six months plus in the future. One thing to note is that you don't need a vision in place to create a strategy. And I think in a lot of cases newer teams that are new to a domain and are still learning are better off waiting six months or so before creating like a 12 month to two year plus vision. Just given the amount that you learned in that period of time, I think it's often better to do like a quick version of a strategy, put together a roadmap, shift for three to six months, learn from what you ship and then kind of over that course of time, I think you'll develop a much higher confidence vision of like where you see your products going in the future. What happens if you don't have a strategy? You can, I think the basic thing that I've learned again through like kind of trial and error is that you can be working on all the right things, but without a strategy to tie everything together. It can feel disjointed and then you end up spending a lot of time rehashing things with people and kind of justifying your roadmap instead of building and validating. And so I think in its best form, the process of creating a strategy is getting buy in on the direction of your product from leadership, from your team, from other teams. And it can help really be a motivational tool as well as an alignment tool for everyone within your organization that then makes the execution process for your team more efficient. Some of the symptoms if you don't have a strategy in place is that you have to keep going back to product leadership to get buy in for initiatives. Your immediate team might feel a lack of direction and purpose. Go to market teams may not understand how to sell customers on what you're working on and why. And then cross functional product teams may not prioritize initiatives that you depend on. What should a strategy contain? It should contain your team charter and scope. So what do you own? What are the bounds of your surface area? And it's okay if these aren't fully defined yet, but it should be your best understanding of the current kind of scope of your areas of ownership. Maybe with some open questions or caveats that you still need to figure out. Should also include a time horizon. Again, if you're just starting out three months is a great place to start. It should include goals or KRs. In my experience, most companies aren't great at goal setting and startups can be particularly challenging in this respect. But even if your company doesn't have a sophisticated goal setting process, take the time to think about what you want your goals to be so that you can articulate them. Because it's going to be the thing that you're measuring yourselves against and reporting back to leadership on. And so even if it's going to change over time, you want to have like a stake in the ground about what your goals should be, because that's going to create more alignment for prioritization and measuring success of your initiatives. And it's just a really important exercise to go through. So I would recommend spending a good amount of time on thinking through your goals, brainstorming them, and then getting some agreement about what those goals should be, even if they'll be refined later and maybe changed. Oftentimes I've found that a lot of the disagreements between product teams and execs or go-to-market teams boil down to a lack of alignment on goals. So it's important to have them outlined. You should include target personas or jobs. So who are you focused on? And this is important for describing what challenges they have. So that's an important part of strategy. Your prioritization criteria or principles. When you're describing your prioritization criteria, it's important to be real and think expansively about these. So it should definitely include things like product value, technical cost, and confidence. But it should also include other factors that may be specific to your team, such as or surface areas, such as we have a lot of technical debt that we need to pay down. And so we need to invest maybe a higher percentage in that for X amount of time. Or we have customer escalations that we have to prioritize because there are retention risks for the business. Or we're lacking technical expertise in XYZ areas, so we'll be slower to ramp up on those things. These are all real inputs into how you'll be deciding how to prioritize. And so the more explicit you can be, the better and more high quality your strategy will be. Also, core hypotheses, you're trying to validate over that period of time, whether it's three months or six months, risks and outstanding questions, and then notable knots. And notable knots are things that are explicitly out of scope and are meant to be callouts in the strategy. And so an example of this for something that I worked on was we owned a reporting product, and we said that we were only going to focus on in-product reporting, that UI, UX experience, and not API or integrations, which were other aspects of reporting. And we wanted to make sure that we made that explicit, that we were drawing the bounds in terms of reporting in-product versus other aspects of the kind of overall reporting experience. So how to get to a first version of your team strategy. When I've seen this done well, it's good to split up these individual steps and collaborate on them with your team and group leads. You can do each of the four separately and it's a good way to use them as checkpoints to get buy-in, even before putting like a bigger strategy doc in front of a wider audience. And so the things I see as part of this are defining the personas or jobs. In this case, you should definitely lean on previous UX research that's been done. If you don't have that, you still should create these even if they're rough to begin with. Oftentimes, you can leverage like internal interviews with subject matter experts, people who know about your particular product area to develop some understanding of like how the different personas or jobs break down. You're trying to develop some sense of segmentation that's going to help you decide what specific segments you want to focus on. And that's a really key part of formulating a strategy is making those decisions about what segments you want to focus on. So that's the first piece. Then define the core problems those personas or jobs base. This again should be based on qualitative and quantitative data and research about what are the biggest blockers to your goals in those areas. To be able to define this, you should have a good understanding of product metrics and customer problems based on previous feedback. And I highly recommend doing the work ahead of time. It can be quick and dirty, but like doing the work ahead of time to really have a good understanding of what these problems are because these are important anchor points as you're putting together your strategy. So setting goals, again, ideally you've defined these ahead of time, collaborating with your team leads as well as your kind of director level managers, and then your prioritization criteria and principles. So again, these first four bullet points, each of these can be done as independent steps. And I think it's good to kind of split these up to get the ball rolling on creating a strategy as well as they're more kind of like bite-sized chunks that don't take too long in isolation and also are going to be a good collaborative exercise for your immediate team leads as well as group leads. So I would recommend starting early on these and knowing that you'll refine them as you go. Once you've done these four things, the things in these four bullet points, you'll put together a first draft of your strategy and get feedback from your team and group leads. Assuming you've done these first four bullet points in a collaborative way, I think the first draft of the strategy shouldn't be too surprising. Like you should have kind of surfaced a lot of the feedback and questions in doing these first four steps. And so it's going to be more incorporating any new feedback and doing another revision of that and publishing it. And then that can be, you know, you can do that cycle of getting feedback on your strategy, updating it and sharing it out again for feedback as many times as you need. I would say definitely don't feel the need to go overboard with this. It's a rough working version and just make that clear to everybody you're working with. You know, you're planning to update it in three months or so. And to publish it ideally, you know, when you publish it, you make it available to anyone at your company to take a look at. And then again, update periodically. So this strategy act is an input to roadmap. So I do recommend doing the strategy before the roadmap. The strategy really provides structure to help you understand the important problems and the hypotheses you need to validate during your roadmap planning process. And you can do them together, but ideally you have to buy in on strategy before you go into road mapping. Separating them creates more clarity and it then becomes easier to put together your roadmap. Once you have a strategy, you can then brainstorm roadmap candidates with your team and group leads and then use your prioritization criteria and strategic themes to rank them. I'm thinking about going to more detail on that in a future presentation on that kind of ranking process. Because I think there's some good exercises there. Cool. Okay. So just some last, some final tips. Definitely recommend doing the quantitative and qualitative work upfront so that you have a point of view on who your personas are or what the jobs are and what the core problems are. You know, it's going to be an exact, but having a point of view on that is really important going into the strategy process as well as the road mapping process. Definitely leverage previous work on UX research, data analysis, any kind of analysis that's been done by other folks within your organization on your product surface area. So leverage that as much as possible because it's going to be so much more efficient for you all to build on that versus trying to recreate the wheel. And in a lot of cases, there have been people, there are people within your organization who know a significant amount of that. So I would spend upfront time identifying who those people are and talking to them. Be realistic and expansive when thinking about prioritization criteria and risks. Decide ahead of time how involved the team and group leads want to be in the creation process of the strategy and roadmap. I've seen some teams that want to be involved at the very earliest stages and then others who want to be more editors. Once you've already kind of put some of the strategy in place and so kind of figure out where on the spectrum your team falls on that. Feedback is super important. Make sure to spend time reflecting on it and incorporating it. Even if you disagree with it, it's valuable. So thank people for providing the feedback and kind of make it clear that you're considering it even if it doesn't ultimately make it into the strategy. Also, if there's something that you can't decide on, then just feel free to include it in an open questions part of the strategy. I would say it's more important to have more open questions than taking longer to draft up a strategy. I think publishing a working version of the strategy is more important even if you have some more outstanding questions. Drawing clear bounds about what you're explicitly not focusing on is an important piece. And then lastly, just to reiterate, it's not meant to be perfect. So focus on creating the short-term strategy that you'll revisit often. Alright, that's it. Thank you for listening. I hope this kind of gives you a better kind of framework and sense for what to expect when you join a new product team and that you're inspired and feel like you have more confidence in creating a new strategy for your team. Again, I think it's a key part of learning and growth as a product manager and it's something that will be a lifelong skill. And so, yeah, thanks again and look forward to chatting with some of y'all in the future.