 Hi, everyone. Thank you so much for tuning in. My name is Marwan Hade. I'm a director of product management at Slack. And in this webinar, we're going to be talking about five critical skills to help you define the what. Now, quick disclaimer, before we get into the thicker things, the content of this presentation is for educational purposes only. The opinions expressed are solely mine and do not necessarily reflect those of my current or previous employers. So in this webinar, I'll start off by doing a brief introduction about myself. I'll talk about the role of the PM in helping define the what and then five critical skills to help you achieve that goal. Know your competition, know your customer, mock it till you make it, prioritize or die trying, and five, make the customer a part of your team. So quick introduction about myself. I graduated from UT Austin, very, very proud, long-born Huckum. I then moved to Microsoft right out of college, where as the PM for almost seven years, I had the opportunity to work on DevTools for Azure. I worked on Microsoft's low-code app platform, Power Apps, and spent about three years working on Microsoft Flow or Power Automate. I also had a chance on the side to start a fitness-based startup called Send Dev. About three years ago or so, I started a part-time MBA at Berkeley, moved down to the Bay Area, and started working at Salesforce. Initially, I was focused on a workflow product called Next Best Action. I then moved to a new initiative at Salesforce called Salesforce Anywhere from the Quip site. And for the past six months or so, I've been working on the Slack platform. So the role of the PM. Now there's various ways of defining what a PM does, but I kind of think of it fundamentally as the PM sits at this intersection between the business, the customer, and the technology. And what I mean by that is PM is responsible for understanding what the needs of the business are, right? Are we trying to grow revenue? Are we trying to increase our user base? Are we trying to increase reliability, et cetera? We're also responsible for working with customers and understanding what they need and essentially reconciling whether what they need aligns with what the business is actually trying to do. And then finally, the PM is also responsible for working with our design and our engineering counterparts in building out the technology, right? So essentially finding solutions that address both business problems as well as customer requirements. But as you can see from sort of the intersection of all of these constituencies, the most important thing that a PM does is helping define the what. What is it that our business needs? What is it that customers are asking for? And then what is it that the team should build in order to address both of those needs? So the first critical skill in helping you define a stronger what is know your competition. Time is extremely precious, especially in the tech world. And you really don't want to reinvent the wheel. And so it's critical that as PMs, we learn from the successes and failures of others. By studying in competitors, it really allows us to establish a baseline. And from that baseline, we can start to figure out how we differentiate ourselves. Studying in competition also allows us to get inspiration and understand what our long-term roadmap could be like, right? Instead of thinking, oh, is this possible? Or I don't know if this will succeed or not. You can just look at your competition and say, well, this is something that X, Y, Z has already done. Maybe it's something that we need to try as well. And then lastly, studying your competition also helps you understand your unique competitive advantages. Is there a specific advantage, like let's say an existing user base that your company already has? Or is there a particular area or domain that you're already good at? And this is something that will compliment your existing strengths. So how do you get to know your competition? Well, first and foremost, you have to identify who your top three to four competitors are. And the way I do this is, first and foremost, doing customer research. So talk to customers and ask them, well, what are the tools that you're using right now? What are the things that help you do your current job independent of our product? The next thing is sales conversation. You have to get to know your sales partners. And the question to ask them is, well, when you're selling to customers, what is our competition? Who are we competing against in closing a deal? Another thing you can look at is G2. G2 does a great job of aggregating reviews, especially for various SaaS vendors. It's a great way to quickly just understand what else our customers talking about. The fourth thing is analyst reports. Gartner and IDC do a fantastic job of identifying all of the big players in a given market. It's a great way for you to just quickly go in and understand who the key players are, what their strengths are, what their weaknesses are, et cetera. And the last thing I would say about knowing, about getting to identify your competitors, is look at financial statements, especially for public companies. Your 10K, your 10Qs are great places to look for data. And most public companies will list out their big competitors. The second thing I would say is you have to sign up for the service and go on the same exact journey with each competitor. There's really no substitute to trying out a service. You can try to do a Google search, you can look for screenshots online, but really the best way to get to know your competition is to actually sign up for the service and play around with that technology. The third thing I would say is take screenshots. Lots and lots of them. This is not only gonna help you when you present your findings to the team, but it's also a great way to just document the things that stand out to you. Fourth, once you've gone through the same journey with each of your competitors, identify common patterns. What are the things that all of them are doing well? So for example, if you look at like project management tools, most of them also have a workflow product. Most of them also have integrations with things like email or Slack or Teams. Many of them have invested in a templates gallery. So start to identify what are the things that all of the players in a given market are doing. The fifth thing is, start to think about unique differentiators. What are the things that each player is doing uniquely well? It could be something like an onboarding journey, for example. Sixth thing is pay special attention to things like pricing, right? Pricing is where you can get a sense of what are the value drivers that need a customer to go from say, a free customer to a paid customer? So for example, if you look at Slack's pricing page, you'll see that free users can get all of the main capabilities, but after 10,000 messages, you have to upgrade in order to search for them. So clearly like search is a value driver for Slack. The next thing to look at is onboarding journey, right? Is there a specific player that does a really good job with their onboarding journey? What are the questions that they're asking? So for example, if you're going through Asana, Asana will ask you what industry are you working in? What is your team size? What other tools are you using? It's a great way to understand what are the things that are important for a given product. The next thing to look at is Gartner and IDC citations. So how does the competitor talk about how they're being cited by Gartner or how they're being reviewed by IDC? It's a good way to understand when they're meeting with Gartner or IDC, when they're meeting with analysts, what are the things that they're focusing on? So how do you summarize your findings? Well, first and foremost, identify the common trends across all of the products that you've looked at. Identify the standout features. The second thing I would do is create a SWAT analysis. So strengths, weaknesses, opportunities and threats. I think of strengths and weaknesses as really internal factors. How do we measure up against the competition? I look at opportunities and threats as, well, what are the things that the competition is doing that's something that we can potentially tap into? Or what are the things that the competition is doing that we should be wary of? And then the third thing I would suggest is something like a Harvey Balls analysis. Essentially, all you're doing is you're looking at each of your competitors. And so this is an example from G2 of players in the project management space. But what you're doing is essentially you're looking at each competitor, you're looking at a series of criteria and then you're identifying where each of these competitors stacks up. And so you can show this using, for example, a bar graph. You could also show it using pie charts. So the second skill that I think is essential to help you define the what is know your customer. So it's critical that you as a PM know who are your customers. Are there certain companies that are drawn to your product or feature? Are there certain characteristics of the typical user? What job are they trying to achieve? And what is a typical journey that users either take or that you want them to take through your product? So how do you learn who your customer is? First and foremost, I would say usage data. If your product is already live, look at your usage data. So for example, if your subscription service, let's say with a free trial and paid segment, look at each of those segments and try to understand what are the behaviors shown by each cohort, right? Are there certain events? Are there certain behaviors that your free users exhibit that your trial users don't? Or are there certain things that lead your users to go from a trial user to a paid user? The second thing I would do is surveys. This is especially true before launching your product. You need to engage in surveys and ask questions like, how would you describe your role? What are your pain points? What tools do you currently use? What is your experience with a given tool? Or what is your experience with our current offering? What is your comfort level on a scale of one to five? Essentially, what you're trying to do is trying to get an understanding of who are your customers or your target audiences? What are their behaviors? Where do they typically work? What are the pain points of their experience? The third thing I would do is interviews. You really have to go out and talk to your customer. You can't just theoretically say, oh, this is who I think my customer is. You actually have to go in and talk to people. And how do you land those interviews? Use your network. Reach out via Twitter, reach out via LinkedIn, reach out to friends and families. Also, ask your sales teams. If you already have existing products, it's a great way to go in and talk to your existing customers and ask them if they'll adopt a new feature or adopt a new product offering. Then lastly, look at usage logs and talk to internal users. Now, this isn't necessarily true for all companies, but more often than not, especially in the SaaS industry, you're building a product that your company is using internally. And so it's a great way for you to just talk to your colleagues and see, hey, what do you think of this feature? Would this make sense? How do you use it today? And this is something that can really quickly help you land interviews and get feedback and iterate on that. So how do you establish a common understanding? So let's assume that you've done, you've looked at your usage data, you've done surveys, you've done interviews. Once you have all of that data, you have to start to share this with your team. And so I would say there's three things that are critical here. One is identify a persona, right? Who is that persona that you're building for? So for example here, Bob, Bob's a builder. What does Bob do? Bob's a non-technical user. What sort of tools does he use? He uses things like Word, Excel, Salesforce CRM, Monday.com. What does he want to do? He wants to automate business processes. Why? So that he can make his team more productive. Another tool that you can use is user stories, right? This is especially true when you're trying to convey to your team, like, hey, what are we trying to solve? Like what are the problems that we're trying to solve? And how does this actually help? Like how do you tie a feature to a user as well as the benefit that they're gaining? And so there's a certain format to follow here, which is as a description of the user, I want some functionality so that I can do something specific. So for example, as a manager, I would understand what tasks my team is currently working on so that I can play my plan, my next sprint of work. And then the third tool I would use to establish their common understanding is end-to-end narratives. And so for example, he's a story about Gloria. She's a marketer at Acme Corp. Acme is hosting a conference in May and Gloria is trying to organize session. So what she wants to do is she wants to survey her team and she wants to get session ideas from PMs and designs and engineers. So what does she do? She uses a new workflow builder tool and she creates an instant workflow that is triggered from the instance menu. What does it do? It features a simple form that asks for a session, an audience, a level, and description. And she wants to store all these ideas and review them later. So notice here, it's a good mix of technology but also scenario. And I've gotten specific about who the user is, what she does, where it works, what is a scenario where our technology can intersect with the work that she's doing. And so I think narratives are a really powerful tool to convince people. It's a really powerful storytelling tool to align various stakeholders on your team and bring them along in understanding who the persona is. The third skill is mock it till you make it. What do I mean by that? You have to, as a PM, get creative, get scrappy, whatever it takes in order to align your team. And what I would suggest is create wide board sketches. So for example, the thing that you see on the right hand side was something that I created for an app. Hack screenshots together. It's totally fine to take a screenshot of something. And if you wanted to show a dropdown, just add in a rectangle and add in some options. Totally fine to do that. You wanna blur something, you point something out. Definitely get creative. Conceptual diagrams, really effective way to get people to understand the big picture. So for example, let's say you wanted to convey that there's three personas that, they all work as a flywheel or that they're all essential cogs. And when they move together, you can get more momentum. Great, put something like that together and share it with your team. And the last thing I would say is create wireframes. A lot of times, as PMs, we have an idea but we don't necessarily want to do a designer's job. Well, what I'm trying to say here is that you're not necessarily doing a designer's job but you're actually putting a picture to the thoughts that you have in your head. And it's a great way to create inspiration with your team. And so why do I say market to your maker? Why do I say this is important? Well, first and foremost, it's important that you establish a common understanding across the team, ASAP, right? You could be hiding months of work behind a sentence or two, pictures really help. It really starts to make things more believable and more real. And it's also a really effective way of getting everyone on the same page. And the third thing I would say is that it's a way to inspire your designers. And it's a way to unblock engineers, right? Oftentimes you'll get to a position where engineers are waiting on designs before they can start working. Well, with something like this, you can at least start to unblock your engineers and say, well, we don't have the final details but I think it will look something like this, at least start to think about the various data contracts and how data will flow, et cetera, even though we don't have final design. And we're working with designers, you're not necessarily dictating what the experience could look like but it's a way to inspire designers on how you're thinking about various things. It's also a way for you to create some sample content that they can use as they're creating more high-fidelity markets. So speaking of that, a few best practices. I would say create sketches, image hacks and wireframes early and often. I would say this isn't just something you do at the very beginning of the product lifecycle. I think it's something that you do throughout the lifecycle. You do it at the very beginning, you do it when things are in motion but you also do it towards the end when you're starting to think about what the next wave of features will be. Include your images, your sketches, your image hacks, et cetera, your wireframes and your PRDs in the decks that you're presenting as well as in messages that you share. It's a really effective way of working with your colleagues asynchronously. Just throw in a picture and add some description below it. It's a great way to get them on the same page quickly. The third thing, don't get attached to your designs. It is a means to an end. It is not the end itself. If you create a mockup, just think of it as something that you're using as a way to inspire folks and to get them on the same page. This is by no means should it be the final design. That's something that you should work with your design partners on. That's something that your front-end engineer should have a final say on. So here are tools that I've used in the past. This is not necessarily an endorsement of any of these tools. These are just things that I've used that I was successful with. On the virtual whiteboarding side, Miro and Figma, Lucidchart as well. Lucidchart does a great job of helping you create conceptual diagrams. On the wireframing side, Balsamic is a really, really effective tool. They have all sorts of controls that you can play with. For the last few months, I've been using Whimsical. Also a great tool. Great way to quickly create nice looking consistent wireframes. For screenshot hacking, I currently use TechSmith Snagit. In the past, I've also used Paint.net. Both are great for just quickly taking screenshots and doing things like cropping and adding little rectangles, blurring things, et cetera. The fourth skill is prioritize or die trying. There are many ways to define the PM. But I think one of the things that is critical for us as PMs is helping define the priority, right? We are very much responsible for defining both what to build but also the overall end-to-end roadmap. Like what are we doing now but what are we also doing in the next six months, the next 12 months, in the next 18 months? What are the things that are most important in shipping a minimum viable product? And why do we define these priorities? It's because, well, effectively resources are scarce. No matter where you work, at the end of the day, you have a limited number of engineering resources. You have a limited number of design resources that you're working on. And we have to make sure that the team is focused, laser focused on the most critical tasks. And I would say like priority planning is really an iterative process. And you're constantly asking these questions, no matter where you are in the life cycle, what are your goals? What are the team's goals? How much does something cost? Are we doing something that is cost-effective? Are we doing something that has very limited return and costs a lot? Are there any dependencies that we should be wary of, right? Could we do something now that is very expensive or could we wait for a few months and have something that a partner team has built? Or is there something that a partner team is building right now where we can provide input because it's something that's important to us a little longer down the road? So here's my approach for prioritization. The first question I ask is, what are my organization and my team's objectives? Is it, for example, to increase revenue? Are we trying to grow usage? Are we trying to increase reliability, et cetera? I'll then make a list of granular features, bucket them into P0, P1, or P2. Think about what objective it's fulfilling and then create a stack rank. So essentially, I'll put my P0s from zero to 99. I'll put my P1s from 100 to 199. I'll put my P2s from 200 to 299. Essentially what I'm doing is I am assigning them a stack rank value and then prioritizing them based on how important I think they are. So what do I mean by P0, P1, and P2? This really depends on your organization. But broadly speaking, I would think of P0 as critical for a minimum viable product. This is essential. It's absolutely necessary in order for us to validate whether what we're building actually meets customer's needs. It's absolutely critical for us to meet our business's objectives. P1, in my mind, is essential, it's important, and it's impactful, but it isn't necessarily critical. The product can still stand if you don't ship this particular feature. And P2s, in my mind, are nice to have. They're still important, but you don't have to do them at this very moment. Once you've made that granular list of features, once you've done your prioritization, it's important to socialize it with key stakeholders and iterate. So this isn't something that's just one and done. You constantly have to get feedback from your team members, from your design partners, from your engineering managers, from your product architects, et cetera. It's something that you socialize with stakeholders, allow them to leave comments and iterate. You might move one thing ahead of another, or you might move something from P0 to P1. It's really a process that takes a number of days in a brief weeks. And the final skill, make the customer a part of your team. As a PM, you represent the voice of the customer. So it's critical that you have a Rolodex of customers, your own customer advisory board that you can tap into early and often. It's also a board that you wanna keep up-to-date about your innovations. It's also a place where you can quickly invalidate a hypothesis. Hey, let's say you have a great idea and you're like, oh, I don't know if this actually, like, will this solve your need or not? Just tap into your customer advisory board, shoot them an email, drop them a Slack message if you can Slack connect, for instance. Just ask them, like, hey, here's what I'm thinking about. What do you think? Hop on a call with them and see like, hey, here's some early thinking, or this is something that we started to build. You know, does this meet your requirements? Is this something that you would use? What else should we be thinking about? Engaging with customers early and often is a great way to build up your credibility because oftentimes members of your team aren't necessarily engaging with customers in the same way that you can. So it's a great way for you to tell your team about, hey, here's what we're building and here's why it's the right thing. It's also just a way for you to increase your confidence. If you have a set of features that you're thinking about, it makes it so much easier to talk about these features if you know exactly who is gonna use them and how they're gonna use them. So I think timing is key when you're engaging with customers. Here are the questions that I asked before development. I asked things like what are your requirements? Why is it important? How do you address these needs today? During development, it's more around, well, here's what we're building. Does it meet your requirements? What else should we be building? How important is this specific feature? Is this something that you're gonna use or maybe it's not that important to you? After development, there's two questions that I asked. One, do you have any feedback on what we've built? Now that it's in your hands, what else could we be doing? How can we improve this existing offering such that it meets your needs in an even stronger fashion? So in summary, as PMs, we sit at this intersection between the business, the customer, and technology, and we help define the what. And you can define a stronger what by knowing your competition, by knowing your customer, by mocking it till you make it, by prioritizing or die trying, and finally by making the customer a part of your team. Thank you so much for tuning in.