 Hi everybody. Thank you so much for coming. We have a packed house here. I know you're going to ask a lot of questions during the presentation. Try to save them to the end if you can, but if you have a burning question, just raise your hand and we'll get to it. This is called the product manager getting started guide. A bit about me before we dive into it. I'm the former senior director of product management at Shutterfly. I'm also an Agile investor in Beam Authentic, which is an IoT wearable startup in San Francisco. I was a former advisor at a box. This is well before they went public. And I have 20 years of product management and user experience in my repertoire. A couple of companies have worked for Shutterfly. My team and I were in charge of the flagship product, which is Shutterfly.com. Shutterfly makes over a billion dollars a year in sales and my team did top and bottom of the funnel optimization and innovation. Westfield retail solutions. Anyone shop at Westfield? Someone work at Westfield? Absolutely. Yes, they used to be called Westfield Labs. That's exactly right. They changed their name Westfield retail solutions. They have about 200 shopping malls all over the world and to build a brand new shopping mall costs well over one and a half billion dollars. Before I got to the company as a consultant, they had legacy systems powering their apps and their sites. Very disparate data sources, very different look and feel user experiences. One data set couldn't talk to another. They retired all that and my team and I defined APIs and end points so they could actually scale one beautiful stack that goes well beyond the 200 malls. And also AOL. I worked for AOL in their web properties group several years ago and my team and I monetized AOL calendar, which at the time had tens of millions of uniques a month today. It has much more than that and wonderful CPM model of all that traffic and we did great with our metrics. So a little bit about me. Let's talk about getting started with the product manager getting started guide. This presentation, I've given it a few times and it's mainly for folks who are very new to product management. Maybe you're just out of school and you're like, hey, what is product management? How does it differ from all the other cool things you can do in tech? It also is really valuable for folks who are in one functional group and they want to transition over to product management. They just don't know where to start and this is a lovely place to start. And it's also kind of cool just to be educated regardless of what you do at a tech company, whether you're senior, junior, middle manager. It's just interesting to kind of share information and that's why I'm giving the talk today. So cool. Here's an overview of what we're going to be talking about. The role of a product manager, there are three questions that every product manager should always have the answer to at all times. We'll go through that. There's a set of functional skills. I'll go through them. It is not an exhaustive set but we'll go through it and we'll see what you guys think about that. Functional skills must be supplemented with domain expertise. And the last and most important thing I think is the ability to take ownership. It's not as easy as it sounds. There's methods that work and methods that don't. We'll go through the methods that work. The next part of the presentation, I want to share with you something that I've come up with called the personal gap analysis. How many of you guys do gap analyses as part of your roles as product managers? Anyone heard of a gap analysis? Cool. So basically we'll explain what that is and you can apply yourself to it developing your skills as you would a product or a feature set. We'll go through two fictitious characters, Michelle Maurice, do your own, and we'll go through some tools and training and of course Q&A. So how does that sound as an agenda? All right. Cool. Awesome. So the three questions. What is our product? Who is it for and why is it valuable? Everyone in your company is going to have an opinion on that. That's awesome. That's good. But product manager needs to know the answers to those questions and it needs to be, there needs to be an internal answer to that and an external if you're talking externally. And what is the product? You'd be amazed if you know what you think the definition is and you ask maybe a team member, it could be very different and that's okay. But your job requires that you know what it is and who is it for is even more important than what it is. Target market. Are you selling to consumers and are they the only decision maker or is it more of an enterprise product where there's several constituents and several decision makers? And who is it for now versus who do you want it to be for in six to 12 months from now? And then the value proposition. Really important. Like product managers love to get into the details, love to get technical features, awesome stories, you got to do it. But value prop is more of a marketing skill set and to understand what that is way before your team starts coding is really important. So the three questions of product management. Here are the functional skills that I think are pretty important. Now this is not an exhaustive list. So I'm going to go through them. Maybe you guys have heard of some of this stuff, maybe not. But the number one thing is gathering requirements. And there's a lot of different ways to do it, a lot of different sources. The requirements are going to come from if you have an install base, maybe you have inherited a product with a million users. Awesome. Start there. They're talking to your customer service folks. They're talking through social media. You might even survey them. There's also other constituents that might not just be your users and let's listen to them and understand what their needs are. Partners will have requirements if that's part of your business. Once you have these requirements, what are you going to do with them? So there's a lot of different development processes. I'm sure you guys have heard of Agile and within Agile, there's Extreme and Kanban and Scrum. Awesome. User stories work with all of the different Agile methodologies and the product manager needs to write short, crisp user stories and then they roll up into epics and when you follow that process, it makes it much easier for your team to deliver on them through some type of narration or sprint. Well, great. What if you write so many user stories and have so many epics that you just can't get it all done in one release? No worries. You have a backlog and it's basically a database, a collection of all of this good stuff that you could do later and you could adjust priorities and when you want your team to commit to the next set of stories. But you're always grooming that backlog. You're always in there in the morning maybe or at night with a beer or whatever and you're kind of going through it and understanding, you know, again those three questions. What is our product? Who is it for? Why is it valuable? And constantly using that as a filter to make sure that your backlog is well groomed. Listening to feedback is going to come to you in a couple of different ways qualitatively. I think I mentioned surveys and verbatims and that's awesome stuff but also quantitatively. Like I'm sure a lot of you guys, if you're on a product team now, you know, there's instrumentation inside of the product in Google Analytics or Flurry or, you know, whatever, there's tons of awesome tools that are bringing you usage data and that is feedback. And you need to not just take a look at the day, you need to analyze and understand what it means. For example, e-commerce companies, Shutterfly, for example, they have a website and they sell stuff on it. Well, any website that sells stuff, there's always a user flow that goes through a funnel where a lot of people start at the top and at the end, you transact. And you're going to lose people along the way. Totally normal. It's okay. If you lose too many, then you're not going to hit any ROI or KPIs and that would be bad. But, you know, if you have the right funnel metrics, you could do the analysis on where the drop-off is and see where there is quote-unquote a choke point. And like, ah, I've noticed on this page, people are getting confused and then you can turn on more metrics like has anyone used a heat map? We're seeing a heat map. Those are awesome. Because then you can see where people are clicking. But I want them to click here. But for some reason, they're hovering over there. Okay, let's do an A-B test. Let's move the button and see if that actually gets our conversion to increase. Anyway, that's stuff that you would lead. You might not do all that work, but you would be leading that, recommending all that good stuff. Prioritizing features, of course, understanding your target market. Sometimes that's easier said than done. What if you haven't launched yet? What if you're a brand new startup and you think you know who target market is? Okay, cool. But, you know, do you really understand them if you haven't gotten out beyond beta yet? Not really, but there are ways to extend the beta and there's ways to take a look at your competitors to kind of get some kind of a fuzzy indication of who they are. And then, of course, as you get into production and you're constantly listening and iterating based on that feedback, you're going to get to know them more and more. When you get to know them, whether it's a startup with a brand new, amazing, disruptive product that's going to create an awesome category, you're first learning what their underserved needs are. For example, Uber has disrupted the transportation category. So taxis have been dying ever since Uber has been going up. That's great. But when Uber started, they basically took a look at that market, like what can we do better than the closest competitive alternative, which is taxis? All right. So that's what they did. They studied before they did any prototype, where they started hiring data scientists and doing all that really sophisticated awesome stuff. They really got into what's called the problem space by looking at those underserved needs and understanding the value proposition. If you solved those problems, how valuable would that be? Would people load their credit card onto a phone and pay? And there's a question. Yes? Is there a framework to identify the underserved customer needs? Yes. So is it an R? Is it more intuitive? Awesome. So yes, there are many frameworks. And I thank you for asking. There's several books out there that present frameworks. One that I really like is written by Dan Olson. And I'll share it with you at the end. And there's a whole chapter on the method on how to identify these needs. And there's other books too. There's the Carlos, who's the CEO of this company. He wrote a book about it as well. But there's lots of resources. And I thank you for asking. Writing an MVP document. Who knows what an MVP is? Thank you. Please. Exactly right. Exactly right. Exactly. You've got to write a document. And it doesn't need to be a book, but it can't just be a bunch of links. Like, hey, go look at my user stories in JIRA. And I'm going to go to lunch. No way. You have to write an actual document that goes through requirements and also non-functional requirements, like performance and other important things. That's not a question. That's not a wireframe? I'm so glad you mentioned wireframe because in my mind, an MVP document and a wireframe are complementary. It's really, especially if you're working on a product that has a lot of front-end interaction. You know, if you write API endpoint, you might not need wireframes. But if you do a lot of front-end stuff, absolutely you have your MVP document that explains, you know, what the requirement is and then what the feature implementation on that requirement. And then a wireframe could be a couple of different things. It could be a quick sketch that you do yourself or maybe your UX designer does with you. It could also be a user flow, how the user will flow through the front-end or maybe both. But I'm glad you mentioned that because a lot of times, if you have one and not the other, people get confused and they wait for the wireframe and then we miss our deadline. Influencing team members, right? So this is classic product manager, right? Influencing without authorities, even a book called that. You know, you are a team member and you're influencing those who are not product management folks, engineers, designers, QA, sale. How do you do that? Well, it's hard and we'll go through maybe not too many tactics at this stage, but it is part of your job. And then the last one is my favorite, is you define the KPIs, key performance indicators, and then you figure out how to measure them objectively. You get buy-in from your team, right? Well in advance of signing up for these. And everyone's gold on them. And it's almost down to the level of performance if you want, your own personal performance with your manager. But the KPIs, if you're starting with data and analyzing data up here, then you've got to, you know, keep it going with measuring success by defining goals and objectives and measuring them. Question over here. Yes, they will be, they're on slide share right now. And of course I can email them and then we can go through product school as well. I think they have a Google doc as well, absolutely. So I spoke a lot about functional skills. My guess is I missed a few. And that's okay. That's just a starting point. But I wanted to transition a little bit over to domain expertise, because the two work really well together. It's very important. A lot of folks who are trying to start a career as a product manager or move from one functional group into another, they don't really have a lot of those skills yet. They just haven't had a chance. But man, do they have domain expertise, which is super valuable. So an example of domain expertise is, you know, maybe you were in a e-commerce, mobile, social, gaming, financial technology augment. Maybe you were in that kind of a company already. Right? But you're not in the product management group. You might be in the engineering group or the sales group or whatever. And that's valuable. Because you know a lot about the trends and the competitors and the problem spaces. And that's incredibly valuable. Right? And a lot of people forget like, oh, I've never written an MVP. No one wants me to be a product manager. Not true. No. If you have some market category expertise, that's super valuable and awesome. Another thing that I put into the domain expertise category is knowledge of the target market, who is our customer. Very important. So someone from sales or biz debt, even customer support. Customer support, by the way, is an amazing training ground for product management. Amazing. And man, you know a lot about what the customer goes through, both good and bad, and that lends itself beautifully to product management. And another example of target market is maybe you do research. Maybe you do primary research or you consume secondary research. Maybe you're an analyst on the business, on the marketing side or the business analytics side. Super valuable training. So functional skills plus domain expertise, plus one other thing. Taking ownership. Super important. Please don't do it that way, like she's doing. Not going to work well for you. Taking ownership. Let's go through it because it doesn't come naturally for some people. And if it does come naturally for some people, sometimes they don't do it the right way. And it's not very collaborative and all that. So let's go through it. So I use the model of a pie. I hope that image is viewable by you guys. A pie, nice and round and whole with all different flavor slices. But when it's all together, it's a whole, but each slice has its own flavor. And the whole pie is owned by the whole team, right? Or the pod or however you guys are organized at your companies. Each slice is equally important, right? So, you know, maybe the top slice is engineering. We'll just go around the wheel. Design, product management, QA, marketing. That's an example of a product team or a pod, but you guys can vary that. Each slice is equally important and delicious. You own a piece of it. So as a product manager, you own this piece, which happens to be my favorite flavor is pecan pie, by the way. And it's really important to know that you own that piece and you're going to deliver what you need to deliver to make sure your team can do what they need to deliver. And what's really hard is, you know, to understand that each piece is highlighted throughout the process. So at the beginning of a project, maybe the product manager has the highlight on him or her. Awesome. So where's your MVP? Where are the stories? Are they well prioritized? Are your prioritizations backed up by data? Can I see the raw data, please? I want to make sure I agree with your takeaway. All that spotlights on you. Pecan pie. Awesome. But we're not serving an entire pecan pie. We're serving a hybrid pie. So then the next handoff would be maybe to design. Wireframes, maybe high-fidelity comps that need to be tested somehow through user testing, maybe visuals or whatever. So you could see how this goes, right? Then it goes over to engineering. Then it goes to QA. So, again, PM should never do what this dog is doing. But it's funny because as a product manager, you want to do this. You want to devour the pie. But you can't. And based on your company culture, but more importantly, the dynamics of your team, you just put it out there. It's like, let's try this pie metaphor, guys. Can I own a piece? Great. How big? It's the same size as everyone else's. Oh, I like it. Let's keep going with the metaphor. Or whatever. You could use a cake. You could use anything that's round and chop-up-able. All right? So taking ownership makes sense. A lot of people just kind of gave me some positive, nonverbal communication like, yeah, that makes sense. That's awesome. Okay, great. Well, how are you going to prove to your team that you're capable of doing that? So I came up with the Ds of ownership. There are six words here that begin with letter D. And let's go through them real quick. So maybe you do some of these now. Maybe you don't. But all of these should be kind of tools that you dive into. So the ability to discover requirements, discover the problem space and figure out, hey, is this problem worth solving? If so, how should we do it? The ability to discuss your findings and discussion doesn't have to be like one to many. It could be on Slack. It could be, you know, after the stand-up meeting. It could be at lunch, right? But the ability to discuss and listen. Define. So whether that's literal, like writing a story or an MVP or, you know, defining the problem in a different way, maybe you come up with a model, a financial model. Like, we can make this much money if we do this. Demonstration. Now this D, if you forget all of these, remember demonstration or demonstrate. Because it doesn't just mean take the latest build and go demo it for your stakeholder. Even though that is part of it and that is super important. It also can mean demonstrate to your team that you're totally bought into this. So that Westfield Labs. We were coming up with a set of APIs. So all the different shopping malls could create apps and websites to do a lot of different cool things. Maybe you take advantage of all the APIs or subset, they're all there for you. Well, when we started, no one knew what was available. So I just demonstrated what another company did with their platform that went through a similar situation. And I just went to, I'm not an engineer, but I went to their site and they had a really cool little API demo. You put in a little data and it pops out something. And that was a lunchtime demo and it just worked wonders. Like, okay, I get it. Again, demonstrating to your team that you care and that you want them to go in a certain direction. And that's that D. So setting direction yourself or kind of subtly recommending that the direction we should go in. And then making decisions. And I don't mean making decisions like a dictator. It doesn't work. It never works. But driving decision, getting consensus, letting people know, hey, if we can't decide on these stories for this sprint, we might not hit our time to market that we need for the whole product in whatever number of months that is. So drive decisions. And make decisions, too. But you don't always have to, but you need to drive them. So the Ds of ownership. Okay, so we spoke about skill set. Let's talk about, if you know all these skill sets are important, right? The Ds of ownership and the functional skills and the domain expertise. So how do you, you might not have all that. I don't have all that stuff right now. And I've been doing this for 20 years. My goodness. How do you figure out what you have and what you need to get to and come up with something called a personal gap analysis. So before we dive into the personal gap analysis, I just want to tell you what gap analysis means. So gap analysis is the features that are not yet in your product that you know will have value. So let's say, again, you're maybe not a one dot O, maybe you're like working on a two dot O of your app, for example. And, you know, since you're working on two dot O, it has a certain amount of valuable features. You know they're valuable. Hopefully you're listening to your customers. You're looking at the qualitative data and the quantitative. But man, you know there's, you know, there's visionaries in the company. Maybe you're one of them that wants to take it out to here. And I don't care about timing. It's going to go out to here as far as functionality and value. Well, there's a gap there. There's a gap between what you're planning for two dot O and what you want the future state to be. That's, and do a gap analysis. What will it take to fill it? Man, we need to hire a lot of engineers and we need to license this and we need to partner with them. That's a gap analysis. So I'm like, wait, that's cool. Can it be applied to me, to a product manager trying to get better at his or her profession? So I think product management stands on four pillars using a metaphor of like maybe, you know, post and beam construction. There's four pillars in the ground and then you stand on top of it. Nice surface, nice and sturdy. And I think the four pillars are in these four areas. Marketing, technical skills, business and communication style. And I'll define a few of those in the next slide. And I think this is relevant for like all experience levels. So beginners, people with a couple years, all the way up to CPO level. So again, these are just quick definitions. This is not a comprehensive definitive list of what each one of these pillars is, but it's just kind of a starting point for discussion. So let's look at the marketing pillar first. So as a product manager, you should know what, how many market segments there are in your target and what your market category is. And if you don't know that, that's okay. But that should be something that you get to know. And of course, those two terms are very different. You should also know the size of your market now and the rate of growth and how you're measuring it or are you measuring it by number of users? Are you measuring it by revenue? Or how are you measuring it? Competitors, there's always competitors, maybe not direct if you're doing something new and disruptive and awesome, but there's always indirect. And you should not freak out on competitors. It's okay, it's a good thing to have them, of course, because it validates the space that you're in. But you should keep your thumb on it and your eye on it. Points of differentiation, hopefully you're different and better than the next competitive alternative and you should know those as well as you know the answers to the three questions. Who can tell me what the three questions are? Anybody? What is that? Excellent. Beautiful. Why is it valuable? Thank you. Excellent. Wow, that's good. Okay, so that's the marketing pillar. Let's talk about the technical pillar. So you should know the stack that your back end is built on. And you don't need to know it in detail. I certainly wouldn't be able to know the incredible details around architecture. But you should have a knowledge of the overview. You should be able to sketch a very simplified architectural overview on a whiteboard. Now you don't have to make it up. Of course you work with your engineering staff and they help you understand it, but you should have a knowledge of what the stack is. You should know some technical trends. And also when you define products, don't just define the front end and how many steps it's going to take the user to, you know, change the color of an object. Even though that's important, right? Because you want that step, those number of steps to be low and you also want to leverage conventions and not reinvent the wheel and confuse users. But what about performance? What about the time it takes to paint the page or render the page after you've changed the color? Maybe the color is a gradient. Maybe the gradient's not using CSS. That would be bad if it's a web app because it'll take too long to load. See what I mean? And these are just some technical things that if you talk about them, put them in your MVPs, have that knowledge up front. It makes your stories, first of all, more digestible from your team, which is awesome, but also more believable. Like, yeah, this product manager is doing a good job because I can actually deliver what they want in a normal amount of time. They're not asking for crazy stuff. So technical skills. Business acumen, super important. So there are use cases. I'm sure you guys have heard of those, but there's also business cases. So, you know, if you're creating a brand new advertising platform, what model are you going to use? CPA? CPA? I don't know. You have to kind of go through those business cases. You don't have to do it alone. There is probably an analyst or a biz dev person that can help you with that, but you need to be on top of that good stuff. What's the revenue model? Are we going to give it away for free for like five years and have 10 million users and then use a premium model? I don't know. It's hard to do. I wouldn't do that. What about a freemium? Hmm. What about advertising? Oh, interesting. Did you say 10 million? Because that's when that volume, that's when it starts to make sense. Anyway, just kind of get into the revenue model. It's really important. Pricing. How are we pricing it? Is it going to be tiers of pricing like enterprise software? Like, you know, here's an entry level product and it's free up to a point and then we start selling per seat. Are we going to have high retail prices always discount them? Assuming it's an e-commerce type company and there's always going to be a slash through it. Wow, that's high value. Retail prices are really high. Always 20% off. Awesome. What's that look like? How do we do promotions on top of that? Super important to have knowledge of that. You don't have to lead it. It's too much to lead all of it. You just have to have knowledge and think through some of the stuff when you're defining your products. You know, this is a good one. Make by or partner. A lot of companies that I've worked for in the past, they're really into being objective. Like, we don't need to code everything ourselves and let's license something to help us do this thing that we're not really that good at. So our core competency is X and we're going to code everything that involves X. Anything that's Y, there's already companies doing that. Let's license that. For example, analytics. Could you write your own analytics package? Yes, many companies do. But there's six or seven off the shelf that work really well. So if you have limited resources, do you also want your engineers to write your analytics package on top of your super cool innovative stuff? Normally the answer is no. But again, it's a discussion. Just be on top of that decision-making. And then another thing in business is, you know, anything you make, anything you make as a product manager within a team, you and your teammate, there's always going to be constraints all the time. And one of those constraints is legal, legal environment. Whether you're trying to go out internationally and there might be some laws around privacy that you're skirting in the U.S. but in Germany and France, no, no, no. So again, always be aware of the legal environment, making sure that you bring those constraints to your team so they don't go down this path where you have to back out. And then the last pillar is communication style. And what I mean by communication style is, you know, understand if you have an internal audience, how you speak to them versus an external audience. External audience could be the press, could be partners. You don't want to talk the same way to them as you would with your team or your internal folks because there could be some buzzwords that if you say to your internal team, they're cool, they get it, but if it rubs the external partner the wrong way, there could be unnecessary anxiety generated. So careful of the words you choose internally and externally. Written versus spoken, right? A lot of product management folks that I've worked with, they're great at writing, beautiful stories. But when they speak, they're often verbose and they keep talking and talking, they don't get to the point. That's okay if you're having an intense brown bag session with some members of your team, that's actually kind of a good thing. But if you're talking to an executive, probably a bad thing because they really want you to get to the point. And if they dive down deeper into details and they ask you more, great, you have it in your back pocket, but don't lead with a long drawn out that just get to the point. So spoken versus written. And then of course, I touched on this, executives versus team. Talking to upper levels, talking to your level, and talking across the cross functional team. Be very capable to do that one hour and then walk into a meeting with a different group of people the next, back and forth. It's called context switching. It's hard to do. And with practice, we all get better at it. So the four pillars of product management. Let's take a look at Michelle, fictitious character, not a real person. Just to give you an example of what I mean by this personal gap analysis, kind of a cool tool. So in Michelle's previous role, she was a market research assistant. And in her current role, she's a product manager for an e-commerce company. So she scored herself. She got her hands on this slide deck and she took the pillars. And she used the academic grading system, but you don't have to. You can use one through 10. You can use five stars, happy face, sad face, face with a line through them. It doesn't matter. You can come up with a scoring method that you feel comfortable with. Anyway, so Michelle used the academic. For marketing, she gave herself a B plus. So that makes sense for her former role. Technical, maybe she didn't have a technical background when she did her college. And that's all right. She gave herself average. Business gave herself a B. In communication style, she thinks she's really great at it. So this is awesome, right? Because your goal is to identify your baseline, know where you want. You want all A's. Of course, everyone wants all A's. That's the end game. Just identify the baseline and there's a certain gap here with Michelle. And then if I were giving Michelle some advice, I'd say, Michelle, what should we work on first? What do you want to go into tech or business? You tell me. But don't try to do it all in one quarter, assuming you're trying to do this quarterly, which I do recommend. Just carve out a little bit. I want to get better at technical. Awesome. So what is your product, Michelle? Well, I'm an e-commerce company. So what are you responsible for? Well, I'm responsible for the bottom of the funnel. So people, they put stuff into the cart and we make recommendations to them in the cart and we take certain form of payments. Ah, excellent. Are you aware that there's lots of cool digital wallets out there that work for web and native apps? Oh, great. Why don't you do some research on it? See what I mean? We give Michelle a little goal like that, a little digestible, bite-sized, achievable thing that, of course, is measurable quarter by quarter. She could take that technical from a C to a B, which would be amazing for her as a product manager and amazing for her as a person because she learned something awesome and maybe she gets a bonus as a result. Who knows? Let's go to Maurice. So Maurice, also fictional. Previous role, he was a senior sales engineer and in his current role, he's a product lead for an enterprise SaaS company. So we scored himself also using the academic thing. Marketing, he was kind of hard on himself, a C minus. Maybe he was never exposed to marketing folks or was never asked to do anything with marketing in the past. Technical, form engineer, A, awesome. Business, B minus. Communication style, B minus. So you see how this works. Let's take a look at you. So we looked at the fictitious folks. Let's take a look at you. So I urge you to try this. So define the PM pillars for yourself. Marketing, technical, business, communication style. Choose your grading system. Record a benchmark just like our friends did. And then set realistic goals for future improvement. Quarterly, annually, both. It's optional to share this personal gap analysis with your manager and or use it for performance eval. It's up to you. I use it with my teams and feel free to mention it to your manager or not. But it's an interesting way to kind of quantify where you need to bolster certain skills. Cool. So we spoke about personal gap analysis and skills and all this good stuff. How are we doing on time? Sam says we're good. Excellent. Let's take a look at tools and training. Start with tools. So as a product manager, you don't use the fancy tools like the designers and the engineers. But you're going to use creation tools and collaboration tools. Some creation tools that I like are Microsoft Office, whether that's the heavy client for Mac Windows or Office.com or Office 365. Love Google Docs. Google Slides. Google everything. Amazing. Someone mentioned wireframes. Well, there's low fidelity and there's high fidelity. Low fidelity, there's some tools that I like, Balsamic and Marvel. The high fidelity Envision, which is mainly for native apps and Flinto. There's a lot of tools, guys. I'm wondering maybe I can pause and see for creation when you're creating documents, creating presentations, creating wireframes or flows, user flows. What tools do you guys like to use? Same as what's up here? Excellent. Anyone else? Ever notes. Ever notes. Awesome. What's this called? Lucid chart. Lucid chart. Thank you for teaching me. I'm now going to check them out. Excellent. Yes, please. Yes. Excellent. Yes, please. UX pin. UX what? UX pin. Pin. Cool. I'll check that out too. So creation tools. Let's talk about collaboration tools. So a whiteboard is a tool. It is a very basic one, but it's incredibly valuable. Now my guess is a lot of you guys work at companies that might have remote team members. Maybe the folks are in country but not close to you. Maybe they're out of the country overseas. So you'll notice that under my collaboration list here, I don't have any web conferencing stuff because I don't like it. But it's a necessary evil if you have remote teams. You've got to use it. I don't like it. And the reason why I don't like it is, my goodness, I've tried many, many times. You can get work done, but you can't get brainstorming work done. You can't get real collaboration and teamwork and sharing ideas. And that's okay. You do with the resources that you have. It's okay. But you might want to, if you're in this situation and you have folks all over the country and out of it, you might want to work it where maybe once a year, you all meet somewhere that is cost effective or you fly someone to you and then you fly to them. Again, this all costs money, but you could put it together and just try to put together a proposal and just try to get some more meeting in the months because whiteboard sessions, I haven't found anything that works better, to solve problems. Now to do the basic stuff like, hey, we're having to stand up. Of course, web conferencing is awesome. It's all problems that make your product unbelievably valuable and useful. Whiteboards are great. Google Docs are also great. Google Docs, you can see who's typing and see the comment log and see the edit log. It's wonderful. Slack is an amazing tool. There's a Slack channel for product school, right, in product management. I think a lot of you guys use Slack or it's competitor. What do you think? Yeah, it's awesome, right? You can have conversations with your entire group, fully transparent, or you can subscribe to different topics and hashtags and get alerted. You have a chat with one person, everyone's looking, and just by interacting with that one person, you've educated the rest of your team without even doing any extra work. And then lunch. You know, everyone has to eat lunch. Feel free to eat alone, but sometimes it makes sense to eat with your team, just like these guys are doing on the steel beam there. You can get stuff done during lunch. I don't mean like brown bag and like don't enjoy that sandwich because you have to listen intently to... I just mean just chatting about it. By the way, I liked what you said at that stand-up, but I was confused. Can we go through it? Yeah, it helps. So those are some tools. Let's talk a little bit about training. So a lot of great books available. The Lean Product Playbook by Dan Olson has a framework that you asked about and many others. Hooked. Have you guys ever heard of a book called Hooked by Near... I think E-Y-A-L. A-L, Near A-L. It's an incredible book. How many people have heard of it or read it maybe? It's awesome. It explains habituation. This guy's a cognitive science guy. It explains in the brain what's going on when you are habituated to a new product. And so the people who check Facebook every hour, they're hooked. How are they hooked? Read the book. You'll find out. It's incredible. The product book by Carlos, who's the CEO of this school. So those are some books. There's many more, but I like those three. Groups. A lot of groups. Especially meet-ups. Meet-ups are awesome. There's one called the San Francisco Product Management Meetup, the Lean Product Meetup. You go to Meetup and search product management. They're all there. But these two have a lot of really great users, very active, very interesting. Classes. Product school. Mind the product workshop. Has anyone ever heard of mind the product? Yes. Yes. There's one going on right now in London. They happen all over the world. And I mentioned Dan Olson. He wrote the Lean Product Playbook. He is leading the one in London literally right now. It's happening either now or tomorrow. And another one, another example of training is a mentor. It can either be your manager or a colleague. And they're technically training you when you identify someone who you think is great at product management or has incredible product strategy or vision. It doesn't have to be even in your own group or in your own company. It can just be a colleague. I had a mentor who was a magnificent architect. And wasn't even anywhere near my team. And I learned a lot from that person. And anyway, that was training to me. And it was also fun to hang out. And the last bit on training is what you guys do every day is it's obvious you consume posts, whether they're news feeds, blogs, Twitter, LinkedIn. All of this stuff is training. Like when you define what topics you want, you're constantly reading it in your feed. And I read a post a couple of months ago that I wanted to share with you. I'm closing with this, by the way. There will be questions after this. But I read a post called Good Product Team, Bad Product Team. And the reason why I'm mentioning it is it was inspired by a post that was originally written 20 years ago. It was a long time ago. It was called Good Product Manager, Bad Product Manager. And this one's been updated because it has the word team in it. And the person who wrote it is Ben Horowitz. And this was when he was, early in his career, his director of product management at Netscape. Who remembers Netscape? My goodness. So right now, you know, he's a fellow at Andreessen Horowitz on Sandhill Road. But, you know, he was a product manager in an earlier life. And Marty Kagan, who has written a book called Inspired How to Great Products, Customers' Love, he wrote this variation on Horowitz's post, Good Product Team, Bad Product. I urge you to read it. I put the URL in there, but you can certainly search on those keywords. Incredibly, it sums up everything I just said in like one post. So posts and news feeds are important and enjoy consuming them as you do. So guys, thank you for listening and Q&A. I'm very open to any questions you might have. Please, in the back. Thank you. Thank you. Thank you. Awesome. Yes, sir? What product? Yeah. No, that's very interesting. So I've heard that many times. It all depends on your company culture, how large the company is. Does the company have a CEO who is really good at product? If so, that would be bad for you to consider yourself a CEO or product. Does your company have a CEO that is really great at other things and wants more of a colleague to kind of be a sounding board and to drive the vision? Because product management is like vision plus strategy plus tactics or implementation. And it should be kind of a combination of all those great things. The CEO of your product tends to focus on the strategy, which is cool, but who's going to do the tactics? Who's going to write the user stories? The CEO? So again, titles versus actual responsibility, often they're a little bit different. But I've talked to a lot of folks who love it. They really enjoy that. It makes them feel great. And if it makes you feel great and you're doing an amazing job and you're balancing that vision plus strategy plus tactics beautifully and your team is collaborating with you effectively. Awesome. Awesome. But it really does depend on the culture and the size and your actual CEO, what he or she is really great at. Please. When do you think startups should hire plus PM, especially when founders are not from a product-backed-off engineering industry? Yeah. So this is a very important thing, right? Because there's two ways to look at it. There's funding. Like, can you afford a solid PM? You have to pay them, and then the person might want some health benefits, right? So startups might not have that in their P&L. So that's what they do. That's what they do. And they have market rate stuff ready to go. There has to be kind of a volume of work that is too high of an opportunity cost for the founders. Because if you don't hire that PM, that work's still going to get done. All that stuff that we just saw, gathering the requirements, writing the envy, you've seen it all, you've maybe done it all, some of you. It's still going to get done. It's just going to get done by guys who should be going out getting funding or should be going out doing other kind of C-level stuff. So if you do that opportunity cost analysis, and it's very high, then yeah, bring on a PM and get going. And you have a follow-up. Do you think we're like part-time PM? Part-time. Like just like part-time designer? Oh, my goodness. Can you tell what I think about it when I do this? And I'm not trying to be a wise guy. You know, product management is like you're in charge of the life cycle of a product, and the product comes out, it's quote-unquote born, and it grows, it grows. If you are part-time, how can you effectively be with that product through its life cycle? Which, if it's a good product, it will hopefully last many years. How we doing Sam? Thank you. I should do that for the video. Thank you. Other questions on the couch? Sure. Hard of counting. Excellent. A question was asked, if you're going to be a product manager at a tech company, what kind of coding skills should you have or should you learn? Yeah. Yeah. That's terrific. It depends on what the product is and what your team wants from you. A lot of product managers benefit from learning HTML5, JavaScript, style sheets, where they can actually look at the code and comment on it, even prototype. That helps a lot. Other teams really like, especially teams that have machine learning and AI competencies, they really like folks who could do SQL queries. You don't have to use a dupe or any of that, you know, SQL queries, just doing the basics really is really valuable. And then another skill that I've seen and that I respect is, you know, Python scripting or some other kind of backend scripting, whatever that language is. Just getting a basic knowledge of that. It really goes a long way. That's a great question. Other questions? Actually. Please. Please. Yes. I hear about companies who prefer to hire PMs who may be specific to a particular industry like working in financial technology and, you know, finance and so on. So how does somebody get their foot in the door and break it into that field if they don't have any experience? Yes, thank you. Excellent. Excellent. So that's what I was trying to get at with that subject matter expertise slide. So it works the other way. So if you want to get into fintech, for example, financial tech, and you've never done it before, leverage your other skills, leverage your ability to take ownership and some of those functional skills. I presented a bullet list. It's probably even longer, but my guess is everyone in this room has a few of those bullets already. I guarantee it. Focus on that. Because when you go to the person who is interviewing you, and they're like, ah, you don't have any fintech. I can't hire you. Not true, my friend. I have the ability to take ownership and I'm killing it with these functional skills and I'm reading these books that are educating me as well. And that really goes a long way. Thank you. Terrific. Yes. Green shirt. Yeah. So often like in a lot of the books they talk about a really specific scrum team or a agile team. But what about if you're a product managing a team that has multiple products and are doing, it's like a more of a start-up thing where you can't exactly have one agile team when you're about to manage a team. Good, good. Thank you. So the question there is if you're a product manager or a product owner on a team and you're supposed to just be focused on one product but you can't because you're a start-up and you might be resource constrained and you have to do double, maybe even triple duty, how do you do that? Is that a good summary? Yeah. Nice. Well, that means you're on multiple scrum teams unless you have one giant scrum team which has its pros and cons. I assume you're using scrum or some agile method? I'm using scrum. Great. And what are your sprints? Two weeks or one week? Two weeks, okay. Good iteration. The way I've seen it work well is and this is a lot of work for you is you have to go to three stand-up meetings assuming it's three products. And you partner up with the engineering lead and or the scrum master and say listen, I know I shouldn't blur the line between my product owner role and your role as the lead and the scrum but help me out here. What can you do to offload me? And often it's an offline conversation maybe during lunch which is my favorite tool, favorite collaboration tool and it'll go a long way just to have that. And another thing in parallel of course is that's not sustainable. You can't do three, you can't do three, it's hard to do two and your manager is noticing and just reminding every so often like I'm here, I'm gonna do this but man, this doesn't scale. We have to maybe plan to bring on maybe an entry level PM to help me or whatever. So that's my recommendation. More wonderful questions. Yes, hello. Any particular caveats you should be aware of or make sure you cover when you try to develop your revenue model or pricing strategy? So the question is what tips do I have for coming up with a revenue model or a pricing strategy? So the great question. So the first thing I would do is kind of take a baseline. Where are you now? Are you guys just a technology and you're figuring out how to productize it, meaning basement level, meaning you're not anywhere near beta? All right, that's actually good because then you could be quite theoretical and kind of just use Excel and just kind of throw numbers into a formula. Are you in the market already? And you already got something and maybe it's not performing. Like oh my goodness, our revenues are maybe flat or maybe they, well, then pick the problem to solve is really my answer to that. What problem do you want to solve? Is it our revenues are flat or revenues are going down or we're trying to cost contain or our cost of goods too high and in a software company cost of goods tend to be royalties, not necessarily like if you're in a hardware company of course it would be materials. So isolate the problem first. Just like you're running MVP for isolate the problem. And then that will inform your model and if you're not comfortable with doing models because not everyone is, go to the person in your company that would be the most logical partner for you, business analytics or wherever and say, listen I want to work with you. I'm going to lead it but I want to work with you on this to make sure that we solve the right problem to solve and we come out. So you need to know how the company is making money now if they're making money. What if the strategy is don't make money now get a lot of users and then make money over here. So get all that's part of the baseline. Get all that down and then partner up with someone who can kind of work you through the model but lead it like you would actually defining a feature set and take it from there. Question over here. Yes sir. Hi. Excuse me. At least in the Bay are the four pillars the technical skills are probably the most important one. Can you share your thoughts around what are the technical skills specifically of them like the coding skills which you think are important that way and in your opinion what is the best way to start working towards that? Excellent. So the question was of those four pillars of product management it seems like the technical one is pretty important and what would be some ways to get those skills? Other than coding. Other than coding. Got it. So talk to your tech lead would be a great start and or if you have an architect who's separate from development engineering a lot of companies if they're bigger they have internet engineers developers, testers, architect try to get a lead on your team and an architect and meet with them separately and say listen I'm in charge of X I'm the product lead of this thing I want the basics so start with the stack the knowledge of the stack the tech, the overview what are you using for your database what are you using for your middleware that kind of stuff and that's a good start make sure you understand how the data flows through what are we coding ourselves what are we licensing if the data has to be stored is there any type of extract transform load to get all of that knowledge that's one good thing to do and if you want to go deeper than that you don't have to go all the way to coding some people love it some people don't try to be the champion of what I call non-functional requirements which is kind of a weird name because they are functional there's just nothing you can actually see these are intangible you don't click on these they're not front end so a non-functional requirement a great example is scalability or reliability or performance and I just love page load performance because Shutterfly is the number one thing if the page loads in more than two seconds you literally lose thousands of dollars a minute during peak it's that important so great maybe you have a product similar to that maybe there are problems there maybe not but try to get into some definition of performance page load performance the amount of time it takes to go out to a third party API and do six queries and come back with a result and try to be the champion of that and you will get way into the tech details sound alright? yeah and you added product analytics so thank you for adding that one yes hi they get more brought in on the process because sometimes because the developers may have their own views or how do you think the designers may have their own views to solve a problem so you have problem A and you want to make sure everybody on the same page but everybody is helping to solve a problem excellent thank you thank you so the question was there is a very important problem to solve and each team member has their own perspective and wants to solve it in a different way so how do you get everyone to align on one way to solve it more or less right? cool oh yeah that's classic product management so you need to take ownership right the D's of ownership so you need to get people into a meeting I wouldn't use the stand-up meeting for this I'd have a separate meeting and here's the agenda problem is this let's all figure out a solution just put it out there in the meeting invitation and then you are driving the decision you're not making, you're driving it right and just put the problem up on a whiteboard whiteboard my favorite tool sorry to keep saying whiteboard and say listen guys we this is the problem do you even think it's a problem do you agree let's just start there some people could be like this with their non-verbal communication great that's a good place to start because then you would want to ask why don't you think it's a problem that could take 30 minutes just to make sure everyone agrees let's say they do then start with like why don't we go around the table everyone lets just brainstorm I'm gonna go last don't go first product manager always wants to go first go last can we start with whoever this team member is how would you solve it and always remind people this is brainstorming this is there's no dumb answers you don't need to go out and have exhaustive data analytics done it's okay we'll do that later once we figure out what we think is the right way but I just want to hear from everybody and then of course take notes and summarize the meeting afterwards you'll be amazed that assuming everyone agrees it's a good problem to solve all the different cool ideas that come up with which may or may not validate yours the reason why you go at the end is because my guess is if you go through three or four team members one of your ideas is gonna be more or less validated but if it doesn't then great then there was a fifth idea right so this happens a lot I'm so happy that you asked it doesn't happen quickly even though you want it to be solved tomorrow it does not assuming this is a big problem define the problem make sure everyone agrees go around the table you go last and then once you get some consensus maybe it takes another meeting for consensus shall we try great thank you I'm gonna write up some stories and then maybe we can try to get them into whatever sprint so we can solve it they're starting to solve it yeah and they're working on it but they find oh sure they tell you to go back to the drawing board oh not yeah so that I hear you again let's assume this problem is very big and complex because that tends to happen in that situation then you need to chop up the problem into small digestible pieces that's the beautiful thing of stories and epics so the epic is this problem and then there's these tiny let's not do all the stories in one sprint they'll be bad let's do kind of prioritize them right and you're leading that as the p.m. and let's do maybe the first print let's do you know a couple or maybe one of these stories and then digestible testable usable great how did that go everyone cool let's go to the next one the next one now again there's time to market pressure all the time so if this is such a bad problem and we're losing and that's how I would recommend how are we doing on our time my pleasure what three more questions yes hi excuse me yes that's the kind of engineers I would just give them a request and they would just thank you for your word they wouldn't have to have a meeting about it let's just do it sometimes at the same day I've worked with engineers who are reluctant to do anything about a good process you get everyone in a room like you said you agree on what we're going to do in the sprint and once they agree to it they will do it and that works fine but there are also some engineers who are incredibly different people who don't apply the same rules to everyone else that they apply to themselves like for example did you say to them I would like to do this on this basis they will say you know give me a ten page document with all the data that backs up your conclusion whereas if you go to a meeting and say okay next sprint and they say hey we want to do this and you say okay where's the data to back that up if you ask them the same question they ask you they say I'll just take my word for it so in a situation like this where you're dealing with someone who doesn't basically play fair sometimes say consistently do you stick to the high road and essentially try to work with the framework you have or do you confront them and say look you can't do this so I like that question but I'm going to summarize it so a team member it doesn't have to be an engineering it could be any team member who doesn't want to apply the same process rules that everyone else is bound by how do you work effectively with that person is that more or less it cool so this is very important and it does happen and a lot of times the reasons for this person's behavior are actually quite innocent believe it or not so it's always good to I would have an offline chat with this person and say listen it's all about I notice that you want me to generate tons of data but when I asked you you said I didn't have to do it I notice that happened okay it's cool but let's maybe take a step back why are we here you know we're solving a problem for the customer it's the customer we're going to benefit if we all don't follow the same process then I would let this person know that I'm very open to changing the process it's cool with me let's make sure we get everything not that you and I get every process changed not that you and I agree to but the whole team like that pie it's important it's the whole pie it's not just two delicious slices it's the whole thing so let's make sure that if you and I agree to this quote-unquote new process let's make sure everyone else does it's the one that you don't like and that he likes or she likes and then flop it the next few months and then let's see what works best so try to test it be objective understand the problem and remind that you know processes can change a process isn't etched in stone it's not in big capital letters it's always changeable especially if you're doing agile now if you try that maybe you've tried similar without being helpful it could be a behavior problem but don't jump to that just try to just put behavior on the side just for a second and just understand where they're coming from and be willing to test out a new process if that's the problem or if you know you can try a data list if you won't want to which is ridiculous you know without data how are you going to objectively measure the success of your product and then say listen these are the bad things that will happen without this so do you really want to do that team member probably not but let's agree to what data it could be that he doesn't want to do exhaustive data collection when you ask him this question and maybe you just need to tell him I just want broad brush strokes it's okay anyway sorry I'm talking a lot but it comes up so yeah yeah yeah let's say let us let us own the product piece because he felt that his seniority his experience from the ability to effectively override products on the decision he disagreed with and obviously it's very difficult to talk to they could say look we don't tell you how to code don't tell them to product let us have our own pieces of the pie yeah you own this we own this let us work together but there's only so much there's only so much game you can give without kind of giving more of the keys the kingdom I'd like to speak with you after because now I see there's a difference here but after this if you could stick around because I have an idea sound okay another question yes yeah nice nice so the question there is if you come from a business background and you want to go into either product marketing which would be the better of the two roots is that yeah I think they're both equally awesome you know it's like I love ice cream chocolate or vanilla doesn't matter and if this is your situation you're in a wonderful situation you could actually try for both there are pillars for product management there's similar pillars for product marketing but the difference in my opinion is product marketing takes a demonstrable something that might be in early beta or whatever that is already fleshed out that actually can function and that the value is very demolable and then they take it to the next step which is finding customers to love it and acquiring new customers is hard there's a technique to it depending on what the product is and what type of market segments you're going for but then if you already have an install base the other part of product market is retaining a little bit of overlap because a lot of times you're going to ask for super cool features like growth marketing there's a lot of tech features that growth marketers need to get into the roadmap for them to be successful but if you take a look at product management as it's more conceptual at the beginning what's the problem before we start doing anti coding and then go through the coding and iterations and all that cool stuff and again product marketing folks I like to have that pie I like to have there as well if your team is deep enough to have both at the table sometimes not and just to understand remember that spotlight I spoke about the product marketers spotlight comes in kind of late not super late that would be bad but maybe early beta once it's demonstrable once they can actually see and then it's like great I need positioning statement I need key messages how are we going to acquire our customers with this marketing mix and this budget and what about stuff you like that's awesome stuff but if you want to focus on the more what I call inbound marketing the stuff that we spoke about here that would be more product management I think we have time for one more and yes so you're talking about ownership of the product yes and in terms of long term project management what is your view what is your how do you do your due diligence to hand off to stop owning that internal owning a product and moving on and having off to a different product so I want to make sure I understand the question correctly please thank you I have managed a product that I created over the last 10 years oh I it will no longer grow beyond what I can make of it I would like to hand off to someone who is kind of new in the company and I plan to leave the company okay my intent is to basically continue the product over the next what's going to be a 20 year run nice very successful product cool but it's there's the minutia in your brain of things that have worked and things that have happened and you've had a game plan and how do you responsibly hand off yeah next generation let's assume that the person to whom you're handing off has done product management before not an entry level person and understands the industry so it has some subject matter domain expertise which is terrific probably is no problem taking ownership or else they couldn't take on a product that has 10 years of success that's very very awesome I would hand it over to him or her at a very logical time in the life cycle of the product and here's I don't know how big your company is but maybe you have product roadmaps okay I get it probably runways maybe after you come up with kind of your product plan for the year just big broad brush strokes that would probably be a good thing for you to do once it is ratified or approved by the founder CEO the people who pay money for awesome people to make stuff then that might be instead of the strategy stuff which you've done which is important because you got the 10 years of success and the incredible knowledge of the install base and the metrics that are important to you maybe when it comes down to do the tactics like the MVP or the stories or whatever or maybe there's some market research because a small company maybe PMS have to do that which would be fine that might be a good because those are very discreet measurable finite tasks that you can walk him or her through mindful have they started yet? No it's one of those things where it's a private conversation that person will most likely be hired particularly for the pre-knowledge good when they come on when they get hired don't knock him over the head day one like I need this I need that literally spend a couple of weeks just having a knowledge transfer taking the the key metrics for example that's a great place to start on a whiteboard again the whiteboard and making sure that this person inherits and understands how we're measured do that first just because you've been in production for so long make sure they separate the solution space from the problem space because you still have customers that you haven't reached yet of course you have an install base and you need to retain but there's always going to be this new group of folks so try to get into that space first before you go into the tactics of we need this feature and we need this and I think Sam is over here