 Hey everyone, and welcome to the session. Thank you for taking your time and listening to me discussing how to build an MVP, a minimum viable product. I'm your host for the session, Khalid al-Assami. I've worked in many big companies in the main region, Middle East and North Africa, and more recently within Amazon. In today's session, I'll focus more on my own experience in building MVPs, my own thought process, and the actual steps that I would take when considering building an MVP. So we will start discussing and answering the main question. What do we mean by an MVP? When to build it and how to build it? At the very end, I will be discussing more of the open questions that either it came to our mind or we always ask it when we were colleagues and friends and reading about MVPs. So let's get into it. What do we actually mean by MVP, a minimum viable product? As Eric defined it, the author of the new starter book is that it's that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. So we can translate from that is that the expected outcome of MVP is to confirm whether the product idea will target the right user, solve a user problem and generate revenue. The main takeaway here and the main focus for us is that an MVP it translate to collecting the maximum amount of validating learning. Why is that very important? Why do we need to validate the learning? Because it's also related to when do we need to build the MVP? As PMs, we're very familiar with the product lifecycle and here where it's come an MVP. Since we want to validate learning that's mean we want to enter a market. We have something that we really want to know is it working or not from the definition. We need to answer, is it the right users? Is it the right problem? Is it the right market? So building an MVP should always focus when we're trying to introduce a new concept in the market. At the end of the session we'll also tap and discuss is MVP good or okay to implement it as a concept in the later stages of the product lifecycle? And why do we really need to focus on the introduction stage because we need the product market fit? What do we mean by the product market fit? Is that as Mark defined it, the product market fit means finding a good market with a product capable of satisfying the market. So it's always about combining two main areas. As PMs, our main focus always is to find that product market fit, maintain it and grow from there. As Dan Olson in his book, the Lean Product Playbook mentioned it and explained it very well is that we have a product which is like a group of UX feature set and the main value proposition. On the other hand, we have the market itself, the underserved needs and the target customer. Our main focus is to combine that and how we will combine that is through market validation. That's why it's very important in the early stage of the product lifecycle and that's why it's very important to keep the maximum validated learning at mind and always iterate and always, always, always capture the lesson learned in order to achieve the market fit. So the main keywords that we have so far is that maximum learnings and product market fit and market validation. There's multiple ways of doing the market validation. So if you flip the coin, it will also translate to testing, experimentation. Hence, we have many concepts of market validation and testing with the very minimum of it is the proof of concept. It can be either one line of code, one component, the minimum way of doing it is just testing an idea very quickly through multiple ways that we will discuss very shortly. The next step of it is a prototype an actual product or a screen that you actually can feel and experience the steps within the idea itself. And MVP, which our main focus today, it's a group of screens and processes and concepts that translate the idea itself to the end user that we're trying to capture the underserved needs. Once we capture that, that's mean we have the product market fit which is the validation of the real value that we think that it's there in the market. Let's explain it more with example from the real world. So the first example is Dropbox. The way Dropbox created their own MVP is that they basically just created a video demonstrating how the idea will work and just posted the video. It's also called the fake door MVP which is like the goal of it is that you want to validate the idea without doing any implementation. The second MVP concept or sorry, implementation that we all familiar with is Airbnb. How Airbnb did it is by using the method concierge MVP. What do we mean exactly by that or what they did is that they created the website, then they put their own living room and the founder themselves replied manually. So the main idea of how creating this MVP is that you have a screen and all the backend or all the action behind the scenes are manually operated. Over, we're all familiar with over, we're all familiar with over, they use the concept of single feature MVP. The whole MVP at the early stage of over was all about one feature only and it was looking right. Groupon, basically what they did is that the piecemeal MVP focusing on third party tools, they did not reinvent the wheel, they just use multiple third party tools to act as the whole backend and then test the idea from there. So, so far we discussed the definition of an MVP that we need to really focus on the learning and gathering or capturing the maximum learning and lesson learned. And then from that, keeping that in mind, that's mean we need to go for the market fit and in order for us to have the market fit, we need to keep iterating and testing the ideas. And we saw that there's many examples of how we can do it. We do not need one of the wrong ideas available or when we discuss MVP is that that you need to develop many screens and many experiences and it's not the case as we saw. So, moving from what and when we will go to how build an MVP. So, what I always love to do when I manage products or lead products or even discuss what is the proper way of doing a product management. I always rely on the steps of the concept created by Martin Keegan in his book, Inspired. And I always use it as my initial homework, the actual thought process that I would need to take before proceeding in any action that I would need. So, start asking yourself exactly what is the problem that we are trying to solve which it translate to the value proposition? For whom do we solve that problem, the target market? And how big is this opportunity, the market size, how we will measure the success, the metrics and the revenue strategy, what alternatives are there? Your competitors, your competitive landscape. Why are we best suited to pursue this? What is the differentiator that we will really implement and we think that will flip the market? Why now? Is it really important now? Is it important in one year? Or it's too late for us to enter the market with the idea and the problem that we think that we want to solve? How we will get this product to market? How we will enter the market? Are we focusing on penetrating? Are we doing market effect, channel strategies and all of that? What factors are critical to success? What is exactly the feature set? What is the components of the product that we really need to develop? And if you have all this answer, then you will know it's go or no go. So, once you go and answer all of this, it's your pre-work before even discussing that you have an idea and a concept that you want to test. This should be your initial step that will answer what you do. Is it worth it to invest or not? Because as we defined it, MVP, it's all about testing. It's all about market validation. That means there's an effort. Even if you're just creating an MVP that is similar to Dropbox concept where they just created a video, it's still an investment, it's still work. So, if you did this initial homework, then you can start discussing MVP itself. You did it. You know that you want to build an MVP. Now, as Dan also in the Lean product playbook, discuss it. This is the hypothesis design test methodology. There's a hypothesis that you need to create, design and test and learn. So, let's discuss it one by one. So, you need to start determining your target customers, which you already did in your homework, identify the underserved customer needs, which will be translated to your value proposition. Now, you will dive even more, not just high level. You'll start creating your hypotheses. You have your problem and you think these problems, it's important to this target customers and you think you will solve it by these feature sets. So, I have hypothesis one and a sub hypothesis of it is A and B and C. I have hypothesis two and A and B and C and so on and so on and so on until you cover a 360-degree point of view of the actual problems and the target user and the market. Always keeping these three directions in front of your eyes. You developed your hypothesis. You now putting the kind of solution that will cover this, you will put your priority and then you start creating your MVP prototype. What do you mean here by prototype? It's not really need that you need to build, for example, as in the example, the open example, a one feature MVP. It can be a Dropbox prototype. Regardless of the type that you want to use, focus on how you will test your idea. There is no one right way of doing it. It's the best way and the most famous phrase for NPMs, it depends on the actual problem that you're trying to solve. And then once you developed your main hypothesis, the feature set that we think and the prototype, then you will start testing it with your customers and the main important point here is that iterate and pivot to improve the product market fit. You put your success measurement. You put your hypothesis and you put your solution and now you're testing. Do not be fooled that from the very first iteration that there's a good feedback that you have done it and you have that market fit. The whole discussion about market fit is so deep that it's parked for a later time but I really advise everyone to keep iterating even if you have good measurement, if even if you have good feedback, keep doing, keep doing and keep shifting all your hypotheses until you know that you captured the real honest feedback. So, so far what we discussed is that what do we really mean by an MVP? And it translated to the main focus of learning experience. It's all about experimentation. When is the best time to implement an MVP? When you have a new idea, when you want to launch something new in the market, when you don't have any clue or any answer of is it really going to be used by the market and the user which translate to the product market fit which is our main goal when we're trying to enter a new market. Do we really know the market? Do we really know that it's worth it? Once we have all of that, that's mean we have an idea of how we will proceed next. Then we discussed the main concepts and the main actual steps of doing it or how I do it and the way of it supported me and helped me across my experience. I always start by doing the actual homework and then once I do that, I know that it's worthy of the investment to move to the next step and then always focus on your hypothesis, listen to the market, keep iterating and updating your hypotheses. So let's have a different discussion now and think about different ways when we start doing the actual work. So the very first question, is MVP only for products or we can apply it on features? It's an interesting question and I had many discussions on this topic itself. There's two school of thought. This is how I see it. One school are mentioning or are saying is that it's in the name itself. Since we've talked about a product, that means it should only focus on products. MVP, a minimum value product, it's something that's required a lot of investment. It will require a lot of thought process. It should focus only on the really big ideas. On the other hand, we have the second group of PMs or you can call it as crew is that they are saying that at the end of the day, it's an idea. Regardless if it's a feature or a product or any kind of label that you will put, you're trying to test something. I'm with this second thought because as I mentioned at the beginning, at the end of the day, it's an idea. Flip the coin, it's a hypothesis. You really do not know if it will work or not. And my advice from my own experience, you're not the user. Even if you are the most experienced or the most senior person in your organization, you're not the user. Always test your idea with them. Let's mean build your hypotheses and go from there. Sometimes you have a product and now where it's come the discussion about the product lifecycle. You have a product already in the maturity stage or in the growth stage. So your product is up and running, but you want to improve from there. You want to advance. You want to beat your competitor or you want to spin off or whatever the kind of strategy that you want to do. That's when you always have new ideas. So should you not follow the best way of testing your hypotheses just because it's not a product? Sometimes you just need to create a new concept and new feature, a new component. And the same exact steps that we did, it can be still apply. This is the beauty of product management and the beauty of testing and experimentation. At the end of the day, you can sculpt it, mold it as the best way that you see fit. One of the main important question and we always struggle with as PMs is that, how to prioritize? We'll always get into the discussion, this important, no, that is important. None of this is important. We should focus on that. My advice here is that focus on the best prioritization model that fits the need at hand. Do not use one framework that you think that it will fit your whole experience, your whole development life cycle. Depending on the stage you're in, use the best framework that supports you on that. Once you have it, align with your stakeholders, make sure that they understand why you chose that specific prioritization model. Once you do that, then it's a matter of applying it to your hypotheses and to your features. When you do that, you'll start testing and keep iterating. It's like a closed loop. Once you have the feedback, you will know that you did not prioritize well or you'll focus on one area more than the other. Then it's a matter of just flipping and flipping until you reach the stage that your model is mature enough and discovering the need at hand. One of the most interesting discussions about MVP is that we often hear that there is also MMP and MLP, a minimum viable product, what we know, what all of us know it, minimal marketable product, minimum levelable product. It's also another deep topic that will be parked for later, but let me paint a picture for you with this example. Let's say that you defined all of what we discussed and now it's all about to what level of development that you will create for your product. I'm not even called at this stage an MVP or MLP. Let's say, for example, within your customer experience, they'll sign up emails. Your end user will sign up and they will receive emails. There's different ways of how to implement the email. It can start by just a simple text and HTML or a fancy way of doing it with videos and very advanced way of sending an email. You can develop it yourself. You can use a third party. You can automate the whole experience. These choices, it will fit in what area you defined your approach in the product development itself. So when we say minimum viable product, it's mean them very minimum least efforts. So if the email itself, the sign up email, it's not part of your hypothesis. It's just a matter of a part of the whole customer experience and it's not affecting the problem solving and the hypothesis and all of your metrics. For example, if it's not affecting the conversion, the whole hypothesis that you built, then you might just say at this stage, I'll just make this a plain text. It's not wrong because it's not the main focus what you're trying to test. You're trying to test your hypothesis. So whatever it's outside your hypothesis, it can be an MVP. There's no need to build something that fancy of it. If you find yourself saying, no, I needed to make it better because what I'm trying to build already available in the market and they do it in a certain way, they cannot be below them. Then it can be a marketable and minimal product. In other words, I don't need it to be a pure text email. It can be HTML. I can have my brand colors, the logo and everything. I even might even use a third party and invest more in an email list or whatever can fit the scenario that you have at hand. The lovable product is that, no, I'm having a video design. I'm having animation. I'm having something that emotionally will connect with the user that I'm trying to test with. So imagine this way, it's a spectrum. Anything that is not affecting the main hypothesis because without a doubt, it's you need to test it with the proper and most way. Anything around it, you can decide whether you want to focus as a very minimum way of doing it, just testing the viability of it. I wanted to be marketable, that I can go with confidence to anyone and say look to my product and across the whole CX, lovable where I will connect emotionally. Let's close the example with, I can simply say that high name, instead of saying hi and that's it or hi customer or dear customer. This can be within the MVP. If I want to make connection, and then I'll focus on those small details doing it. So as a takeaways, the MVP is really a powerful concept. And the beauty and the power of it is that you're validating the hypothesis in a more faster way. You have many questions at your hand, sorry, at your mind. Is it really worth it to build it in this way? Should we focus on this segment rather than that? Should we focus on this market rather than that? Should we use this technology rather than that technology? All these questions, you should always, always, always address it, not just by going directly, developing it, or not just by voting or prioritization. Always, always, always start with the hypothesis and then experiment your hypothesis. Experimentation is a very, very, very, very important topic and for us as PMs to have it in our toolbox. So an MVP is one way of validating this hypothesis. Don't be overprotective of your MVP process. Be flexible, adapt, and optimize where needed. Sometimes as PMs, we will fall in this mistakes on overprotective or over ownership of saying that, no, it's a process. This is how I want to do it. This is how I do it for many reasons and many issues that we might encounter while we develop, whether it's going that politics, whether it's going to be issues with the development, marketing, business, et cetera, et cetera, et cetera. Be humble, listen for others, from others, listen from your customers, listen for the feedback and optimize where needed. Maybe you will find yourself building an MVP where you should focus on building an MLP. Maybe you will find yourself so focused on one area of your hypothesis that you need just to flip it and focus on the area. Be open for criticism, be open for discussions, be open for optimizing where it's needed. As we mentioned, there is so many way on testing a hypothesis. What I've shared today is that the concepts and the best way that I saw of it for my experience and where I was leading and the challenges and I faced it, but at the same time, I was very flexible of adapting and I think sometimes I'll just focus more on discovery because it's a pure new idea. Sometimes I just focus on delivery because it's challenging how we should make it from a technical perspective, really mature. Maybe the whole idea and the whole value proposition of my product, of my hypothesis is that performance, it's a key. We can offer the same as our competitors, but our key differentiator is that our CX is seamless and our value, it's all about the responsive of the app of the RD itself. Selecting the most suitable MVP, we tapped on it a little bit. I'll close this thought by saying that there's so many ways of doing it. We saw how open Airbnb Dropbox did it. Try the best to fit your challenge, your problem, sometimes the budget that you have at hand and the team and the skills that you have at hand. Sometimes you would need to work with your team rather than forcing them to use a specific technology. Remember, at the end of the day, you're testing a hypothesis. You're not trying to prove the power of your team or your company. If you can do both, then it's a really great achievement. Building an MVP, it's a continuous process. Keep improving until you reach the product market fit. Again, it's about validating the market. It's all about testing your hypothesis. Keep listening, keep iterating until you find it. From a practical experience, it's really important to keep communication or communicating with your own stakeholders. So build fixed checkpoints across your main stakeholders for review and feedback, where you will discuss the performance of your MVP, the success metrics that you selected personally and with your stakeholders and sharing the feedback that you received from your end customers and the internal feedback. It's really important. Choosing the checkpoints, it can be quarterly, monthly, weekly. Again, it depends on the product situation that you have at hand. Don't worry if your MVP fails because this is what we need to do. This is what we aim to get, not failing exactly, but the feedback that will improve and allow us to iterate our product and what we are trying to achieve. Always, always, always be open to pivot. Always be open to kill your idea and switch because again, at the end of the day, what we are aiming is that listening from our end users or target customers. I'll close with this. There's really great books to read and articles. I really advise everyone to read the Lean Product Playbook. I tapped on it today in this talk in various ways. Also, validating product ideas. This is a really great book where it will show you the actual steps of how you should reach your audience and depending on the stage where you are at. Whether you're trying to create a focus group or whether you're trying to validate the market, whether you're trying to validate the hypothesis itself. It's a really interesting book and definitely inspired by Marty Kagan. I use it as my initial thoughts of how to build products. The Lean Startup will show a different way from Dan Olson of creating an MVP. As I mentioned, there's so many concepts, there's so many ways, there's so many steps. It's all about using the right one for your product and your idea. Some really interesting articles. I discussed a few of the MVP types. I encourage everyone to go and read type of products and type of product MVPs to know about. One interesting article that will really let you go to the stage of deep thinking of, do you really think the right way of your problem? Is that stop asking what problems are we trying to solve? Lastly, MLP versus MVP versus MMP. I really encourage everyone to go and read it. I discussed a little bit of it today, but it's a very deep and long discussion. Always remember, the value is in what gets used, not in what gets built. Keep it always in your mind. MVP at the end of the day, it's a concept that you can implement, but it's not the only thing that you should do. It's not the only thing that you should focus on and it's not the only way of testing or creating products because more recently, we're starting to see it as a trend, as a must. Our part is to educate the stakeholders that we work with. Our part is to take the right decision and choose the right way of testing your hypothesis. Thank you for everyone. Thank you for listening. Would really love to discuss more with you. Please feel free to reach out through LinkedIn. If you have any feedback, discussions or questions, that you would love me to answer. Thank you, everyone.