 Many of us in the software business are quite sure we know our target audience, their opinions and even how to cure them. I know what people need, you think. And some even believe that Steve Jobs didn't ask his customers what they wanted before planning a new product. Yeah, probably. You can make the right assumption about customers' wishlist, but none of us is Steve Jobs. Hi, folks! My name is Tatyana. I'm a Business Analysis Competency Lead at Altecsoft. And today we start our new series about product discovery and MVP development. In this series we'll try to understand how to approach product market fit as you build an MVP. We'll begin with product discovery and how the lean development approach helps with it. Then we'll discuss how to run customer research, how to prototype, prioritize features and eventually ship your MVP. Once it's ready, you can get feedback and validate your ideas. So in this first video we'll talk about lean development and how it helps with product discovery and MVP. Let's jump right in. Sometimes we should set aside our expertise or the desire to decide something for a customer. It's better to make assumptions based on the real market requests, pain points and bottlenecks. Keep in mind that, more often than not, customers can already satisfy their needs. So what we should look for is the existing inefficiencies in competitive products or solutions that don't exist yet. Only then can we make product hypothesis and suggest something new and valuable for the market. Eventually, we want to build the right product for the right people. And of course, we don't want to build something no one needs. So how do we make valid assumptions? Let me introduce you to the practice of product discovery. Product discovery is basically the set of activities we can perform to find our market fit and validate product ideas. What are those activities? Well, there are two main phases. First, we explore the market to define any problems and form our ideas. That's what's called exploration, when we do customer interviews, surveys, listen to social media, look through reviews of existing products and so on. They all provide insight that we use to make assumptions. With the existing problems in mind, the team comes up with ideas on how to solve them. These ideas become a blueprint for our product. Then comes validation. When we test these assumptions, again, the real world with only goal. Prove that customers really need the product and like it. And if we find out our assumptions are wrong and no one needs the product, let's also win. We should be extremely receptive to the feedback as it's better to fail early before we spend any money or effort. That's why we test ideas with prototypes. The process of finding product market fit revolves around constant communication with the audience and leaving our ego at home. Because we receive valuable insights only when we explore the market, evaluate ideas, then test and iterate them. Besides feedback, what we need to successfully discover the product is to focus on necessary things. The earlier we test and improve, the less chance a product backlog will be bloated with nice to have and yet not so important features. That's what the lean approach is about. It's always good to have ideas in excess, but they often interfere with the core value of the product. That's where the lean development approach comes in handy. For starters, lean is a philosophy of how you manage the project. It's about minimizing any unnecessary things that we call waste. In other words, we're trying to take away our extras and nice to have and focus on our main value. Lean development complements Agile as it suggests conceptual approach to fulfill business objectives. While Agile concerns technical aspects of how the development should go, according to Lean, there are seven key principles regarding how we organize our work. Eliminate waste or cut everything that doesn't bring evident value. Amplify learning, decide as late as possible to gather enough data and dissolve all the uncertainties, deliver as fast as possible, empower the team to communicate and decide together, build a quality approach, and optimize the whole process. So how does product discovery match these lean principles? First is market research. It's difficult to spot pain points as customers tend to suggest solutions instead of explaining their pains. But we need to start with the problem as lean is about learning from past experience instead of making assumptions for what customers want or think they want. Second is problem definition. Existing solutions carry habitual value for the customers. People are used to the tools they have. Everyone got used to the interface of Facebook and Instagram, but it doesn't mean there are no inconveniences in the way they work. So our task is to define what can be improved or which new solutions are required on the market. Third, we are moving to the idea and value proposition statement. After we understand the specifics of the customer's jobs to be done, we can transform these qualities into our product idea, a set of solutions for the given market. First is idea validation. Prior to this point, we were testing our assumptions that the problem exists or not. Now our task is to do the same for the ideas to solve these problems. As we want to approach all features that customers aren't going to use to solve a specific problem, these tests will include all the methods I mentioned, from customer interviews to clickable prototypes. After some trial and error, the team will come up with the minimum roster of things a good product should have, no more and no less. The fifth step is MVP delivery. Once we understand the core value we are bringing to the specific markets, we know everything we need to know to build an MVP. There are various methods to prioritize user stories for the MVP, including well-known, Moscow, Canada, and Rice. We'll touch on them in the future videos. Finally, we're gathering feedback. We need to tag the MVP on the market and listen carefully to what our customers say. If they don't accept and like the MVP, it only means it was based on their own market assumptions. And while it looks like we failed, actually, it's a positive outcome. Why? Because we're able to experience this failure before the real product is launched. Of course, MVP deserves more explanation, especially in terms of how it's connected with product discovery and lean approach. That's basically the purpose of this series. So now, let's discuss in a bit more detail what MVP is and its purpose. The concept of the MVP, while widely known, is often misunderstood. What we can do without Hollywood and just look at the essence of it. The initialisms stand for a minimum viable product and, as the name suggests, is a list amount of features required for the product to cover all the basic needs of the client. MVP can be sought after the demo version where customers have just enough functionality to use it, but it's primarily designed to check if you're solving a real, existing problem and if our solution is unique and sufficient. If we discover that our target audience doesn't experience such a problem, or existing products solve their jobs to be done better, we'll return to the first stages of product discovery and reiterate until we find realistic problems for which we'll provide valuable solutions. The sooner we get any feedback from the market, the better for everyone. Any product fails on the first interaction with the customer. No matter how much love and diligence we put into it, customers interact with the product in the other ways that we expect them to. So the first interaction shows all the short comments. And we pick and debase on our value proposition and neglect all the standard industry features that exist in every similar app. But we decide to neglect them for the sake of testing our specific solution and ship them later. On the other hand, MVP is not necessarily a whole product, but any feature we want to test against the real-world customers. Okay, let's recap. When you run product discovery and follow lean principles, you help your team build only what they should be building, rather than chasing cool features. And this is how lean complements agile. While the former emphasize working software, the lean approach is all about bringing value to the customer. If we put them together, we'll get a product that is released on time, works properly and meets the market request. Great, right? So in my next video, we'll discuss the product discovery process in detail. I'll run through its stages and activities to provide you with a concise look on the practice. Thank you for watching. Like the video and subscribe. See you next time.