Transcripts
1. Class Introduction: Hi, I'm Josh Annan. In today, I'm gonna teach you about how to take a product, a blank page to something you can build. Whether you're at an early stage startup building its first product were in charge of a major new initiative at a big company. This class will help you learn the steps to go from concept to execution successfully with proteins to ensure you build something your customers love. Before we start, let me tell you about myself and why I'm qualified to teach you these skills. I started my career as a software engineer at Pixar, building the software we use to make movies. I switched over to production. And now knowing how we made our software, Intel, we made our movies. I often acted as an internal product manager without realizing it. Outside of work, I loved building products such as one of the first iPhone apps, flip book, which was incredibly successful. I left Pixar and move to tech full-time, working at many early-stage startups, trying to bring sci-fi to life. I worked at LOTRO, building futuristic cameras, at magically building an augmented reality device and embodied building a social robot for kids and more. Now, on the PM at roadblocks, building software that millions of people use. This wide range of experience has taught me a lot about how to go from 0 to one and how to work in an environment where you really have nothing but an idea. You have no customers, no product, no data, and so forth. I found this requires a completely different mindset than a typical PM role. And I'm excited to share what I've learned. I really enjoy helping PMs become better PMs. And so I really appreciate a great product and want to see more great products in the world. More iPhones, fewer Microsoft Kim's, please. In fact, I helped product school develop the curriculum they used essay scaled from a small boot camp in San Francisco to an international organization. And I wrote their best-selling textbook, the product book today in this class, I'm assuming you already know the basics of building products. And we're going to focus on a more advanced topic. We're going to talk about how to go from a vision to a product strategy to executing on that strategy. Early in your career, you'd likely worked on very tactical things like running an AB tests on a change to see if it moved to key metric as your career responsibilities progress, you need to know more about product strategy and how to translate a high level vision into a product your team can start building. This requires a completely different type of skill set that will help you develop. This class has six key sections. Will first touch briefly on vision and understanding what it is and where it comes from. We'll then dive into strategy and focus on how to start turning a vision into something you can begin executing on. We'll look at how to define tactical solutions to deliver that vision, and then how to do some initial validation of those solutions, potentially without writing any code to help you pick the best place to start. Finally, we'll discuss a bit about execution and how to really flesh out the solution you're picking in a way that your team can execute on and how to manage risk so that you deliver a product successfully. But before all that, in the next lesson, we'll talk about your class project. So let's get started helping you build the next $1 billion product.
2. Class Project Overview: No class is complete. Without practicing what you learn in this class, you're going to define a product based upon a vision I give you. Specifically, I'm the CEO of a fictional startup and we're going to build social games on top of video chat. I have this vision of using zoom as a platform to let people have fun at a distance in a casual way. Think about when you get together with friends and play a board game. How could we build that type of fun light experience on a video chat system so that it doesn't matter if weren't at pandemic. We're in different cities. We can still connect. I know I can raise money to do this, but I'm not exactly sure what our first product should be. I'm hiring you as my PM to figure out the details as we go through each lesson, you'll complete the next step of the exercise and add more detail to the product strategy and execution plan. First, we'll make sure you understand what product vision means and that we're aligned on the vision for this project. And that you understand the key elements of the vision to keep in mind when crafting our strategy. Next, you'll use the strategy videos to go define the key goals for the game, who our customers will be, and what problem we'll solve for that. You'll then learn how to brainstorm tactical solutions for the specific type of product we can build. You'll do some rough validation by getting customer feedback from target customers. Maybe even building a prototype of our game. And after you're confident with your idea, you'll use storytelling to write a user narrative for what the game experience will be like in define key requirements for the team to build. Finally, you'll assess the product risk to help determine what we should do first to build our game. Be as creative as you can be with this. And if you're worried you're not creative, Don't be scared. And easy way to jump start your creativity is to think about games you enjoyed playing with other people and how you'd want to play them over video chat To be clear, Someone like you might not be the customer, that's to be determined. But putting yourself into the situation can help spark ideas. This might seem daunting. So let's dive in and learn how to make it less scary. Starting with understanding what product vision is all about.
3. Understanding Vision: You often hear executives talk about vision or praise visionary leaders. What the heck does that mean? How does it differ from a company mission? It's pretty straightforward. Generally, the vision is about what you want the product to be like sometime in the future, usually five to ten years from now. It's not very tactical because it's quite likely we don't know this, but the specifics will be and they're going to change as technology changes quickly. But the vision will capture the key high-level guiding principles that will drive your product decisions in priorities. These are what your ideal product will be like in five years. For example, I think many people have a future vision of augmented reality glasses being lightweight, stylish glasses. They're fully aware of the world around you and have a great display where digital objects appear seamlessly next or real-world ones. And the images look great all day, whether you're inside or outside at the start. But it doesn't at all capture why a customer would want this or what role the product will play in a customers like. It's a vision of where the hardware could be, not why anyone would buy it. A good vision will also talk about the value the principles expressly provide to a customer. This is the why of the product. Why will it exists in the world and be worthy of someone's attention? In fact, a vision might even focused almost exclusively on the use cases. You can imagine a customer one day using your product who achieve and very little on the actual product. The use case can be high level or specific. For example, perhaps this vision of augmented reality glasses includes a principle that the glasses will make customers feel smart by ensuring what did, whatever information they want is always easily at hand. That's still pretty high level. So perhaps this division also includes a sample story of what the users day would be like wearing the glasses and what it's like when the information they need as always at hand. Maybe it talks about going to the grocery store and having turn-by-turn directions inside the store provided to you with items on your shopping list visually highlighted when you look at the shelves. Putting these two together, the good vision will have the key principles you want to achieve in five to ten years. Short summary points you could easily put into slides and we'll use to guide the priorities and decisions you make on the way towards achieving the vision. And a good vision. We'll have additional details such as narrative stories where sample use cases to explain why a customer will care about this vision. What value does it give them? Really think about what you'd like the product to be like if you had no limits, don't just describe the ideal V1 or V2. It's easy to underestimate what you can achieve in five to ten years. And when done right, sometimes product visions will seem like science fiction and that's totally fine. Everything we have today from electric carts and network pocket computers at hold. All of humanity's knowledge once seemed like sci-fi. In fact, there's a reason many folks myself included, encourage entrepreneurs and PM's to read sci-fi. Visions can also have multiple levels tied together. For example, when I worked at a social robotics company or 10-year vision, was to have multiple types of robots for people with different needs. And the robots could assist these people in different ways. We also had a specific long-term Product Vision. For the first product we were building a robot for kids. This vision was that the robot could be a true companion and listen to what the child was saying and react appropriately in a life-like way that provides practice with social skills. Now I know what you're thinking. Why not encourage kids to practice with other kids? Frankly, not every child has the opportunity or the skills to do so, but that's a different topic. It's worth noting. This is related to, but different from a company mission vision. That is, the company mission is a broader, even vaguer, more ambitious statement about why the company is building these products. Domitian is about every day, whereas a vision is about tomorrow. For example, Microsoft's mission is to empower every individual and organization to achieve more. Facebook's is to connect the world. Neither of those are product vision through not about tomorrow, but division for each product should tie into and support the mission. For example, it might have seemed odd a few years ago when Facebook bought Oculus VR in the early days of modern VR. But Facebook has a vision to build the multiverse like you read about and Snow Crash or saw I'm Ready Player one. This is a virtual world that you can go to where you can connect with people and do things you can't do in real life. True, social VR is the product vision. And it ties into the company mission to connect people. Who sets the vision. It can be many people, but some aspect usually starts with someone high up in the company as the vision will be used to align everything in the organization, not just drive product development. For example, at a big company like Facebook, Mark Zuckerberg set the build the multiverse vision and Roombas worth, who currently runs Facebook reality labs, sets the more detailed and ultimate AR VR vision that aligns every product they work on. And when put together those products from Portal video screens to VR headsets to future AR glasses, bring them universe delay. The product owner for the portal line sets the vision for that whole product line and product owners within the various features of portal set the vision for each feature. Yes, even features have visions. You want to know where you're taking it, how that long-term view lines up with the penultimate vision and mission and so forth. It's smaller companies. It could just be the CEO who sets the vision or maybe the most senior PM. There's a good chance that unless you're a junior pm, he will honor product vision soon, whether it's for a feature area or for an entire product. For a class project. I've given you the high level vision. I imagine a world where people can easily play any type of casual game that isn't a typical video game, card games, board games, and more via video chat. So that distance isn't an issue. It's up to you to define the long-term vision for the first product line we build in to figure out the details, just help us start building V1. If you're struggling to write a vision statement, step back for a second and don't worry about any of the technical details. Just imagine that you're the key user for your product and you're writing a story about what your products like in the future. What would it be like, and why would you want it? What would you want it to do for you? And what would the ideal interaction be like? Got it, cool. Tell that story. Now that you know what a high level vision is about, in the next lesson, we'll learn how to craft a strategy to achieve that vision.
4. Product Strategy: It's great to have vision, but often the product vision is too vague to execute on. There's a lot of detail left to fill in before you get to something you can start building. The next level of detail beyond vision is the product strategy. This is frequently the major piece of the puzzle that more senior PMs ONE, let's look at what strategy is and how to define one. Put simply, strategy is an analysis of how you're going to achieve the product vision. What customers are you serving? What customer needs will you address? What goals we will define your success? And what are the general steps you'll take to go from the current world to achieving the product vision in the outcome you want. Strategy starts with a solid understanding of your customer. Who are they? What need will this product Phil, and their life right down what use cases your product will let the customer achieve that either they can't do now or it's very hard to do currently. For example, you could imagine that a product vision years ago for the Apple iPod was select customers easily listened to any piece of music ever made on the go at a high-quality. One possible customer would be someone with a large music library at home for whom tapes and CDs were inconvenient and only held a small part of the library. The key use case would be to let this customer take their music library with them. So part of the product strategy to achieve this vision would be around building a portable device to let a customer who listens to a lot of music take their existing library with them. It's worth noting that a product strategy doesn't usually just focus on one customer and one use case. It's a plan that changes over time, taking a step by step towards the vision. For example, after letting customers with existing music libraries easily bring their music on the go with iPod, you can imagine how Apple added iTunes store to make it easy for customers without existing music libraries to purchase new music digitally. That's the next step towards achieving the product vision. When you're defining a strategy, it's not always clear what customer in what need you should focus on. First, just write down all the possibilities and then you can think about how to stage up later. If your product visions vague, it's possible there are multiple needs for even one customer will let alone varying customers. Again. Just write them down and prioritize them later. In addition to a customer's pain points, it's worth articulating what your goals are along with your non goals for each phase. What do you want to achieve and what are you explicitly not going to worry about achieving? For example, the PM at Facebook, who own messaging might have a strategy goal around unifying all of Facebook's messaging tools to work across applications. But a non-goal IF integrating with third party messaging systems, writing goals helps keep you focused and writing down non goals narrows your focus even more. Let's pause for a second and think about your class project or video chat game exercise, list out possible customers we could target. Next, write down what we want to let each customer do. That's currently impossible or very hard to do. What goals do you think we have with our video chat game? Consider articulating goals around connecting people through gaming and a non goal of providing an alternative for hardcore gamers to existing tools like discord. Of course, that's just my thoughts. You can take this exercise where ever you want. Another part of strategy is defining how are we going to measure success for the product. Defining the key metric will help you make tactical choices later about what features to build as you want to focus on features that contribute to the key metric. This metric could change as we execute on the strategy that at the end of the day, how will we know if it's worthwhile for the business to try and achieve our product vision. Now of course, we could level high level things like net promoter score. Our customers happy with this product and would they recommend it to a friend? But how can we tie that metric to our company goals? For example, perhaps initially with our game, we'll focus on getting a target number of customers to spend a target amount of time playing our game. Focusing on people successfully adopting the product and using it is often a good first step for new products. Perhaps the next phase in our strategy focuses on growth. How many new players can occur in player bring, what percentage of those new players do we retain and so on. A final part of the strategy that sometimes worth writing down is how do you differentiate versus the competition? Even if you have no competition when you start initially. Although that's highly unlikely, at some point competition will emerge. What are the key principles or things you want to maintain throughout every step that will differentiate you from the competition. For example, with some projects I'm working on now, like company values, making things that just work for our customers no matter what customer or device they're using. Things need to be easy and they need to scale. That's different than how our competitors were, where their customers prefer control over automation. Whenever I build a product strategy, I make sure to call out what we'll do to make sure the strategy as ours in consistent with these values from day one. Finally, let's talk about bad strategies for a second. Sometimes it's easier to look at what you're not doing, but could be building. For example, Samsung and LG make washing machines, but Apple doesn't. Samsung and LG are competitors and the phone market. So maybe Apple should make a washing machine. Well, that's not a useful strategy because it doesn't take into account factors like what unique and differentiated thing could Apple bring to the washing machine market? What unmet need to customers with washing machines have now that Apple could bring their expertise in UX manufacturing and more to solve how to washing machine fit into the product ecosystem. Just because your competitors are doing something you're not, doesn't mean that should drive your strategy. To sum it all up, product strategy is about breaking down how we're going to achieve our product vision. What products will we build? For? Whom will we build them? What problems will they solve for our customers? What use cases will we enable with her products? What goals will the products have? Why are these the right products for us to build? And how do we measure success? At this point, you should be ready to write down rough ideas about what problems we're looking to solve with her video chat game, who were going to solve them for what goals will achieve and how we'll measure success due. So don't worry about what specifically you should build it each step and how to organize your ideas into a staging plan will discuss that next. You might even have some rough ideas as to what we could build at each step. So just write down how you think we should stage them and turn them into a phase strategy. What should you build for each step? Will discuss the details next as we switch from strategy to tactics.
5. Making Strategy Tactical: At this point, you should have some thoughts about who our customers will be, what problems will solve for them, what use cases we want to enable them to achieve, and how we'll measure success at each step. But your ideas might not be organized or prioritize. And you might not have thoughts about what you can build in each stage to address the customer's need. In this lesson, we'll look at firming up or product strategy and turning it into a series of phases that will take us from today's world to the product vision. Unfortunately, this process is more of an art than a science because every situation is different. So I can't give you a five-step plan to come up with a great product strategy. But what I can do is give you factors to consider in tips about how to think to help you make a strategy for your specific situation. First, I like to brainstorm a list of possible products we could build that all work towards the vision. These products don't have to be detailed, that'll come later. But just some general idea of what product might be alike in various phases. Helping you brainstorm ideas is beyond the scope of this class, but similar to establishing a product vision, I found it helpful to focus on a specific customer and specific need and think about if there were no limits, what would I like to build, to solve that meet to help solidify what these possible products look like. In my mind, I like writing a short narrative about how the solution will fit into a customer's life. I find that the narrative feels forced or awkward. It's probably not a good idea that a customer will actually use. If I can easily imagine the customer using the product, I'll keep the idea. Next. I tried to step back and assess if there's a really simple product we could build first, that feels like the first step towards solving the ultimate product will go into detail in a later lesson. But sometimes there are key risks that you have to address first, that mean you have to build a hard product first. Often there are a couple of products that could be a good first step when I'm making my recommendation for which to do First, I'd like to assess how easily we can build the product, how hard it would be for a customer to adopt the product and how well the product would solve the customer's need. Of course, there are always external factors to consider. Often your boss or someone higher up will have strong input as to what you will work on first. After I've thought about where to start, I'll look back monks my ideas and continue to assess what the incremental steps we can take art building off the previous steps to help us go from now to the world that their product vision. Secondarily, I'll use the goals I defined in the last lesson to think about how to stage these steps so that a moving closer to my goals. When I put these steps together, I should be able to tell a comprehensive, insensible narrative about how I'm going to go from today's world to future world with the product vision. That might seem a little confusing. So let me give you a specific example. Think about Tesla. Their vision is a fleet of electric self-driving vehicles that are better than every other vehicle on the road. Obviously, there are a lot of types of vehicles that they could build, but different customers. A truck driver has different needs than a soccer dad. But Tesla had some major risks and challenges to overcome. Could they build an electric car? Could they manufacture at scale? Could they build an autonomous car? That's a lot to figure out. Elon Musk famously wrote their product strategy and the blog post. They started with the high-end electric car. They didn't need to worry about manufacturing at scale, autonomy or even cost. They just focused on building an electric sports car that was better than any gas sports car. Then they took those learnings and focused on making it cheaper and building with the certain level of scale that was in Model S and the model x there, not every man's cars, but they let Tesla use learnings from the Roadster and scale-up manufacturing, service sales in reputation. They also started building autonomy systems and gathering the data needed to get the to increasing levels of autonomous driving. Finally, they built the models three and why they took everything they learned so far to the next level and scale it all up, building their most popular cars. It's possible somebody argued that they should have tried to build the model 3 first, build a mass market car to bring electricity to the masses as soon as possible. After all, any company, once they get customers and revenue fast so that they can thrive. I think Tesla would have failed if that was your strategy, because look at all the things and model three, buyer would expect fast charging for road trips, convenient service, good range that are quite hard. And these things take a lot of time and money to learn how to build. Conversely, someone buying your Roadster but a different needs, an early Tesla could build a great product to address those customers and then build on top of it to address the Model three customer. Now you might be thinking that a product strategy sounds a lot like a product roadmap. The high-level idea is similar. What steps are we gonna take to reach an outcome? The differences out roadmaps are generally focused on short-term tactical activities to execute on. Roadmaps have specific defined deliverables. The product strategy is a bit higher level and the details of each step might be a little fuzzy, but the goals, customer and so forth will be clear. The product strategy will be used to define the roadmap. For example, we're going to build the Tesla Roadster. That's our goal. At the strategy level, the specific details of the roads are likely vague, but there are key goals like super car level acceleration. The first step in building the roadmap would be to flesh out all the details of what the Roadster will be. And then we'll break it down into a roadmap plan that we execute very tactically in day-to-day on to get from nothing to the Roadster. Of course, it's never that smooth in the real world, but that's how it works on paper. Also, while I'm repeating myself, do make sure that for each stage and your strategy, you define who the solution is for and what problem you're solving. Customers don't buy and use products that don't address a need and will. Let seems like having those definitions in mind is obvious. Many products seem to ship without them. For example, over the past few years, Microsoft has switched to a strategy of making their products and services available everywhere, rather than requiring you to come to Windows. At the time of this video recording, they decided to re-enter the phone market with the surface due up, which is a dual screen folding device that runs Android and not a Windows-based OS. But it's completely unclear, at least to me, looking at their product marketing material, who the duos for, and what specific use cases it's folding design enables that are better than what you can do on a single pane phone or tablet. It's unclear if this folding device can replace both the phone and a tablet. And if you read the reviews, they all say that the hardware is brilliantly built, but it's unclear who should buy this and why. Make sure your product strategies don't have the same failing. To bring this all together. Organize your product strategy into sensible phases that build off each other and let you ultimately achieve their product vision. Take care about what you pick for product one, make sure you're picking something you can successfully deliver. That solves a need for customers. Don't try to boil the ocean, doing everything with the first product, focus on the most critical pain points to solve that you can build upon and make sure to account for changing customers goals and success metrics between phases. Looking at the class project, I want you to put together a product strategy that defines what we should build first, who it's for, what it lets us customers do, and how we measure success. I next want you to put together notes for the next couple of phases, or do we do next? How do we get to a world where a billion people Player a casual video chat games to feel more connected. Write a story about how these steps Connect and why you believe the first phase is the right first phase. Now that you know how to build an organized product strategy. The next lesson we'll introduce you to product risk management so that you can determine what through really start building or prototyping first.
6. Managing Risks & Challenges: Whenever you start from 0, whether building a major new product initiative or making a major change to an existing product, you're taking a bigger risk than if you simply made an incremental improvement to an existing product. Let's talk about how that factors into prioritization to help make sure you take the right first step. I've consistently found that new products have two major buckets of risks. The first are the unknowns. These are new things that haven't been done and you're not even sure if they're feasible. There could be something technical. For example, on one product I worked on, we weren't sure we could get accurate speech recognition with children. And the product we wanted to build dependent on that. Another major risks could be around how a customer interacts with the product. For example, iPhone dependent on multi-touch working. But multi-touch hadn't been done commercially at scale before. Sometimes risk is also around customer behavior. They'll customers written videos for the male rather than going to a store. The second bucket of risk, because about challenges, there are things that you believe are doable but are hard and will take time and effort to achieve. These can be easy to dismiss when you're faced with true unknowns. But challenges are important to keep in mind because not accounting for them can kill a project. Whenever I'm thinking about how to stage your product strategy or roadmap, I make sure to take time to write down the key unknowns and challenges I will need to solve to achieve the product vision. Then I prioritize within each category and finally, across categories. What I mean is that unknown one is more critical to solve than unknown too. But I might need to solve challenge a before unknown to. Once I have that prioritization, I'll take that into account for my recommended product staging. I might not want to build the easy thing first, but rather the thing that addresses the biggest unknown or challenges, the things that can kill my product before it's even started. Going back to our Tesla example, we could imagine that building an electric car is a challenge. And not none, no. Electric cars had existed before. They just haven't been good. Building a car with decent range as an unknown, building an autonomous car, even if semi autonomous One is a complete unknown, building a charging network is a challenge. If you weren't practice, keep going on your own and breaking down what we're likely unknowns versus challenges for Tesla. Hopefully, you see that it makes great sense that they focus on the biggest risk. Could they build a great electric car before worrying about other risks like building a charging network. When I'm tactically executing towards a goal, which we'll talk about shortly. I follow these same steps and define and prioritize the risks. It's easy to get overwhelmed by the risks some projects involve. I've found that setting up demo milestones is a great way to ensure my team is successfully solving the risk. Essentially, I will define a milestone specifically focused on addressing a particular risk or two. I'll make sure to narrow the scope to call out what we need to worry about and what we don't. And I'll also call out if we're building a proof of concept intended to be thrown away or something, we're going to build on later. You could imagine Tesla calling out a milestone about building a battery that provide a certain amount of power and having tests units completely separate from cars to work on just the battery risk factor as another example. But one startup I was at, the foundries had a vision of building companion robots, starting with a robot to help kids with their social emotional skills. There's some q dress. Can we build a robot? Can we build a robot personality? Can we make the robot autonomous and voice driven? When I joined the team, they had essentially a systems test robot to show we could pump mature robot and make it have personality. The next thing we did was to focus on a demo showing that we could add a voice UI and autonomy while still having character and personality. All of this was designed to help us learn what to do later. It was designed to be reused if possible, but thrown away if needed. Even though we throw away the hardware and software platform we use for the demo, all of the learnings we had about how to build the character. How did you the voice you lie and so forth, carried on to the final product. So when you're starting from 0, whether you're building your product strategy or product roadmap to deliver a phase of the strategy, makes sure to list out all your risks, prioritize them, and consider how to account for them in your milestone staging, often, you'll want to focus on de-risking the product in step one. Demos are a great way to keep progress focused on a particular risk item. Just make sure to keep the demo scoped appropriately. It's not a useful demo if the milestone ends up being build the whole product. A class project, I want you to make a list of all the risks involved in the product strategy you currently have. Prioritize it. What do we need to address first? That everything else depends on what's next. One major risk IC is around customer behavior. Can we get people to play games via video chat? How does your strategy is rest that? How does that risks priority balance against other risks. After you've done your prioritization, reassess the first product, are recommending that we bill. Is our product feasible or is, or too much risk to actually do it? Is or another product that's lower risk and would make more sense to build first, if there is one with lower risk, what's the customer value like? Is it worth doing a less risky thing or should be pushed forward and figure out how to do the riskier product because it's better for customers. Revise your strategy, phasing, keeping risk in mind. Now that you have a strategy that includes addressing key risks and challenges early on, it's tempting to want to go right to building. But what if you're building the wrong thing? In the next lesson, we'll discuss ways you can do some customer validation before building anything to ensure that tangible products you want to build or actually sudden thing customers will want de-risking. A major part of your strategy. Will anyone want this product?
7. Validating Your Ideas: At this point, you should have a product strategy together. You should have a recommendation on what type of products will build, in what order, why we're building that way, but problems we're solving for our customers and more. But what if you're That's often what keeps me and other PMs up at night. Before diving into building something, where sometimes even before presenting a strategy to others, I find it very helpful to do whatever validation I can to help make me more confident and to plan or to change it. If I find out I was wrong, I have consistently found the most valuable thing to validate early is if I was right about who that customer is and the pain point I want to address. The easiest way to do so is to try and talk to some of these customers, whether via interviews or surveys. Now to assess if you've actually found a customer or if it's a real pain, it's also really important to ask them with currently doing to address the pain point, not if they wish to address it. For example, if you're building a language learning product, don't just look for people who said they want to learn any language. Because many people will say they want to learn a new language. Asks what the person is actually done in the past six months to learn a new language, far fewer people will have taken these actions, but the people who have actually taken steps to address the pain or your real potential customers. This dilemma is called the Ideal Self versus real. So people will always say they want to be better than they currently are. So if you want meaningful information, asks what steps we've taken to achieve a goal or address the pain point. Furthermore, I want to make sure that the pain point I'm planning to address really is a big pain point and that it's worth whatever my solution will cost to the customer to Saul. That might be confusing. So let me explain. Imagine I'm building a new type of washing machine for sheets that's guaranteed to make white sheets white without bleach, no matter how yellow they are. And I think I'm going to build it for the average family consumer. Now personally, I have white sheets and they are a pain to keep white. I currently spend money buying products to help me keep my sheets White each time I wash them. So far so good. But imagine my hypothetical washing machine. It's going to cost $10 thousand. If you find that I currently spend about $10 a month and products to keep my sheets white. Chances are I'm not going to be willing to spend a 100 times more, even if this new washing machine works better. On the other hand, if I talked to a high-end hotel, perhaps spending $10 thousand to have great sheets is absolutely worth it and I'll buy ten. Sometimes it can be tough to determine if you can build a solution at the price point a customer will pay. In those cases, I usually look at the severity of the pain and how convoluted the solution a customer has. If the pain points real. Chances are the customers solving it today. The more convoluted or expensive of a solution they're currently using, it's more likely that I've identified the right customer pain point and founded something they're willing to pay. Four years ago, I worked at a photography company called light truck. We made a special type of camera that let you refocus your picture and change perspective slightly after you took it. We were building a consumer camera. But it turns out that consumers didn't need this feature, especially with the image quality trade-offs are product tat. Existing camera's autofocus was good enough that focus wasn't a problem. However, I always thought that we should have targeted the video market as soon as possible. Because if you look at professional film shoots, there are dedicated focus pullers, people hired specifically whose only job is to make sure the focus gets sets right. Focus is a much bigger and real pain point for that market. Now talking to customers is a great initial way to validate your ideas. Talking to a few customers usually gives you a small dataset, but it's nice because you can ask follow ups. You can often extend these questions into surveys to get quantitative information about what customers are doing. Now, building a good survey is an art in and of itself. We're not gonna go into detail here. But one important thing to be aware of, especially when you're building a new product, is that there's a good chance people won't have a good frame of reference for this new product. This can make it hard to get reliable information out of a survey. For example, I've mentioned I've worked at accompanied building companion robots. Most people have never had a companion robot. Even though in the surveys we did, we tried to roughly describe would it be like the people filling out the survey, you really didn't know or have a good reference for what living with a robot would actually be like. This meant that we had to take all the answers with a grain of salt. But having some sense of general trends in Preferences helps us validate key ideas before building anything. Occasionally, you'll be able to build a prototype. Theres some sort to validate your strategy. Prototypes are great because you will have a much better idea of how a customer reacts to that potential product. You might discover needs you didn't anticipate. Prototypes don't mean you have to write code. The simplest one you can do it would be a manual prototype where you're actually doing the task for the person. Here, the customer is aware that there's a human involved, but that's okay. Can you imagine how you might make a manual prototype or her video chat game? Perhaps you can act as the game facilitator for a group of people to see if your idea works. Now obviously, manual prototypes don't scale, but they're quite useful as a quick and dirty way to see how your solution addresses a potential meet. A variant of a manual prototype is what's called a Wizard of Oz Prototype. Here, you make it look to a customer like a process is automated. But behind the scenes, humanist making things work. For example, with the autonomous robot I worked on. We had a Wizard of Oz Prototype where we could control software with preset things that we could make the robot say based on what the user set. It's definitely not as good as if we had the full autonomous product. But let us see how some human robot interaction work. And it helped inform the autonomous product. If you have time, another prototype you could build is called a fake door prototype. This essentially means you make it look like your product exists. But when someone clicks to use it or clicks bye, you tell them it's in development and potentially asked him to sign up to be informed when it launches. This is a way for people as a way to see how many people register interests in your idea. This prototype can be tricky if you're starting a new product though. With the new project, you'd build a fake website that promotes the products you intend to deal. The challenges that people might not organically discover the website. Data about how many people sign up isn't necessarily conclusive. After all, most new products have strong marketing efforts behind them to help make them successful. Faked or prototypes work better for new feature initiatives on existing products. You can add a button, you're such an existing website or product and see how many gate existing users click to try and use it. I should mention that all of these validation methods aren't just valuable when determining a product strategy and where to start. They can be helpful tools anytime you have an unknown and want to try and gather customer data. At this point with your video chat game, you should have a rough idea as to what your product strategy will be overall and what the first product would be like. Come up with the validation plan for the first product, especially in try validating. This could be anything from finding potential customers and asking if they do anything like what you have in mind and getting a sense of how awkward it is through running a few video chat sessions yourself and facilitating a game. What assumptions that you make about the first product that we're right and which ones were wrong? With your idea validated strategy in mind, and a roadmap defined. It's time to start building. The final lesson. We'll walk you through tips and how to start executing your strategy in defining the minimum viable product you want to build.
8. Execution: You should have a pretty good idea of what the first steps towards achieving your product vision art. Now, we need to make sure we successfully execute the step. State your strategy can pan out so that you can adjust it as needed. This is likely more familiar territory for you, but it's still worth going over some tips to help you go from a high level description of the first product to a set of defined requirements that make up your minimum viable product, otherwise known as an MVP. Even if it feels like you have a good definition of what you want your product to be. Chances are there's a lot of detail missing that you need to flesh out to help your team execute successfully. And that detail can make or break your product and therefore your strategy consistently, IF found that useful to write a document, spec, a product requirements document or PID, where ever you want to call it to capture some key details. Writing these details down will help align your team. Also, note that this document will be a living document. You'll update it as a team builds and as you learn more, the key things to write down or one, what's the high level description of what you're building to? Who is this for? Three, what are your goals and non goals for? How will you measure success? What are your KPIs and what are their metrics you want to capture? And finally fought a narrative story describing how the customer will use the product with broken down requirements. The first force should be quite familiar to you. Let's focus on the narrative. Most PM's don't do this. I have consistently found that it's helpful to write prose about how a customer will use your product for three major reasons. The first is that it helps other people better understand your vision for this product and how it solves a problem for a specific customer. The second is that if you find yourself writing really awkward sentences or sentences that seemed dishonest to make the story work. Chances are this product isn't right for this customer. Writing a narrative can be part of validation. And three, the details that you put into an exclude from a concise narrative can help you prioritize the features to build. When I write a narrative, I do my best to be concise, not add lots of extraneous detail to ensure that the key product features or clear. I also do my best to avoid being prescriptive and specifying how things work. And instead, I focus on what the user is accomplishing with the context they accomplish it in. And I let my design and engineering teams determine how they will achieve the task. For example, rather than saying Bob reaches out and Turing's a door knob to open a door. I'll just say Bob opens a door. Perhaps would be better if this was an automated door or sliding door, rather than having a door knob. Pay close attention to the pragmatic limits your product has, as you write your narrative, called them out. This helps you maintain an honest assessment of the friction and trade off that your product requires. For example, if your product requires a customer have a camera that's on all the time, are they going to be okay with that? It probably depends on the situation your customer uses the product in. So make the framing clear in your narrative. After I've written out my narrative, you'll find that a natural conceptual grouping occurs. For example, first-time usage, daily usage for the sequence of key tasks, edge cases, and so forth. I'll go section by section and add a table with four columns in my document. One column is the user requirements. I'll turn the pros I wrote into explicit requirements often in the as a persona, I want loss that I can blah, format. The next column is an example, and not every requirement needs an example, but I've found that providing an example can let me write my requirement and non-prescriptive fashion will explicitly saying what I mean with a possible implementation as an example, An additional column is for notes. Sometimes requirements just need more explanation or documentation of discussion. Again, not every requirement will have notes. The final column is for a priority. Once I've written my requirements, I'll go back through and fill out the priority column. Anything that's critical to ship is a p one. Anything that be good to have, but it isn't essential to Zip2, anything that would be extra nice, but I don't really expect what's going to happen as a P3. You might be wondering why it's worth capturing P3s at all. I frequently found that especially with new products and many people have lots of ideas as to what the product could do one day. Writing those ideas down ensures that the stakeholders feel hurt. But if the idea of really isn't critical to the product are critical for V1. Capturing it as a P3 makes it clear that you'll likely reassess priorities as you build and sometimes even adjust requirements. Be strict about what's a p1 and what isn't. Products always take longer to build an estimate it if you truly must have all the p1's, the ship, the more P1's or are the longer shipping will take. I frequently found them model called the Kano model, helpful for both prioritizing and defining features on a new product. Or the kinda model starts by grouping features into three categories. There are table stakes features a customer just expects and wouldn't even think to ask for, like having Wi-Fi on info. There are the satisfying features a customer will ask for, like make it faster and there are delayed or features that a customer wouldn't think to ask for, but that makes a product special in differentiated, like when Apple released face ID for the iPhone, the Cuno model also illustrates how much investment versus reward you get with features. You want to spend the least amount of time possible in table stakes features because more effort doesn't yield more customer satisfaction. The features that a customer asks for generally have a linear relationship between how much investment you make and how much happier the customer is. The lighter features, you'll have a lot of satisfaction. In an ideal world, they be easy to implement, but often delighters or the unique things about your product that are actually really hard to make work well and they're gonna take time. Remember that some delighters will be P1's. If you ship a product that doesn't have features that are unexpectedly delightful and solve a user pain point in a frictionless way, your product won't be special. Too often, people assume that an MVP just means the bear features to make the product operational. A better definition is that it's the critical set of features to solve the users need and a great way without over solving. If you don't have any delighters, then your products is likely just a copy of an existing product and not differentiated. After you've done your prioritization, review it with key stakeholders and make sure everybody's on the same page. I should mention that this might sound like a very waterfall process, which is going to leave a bad taste in some people's mouse because of course, Agile is what's hot. Truthfully, new products tend to be a mix of both approaches. You need some definition of where you want to be. But the exact path you're going to take to get there is going to constantly vary based on what your team learns as you execute details. So the solution or even in a change, treat your user narrative and requirements as living documents and continuously update them as you learn more, just make sure that you're always still solving the user's core problem in a way that's better than what they do. Now, going back to what we mentioned earlier about risk-management, also sometimes list out the unknowns and challenges and my spec document and define the prototypes we're going to build to de-risk the project. Putting this together, once you have a high level idea of the first product and your product strategy, go into detail to help get everyone on the same page write a spec that includes who this product for, what problem it solves, how you measure success and narrative of how the customer uses it and prioritize requirements. And remember that this document will change as you built, but always ensure you're solving a real problem for a real customer. It doesn't matter how well built your product is or how many cool features it has. It doesn't solve a pain point for a customer at a price they can afford. Looking at your class project, you probably see this coming. Last step I want you to do is to write a narrative and define the MVP for our first product. After you've done this, you should have an idea that you could take to a designer and engineer and actually get built. And if you do so, and it becomes a hit, let me know.
9. Wrap Up: I hope the idea of starting a new product is a lot less scary to now. In this class, we've covered how to take a very high-level product vision and turn it into a phase product strategy with all the key details define, we then paid close attention to how to pick what product to tackle first, especially considering the risks that new projects have. We looked at how to validate your approach to help make sure you're solving a problem customers actually have. And finally, we briefly looked at how to go from a high level concept, an actionable MVP defined in a way that your team can go Bill. There's one thing I want you to remember from this class. It's that when you start from 0, you have to always stay focused and solving a customer pain point in a way that has acceptable tradeoffs that you can deliver at a price of customer will pay. And make sure there are enough customers to keep you in business. Once you've finished defining what video chat game you build, first, share it with your classmates so that we can all take a look. I can't wait to see what ideas you come up with. Thank you for attending my class and I hope that this has helped you become a better product manager.
Josh Anon, Product Manager
