 Hi everyone. Good morning. Thank you for joining me today for the product school webinar. My name is Nausin. I'm a product manager at eBay prior to being a product manager in my previous lives. I have been an engineer, UX researcher, designer and finally landed in the product world. It has been a wonderful learning experience for me and I hope today I can share some of those with you all. I will be talking about building a product from the ground up. It is of course an extremely simplified step-by-step guide but can also be utilized at any phase of the product lifecycle. Let's jump right into it. The way I like to break it up is in seven different stages. I go from ideation to idea validation to defining solutions, evaluating the solutions with the users, building an MVP, launching the MVP and then test, learn, iterate and repeat the process. The first step to any product development, whether it is a new product or an existing product, we always start with ideation. In this space, we want to focus on the problem space, which means understanding who the customer is and what problems we are solving and why. At the end of this space, we need to have a very clear user persona in mind and the problem we want to solve in the form of how might be questions. Let's start with customers. How does one go about identifying customers? Depending on where we are in the product lifecycle, we can utilize multiple methods to identify our customers. If there is a specific problem space in mind, we can start by doing interviews, user research, reading existing articles and reviews, doing online news. We can also do competitive research, ask our users to show us how they're solving the problem today, what are the different tools and services they're utilizing, things they would want to improve upon and those can really help us guide into the problem space that we should be looking towards and also help us understand our users better. At the end, we want to create a user persona where we identify our targeted audience for the problem and their struggles. In the slide, you can see that there is a product school resources which gives you a guide, step-by-step guide into how to create a persona. This is an example of a persona. We have information about the user's details, but also their goals, motivation, along with their struggles. There are many, many benefits of having a user persona. Some of them are it really provides a common language for discussing users internally within your team. It helps maintain a very user-centric mindset throughout the design and development process. It also empowers rapid alignment when we are making early design decisions or product decisions. As we have our persona, the next we want to do is to define what is the problem we are trying to solve. After understanding and studying our user struggles, we have to land on a problem we are focusing on and write how might we questions. The how might we question statements are small but extremely powerful because it allows us to reframe our insight into an opportunity based on the user problems that our targeted audience are facing. It really helps us give a direction to the product journey. We can come up with more than one multiple how might we questions. So the way to decide on which question we need to focus on, we can do a dot voting where everyone goes around the room and reads the how might we question and puts a dot vote on the question that they think we should be solving towards. Once we have the targeted users and finalize the problem we want to solve, something that I prefer doing is actually going back to the customers and validating our assumptions. Because often we can misunderstand or misrepresent the information we get from our customers. I have had experiences where we assumed a user is frustrated by the number of clicks it took for them to find a certain information. But after doing more research and digging deeper into it, we realized that the information itself was irrelevant that was bothering them rather than the number of clicks or the interaction it took. So often we can misrepresent and end up working on something that the user does not want or it's not the right problem space. So it's always good to go back to the customer and validate our assumptions before we jump into solutioning. So what do we need to do is go back to our users, validate the problem space and all the assumptions we have made. It could mean doing a quick check-in with the users we have already spoken to or going to a Starbucks and doing interviews with people who might fit the persona that we are targeting or just talking to colleagues who fall under the targeted users. But doing this validation is very important before we jump into solutioning. While doing the validation, it also gives us an opportunity to ask more questions to the customers and understand how they're solving the problem today and what are the solutions they have in their mind. That information becomes extremely helpful for the next space, which is defining our possible solutions. Defining solution is an extremely important but also fun process. Here we get to be creative and think outside the box. There are multiple methods one can use for defining solutions. My personal preference is always starting with a team activity session before doing any kind of design work, especially when we are focusing on new problems. What I like to believe is five brains are better than one. We have done a few things depending on the project. One of them was doing a brainstorming session with my team, where everyone gets a bunch of sticky notes, you write possible solutions on that sticky note, you put it on a wall, everyone goes around, reads the solutions, you group them together, and then you do a dog voting to decide which solution we would like to test out with our customers. We can also do a crazy eight, which is an eight-minute long process where every minute we come up with a new way of solving the problem. This forces us to break out of the regular process and really push our boundaries to be creative without overthinking. Each person decides on the solution that they would like to elaborate and the whole team goes around looking at the possible solutions and at the end we do a dog voting to find the winning solution. We can also do storyboarding where we take the problem and create a scenario around the problem and solve it in a storyboard. This allows us to create a user journey and solve a very specific problem while keeping the user in mind and the specific situation they might be in where they're trying to solve that problem. At the end of each phase, we want to come together as a team and vote on the solution we think are right for the persona and user problem we have identified early on. This really helps us make sure that the entire team, everyone, stakeholders who are involved in the process are aligned in the direction of the product that we are going towards. Once we have our winning solution, it is time for us to evaluate that solution. The evaluation phase is broken into three steps, creating prototype, testing with users and repeating it until we figure out what features should be going into our MVP. Now, I always suggest starting with low-fidelity prototypes for evaluation before going into any kind of high-fidelity mockups or defining features for MVP. The reason for that is it's easier to build. It costs very less. It's much easier to make any changes so iteration is much faster. It really helps user focus on the high-level concepts rather than the details of the prototype itself. It also helps detect and solve problems at an early stage before investing a lot of effort and money into building out the solutions. There are multiple methods that one can go about to create low-fidelity prototypes. One of them that I have used a lot in the past is paper prototyping, where you can draw with freehand and create working prototypes by just changing one paper on top of the other. It really helps the user understand the product flow and help them focus more on the high-level goals rather than the UI of the product itself. We can also have very simple wireframes with boxes and circles. It also gives a very nice overview of the solution to the user and they can understand what happens as they click on one button, what pages can show up. Again, really keeps it very high-level, really focusing on the UX of the product rather than the UI. Next, we can also turn those wireframes into applicable prototypes with a lot of tools and software that are out there. It's still pretty low-fidelity where we are using boxes and circles to create that user flow. Now, we can make it clickable so that people can click on it and really get the feel of how the prototype or how the product is envisioned to work. Once we have our prototype, we need to go back to the user and ask them to test it and give us feedback. We want to focus more on functionality and high-level features rather than the execution details. For example, in a previous role, we learned that users wanted to get feedback from their clients on our platform, which means a communication feature was missing. Whether this communication feature needs to be a chat or an email does not need to be identified at this space. I like to iterate this process and keep building a high-fidelity prototype and test with users. I also like to time box while building prototypes to make sure that we are not spending too much time and effort while testing and getting closer to the feature requirements we can use for our MVP, which brings us to our next phase, building our first MVP. But before that, what exactly is an MVP? A minimal viable product is the first version of our product that is functional enough to solve the core user problem and help us gather feedback. It allows fast learning and reduces cost of failure. It helps us get out of the building instead of working on our idea without any feedback and really get that customer feedback loop going. Overall, it really minimizes the risk of building the wrong product. For example, an example of an MVP could be that when the Airbnb founders did not have money to build an entire business, to validate their problem and solution, what they did was they created a very minimalistic website and published photos and details of their own property and found that several paying guests were willing to rent out their space. By doing this very small MVP test, they were able to find out that there is a market for peer-to-peer apartment room sharing. Now deciding what features need to be part of an MVP can be difficult because there are so many things we could be building and doing for our users. So to keep ourselves on track and make sure we build the right thing, we can follow a few prioritization methods. What I use is a prioritization matrix, understanding the low hanging fruit to achieve the highest impact. For example, here you can take all the different features ideas and put them in this matrix of how much impact it's going to make versus how difficult it is to build a feature. This allows us to identify the low hanging fruits and prioritize them. This is especially very useful for any kind of new product space. We can also use an impact versus urgency matrix. Here you can take all the different features ideas and put them in a matrix of how much impact it's going to make and how urgent the feature is for the user to solve the problem that they're looking at. This helps prioritization post-MVB as well. So it's an ongoing process that we can utilize after we have launched our first MVP. Another method one can use to prioritize features is the feature bucket. Here we take all our features and we put them in three different buckets. The first one is customer request. These are features that customers have been asking for. These are not necessarily a metric mover. They might not have the biggest impact when it comes to launching an MVP or having an impact on a metric, but these are something that we know people always ask for. Then we have the delights. These are minor but very attractive features such as a unique sticker or an emoji that can go on the app. These are delightful experiences but not necessarily hard requirements for an MVP. Then we have the metric movers. Depending on what metric we are focused on, it could be user engagement, it could be customer satisfaction. These are the feature that is actually going to move the needle for that specific metric, which means these features can also be part of the minimal viable product when we are launching it. Another method that I have used a lot in the past is the Moscow chart, which it has must have, should have, could have, will not have. This really helps us prioritize our features into non-negotiable product needs. When we know that there is a specific problem that we are trying to solve, we take a feature and we see that if we don't add that feature to our MVP, is it not going to solve the problem? Is it actually going to break the product that we are working on? If so, it needs to be part of the must have. Now, there could be other important metrics that are, that should be part of the product or the feature, but it necessarily does not break the functionality or usability of the product. Those features can go under should have. Then we have, could have, will not have. These are features that are not that important for the MVP and they can be nice to have for the users. So these are bells and whistles that we can add to our product, but not necessarily extremely important for the functionality of the product itself. Then we have the counter model analysis. Here we have threshold, performance, excitement. Now threshold, these are the features that's going to ensure the operability of your app or the product and are the most expected by users as well. Then we have performance. These features are mandatory, but will not substantially enhance the user experience. The third is excitement. Features that users do not expect, but into guarantee the excitement or generate excitement in a product. Now threshold is the most important features that needs to go into your MVP and it's going to really make sure that the, the MVP is functional. Lastly, we have the user story mapping. User story mapping is a lean method. We often practice it in agile teams where we use sticky notes and sketches to outline the interactions that the, that the team expects the users to go through to complete their specific goals. Now we can have very specific different problems that we are trying to solve. We can take all our features and see which feature is solving what problem. If a certain feature doesn't fall under the, the problem that we are targeting for MVP, it does not need to be part of the MVP. It's just another way for us to prioritize the feature that we want to work on. Finally, all these different methods are just to help us decide what features need to go into the first version of the product that we can release to our users and get feedback. Assuming we have done our feature privatization, we know the features we need to build, we build the feature, we have our MVP. Now it's time to launch. Now there are many ways we can go about launching a product. We can do a full-scale launch, which means we, we take the product and we make it available to everyone. We can also do a soft launch, which means we release it to a very targeted niche group of users to get their feedback and iterate over it before we make it available to everyone. If it's an existing product, we can start by doing an AP test where we have a control group and a treatment group to see how our feature or product is doing in the wild in the hands of the user. We can also do an internal launch where we make the feature available to our colleagues. In a lot of places, I believe it's called dog footing as well, where we can expect our colleagues or team members who fall under the persona to utilize the product and give us feedback. The overall goal is to present it in front of the users and collect feedback. Now one might think that this is it, we have launched, but the most crucial part of product development is creating a feedback loop. Now the feedback loop can be many things. We can do surveys, we can do user research, we can do usability testing. There are many ways of going about it, but creating the feedback loop and making sure that we talk to our customers, we understand how they're utilizing the product and find the problems that they're facing and iterate over it is going to be crucial for better product development. So then we can test, learn and iterate faster. When products are in the wild and users are using it in their natural habitat and process, it is the best time to get feedback and create the feedback loop. This is one of my favorite images that one of my design professor had showed us in a design thinking class. Building products is almost like playing broken telephone. Sometimes we understand our users, but we can misrepresent what they're asking for. So it's always crucial that we keep going back to them for feedback or we can actually end up building something that they did not ask for. And so creating the feedback loop and iterating and launching is crucial to building good products and I hope this guide helps you do that. As I mentioned, it's an extremely simplified process with seven steps on a straightforward path. But it is never as easy as we think and we should always expect something to go wrong. We have to go through a lot of hurdles, a lot of hoops that we might not expect and it can be a little bit more wavy, but honestly it's a lot more than that. There are many, many, many processes that I did not mention in that seven steps. It could be recruitment, it could be users not showing up to interviews, it could be going through a design review, it could be getting stakeholders alignment. There are many small bits and pieces that are missing from that seven step, but overall that's a very high level process that I have been following in my career and I hope that that seven step can fit into your product journey and would help you kind of have a sense of how to get from and just an idea to building something that we can actually put in front of users and see them utilizing it. If there are any two takeaways that I would love for everyone to get, the first is test early, fail fast, iterate and repeat. This is the Holy Grail of product development where we want to test with our users, we want to learn from them, we want to fail and we should never be scared of failing, but we always need to learn from our failure and iterate over it. The second would be involving users as early as possible. Our users, our sounding boards, they are the people who are going to use their products, so we cannot get better feedback from anybody other than the users who we are building for, so involve them as early as you can. Every step that we have discussed throughout this presentation, I have linked to articles that can really help you dive deeper into what each of those different processes mean, so I hope that's helpful and if there are any few books that I would recommend for PMs or even designers would be the following books. I have read all of them and they have been extremely helpful in my product management journey, product development journey. The one book that I thought really helped me with my process was Sprint. Again, it's also a guide which gives you different steps of how to go from an idea to actually building something that we can test with customers. I hope this presentation has been, this webinar has been useful for everyone. I would love to learn from you all, all the different processes that you're using. If there is something I have missed, please let me know. Please share it as a comment and I am looking forward to getting all your questions. Thank you so much.