Conceptualizing the solution & defining MVP.pptx

Conceptualizing the solution & defining MVP

1. CONCEPTUALIZING THE SOLUTION & DEFINING MVP Olgica Strezoska

2. Product Development Phases DISCOVERY Find a problem to solve DEFINE Determine the MVP DESIGN Defining and designing IMPLEMENTATION Create product specifications Olgica Strezoska

3. Picking winning features When considering possible product features, you should analyze the feature from two angles: Customer value : How important is the need that this feature would address for the customer? Is it high value (addresses a critical need), or low value (nice-to-have)? Will the feature address a scalable critical need across most customers, or is it a niche feature that only appeals to a small handful of customers? Is it unique? : Do any of the direct or indirect competitors in the market already provide this feature? If you include the feature in your product, would it be unique? 3 Olgica Strezoska

4. If something is of high customer value, but not unique in the market (meaning that most competitors already offer it) These features are extremely important, and are the cost of doing business because customers value them and expect them. But they are not going to set you apart in any way As much as possible, you want to be in the upper right quadrant — high customer value and unique (meaning that most competitors don’t offer this today) Features you should consider building TABLE STAKES 4 DIFFERENTIATOR Olgica Strezoska

5. The lower right quadrant is something that is unique in the market (most competitors don’t offer it today), but it’s also low customer value T his is a trap that a PM (or a startup) can easily fall into — chasing products and features that are “differentiated” and unique in the market, but are not valued by customers The lower left quadrant is to be avoided as much as possible — low customer value and not scarce If you over-rely on sales or even customer input (without understanding the “why?” — is this feature really valuable to the customer?), then you’re likely to include at least some “Waste of Time” features Features you can survive without WHO CARES? 5 WASTE OF TIME Olgica Strezoska

6. 6 What’s the best solution? You should always want a mix of Table Stakes and Differentiators If you’re only building Table Stakes features, everything you’ve built is also available with competitors (not unique), and there’s no compelling reason to buy your product — other than maybe price. You will never be able to command a premium price, you will always be subject to intense competition. Not a winning strategy in the long-term. Turn Table Stakes feature into a Differentiator It’s ideal if you can pivot features that are considered Table Stakes into being somewhat of a Differentiator. It’s important to ask yourself every time you’re considering a Table Stakes feature: is there anything we can do to put our own twist on this to make it unique and valuable? Olgica Strezoska

7. Product Roadmaps 7 Olgica Strezoska

8. What is a product roadmap? A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. A roadmap is a guiding strategic document as well as a plan for executing the product strategy. 8 The product roadmap has several ultimate goals: Describe the vision and strategy Provide a guiding document for executing the strategy Get internal stakeholders in alignment Facilitate discussion of options and scenario planning Help communicate with external stakeholders, including customers Olgica Strezoska

9. Top-down product planning approach 9 Olgica Strezoska

10. 10 How your roadmap will evolve as your product matures Product roadmaps also go through an evolution of their own. A roadmap for a freshly-minted MVP differs significantly for a mature product on many fronts: Horizon: Startups have a much harder time predicting future requirements and opportunities for the products. Therefore their roadmaps probably won’t go too far in the future (or if they do it’s with some very large asterisks). Established products can make firmer longer-term plans. They have a better understanding of their customers and the market. Frequency: When you’re young and scrappy, you need to “always be shipping.” More mature products can space out their releases with less urgency. Dependencies: Startups can move quickly and break stuff. Mature products have a legacy to worry about, third-party integrations to maintain, and regression issues to contend with. Goals: A startup’s goals are very different from an enterprise product. The first is just trying to prove its viability, gain some traction, and grow. The latter will have more nuanced strategic objectives and more diverse targets. Olgica Strezoska

11. How can you prioritize your roadmap? Roadmaps are the result of lengthy analysis, consideration, and deliberations. Once you set strategies and goals, it comes down to prioritizing features and enhancements based on a variety of criteria MoSCoW prioritization, also known as the MoSCoW method or MoSCoW analysis, is a popular  prioritization technique for managing requirements. The method is commonly used to help key stakeholders understand the significance of initiatives in a specific release . 11 Olgica Strezoska

12. MoSCoW prioritization categories 12 This category consists of initiatives that are “musts” for your team. They represent non-negotiable needs for the project, product, or release in question. For example, if you’re releasing a healthcare application, a must-have initiative may be security functionalities that help maintain compliance. Should-have initiatives are just a step below must-haves. They are important to the product, project, or release, but they are not vital. If left out, the product or project still functions. However, if they are included, they add significant value. MUST - HAVE SHOULD - HAVE Another way of describing “could-have” initiatives is nice-to-haves. “Could-have” initiatives are not necessary to the core function of the product. Compared with “should-have” initiatives, they have much smaller impact on the outcome if they are left out. Placing initiatives in the “will-not-have” category is one way to help prevent scope creep If initiatives are in this category, the team knows they are not to be a priority for this specific time frame. Some initiatives in the “will-not-have” group will get prioritized in the future, while others are not likely to happen at all WILL NOT HAVE COULD HAVE Olgica Strezoska

13. ProductPlan Aha! Time.Graphics Smartsheet 13 Roadmapping tools Olgica Strezoska

14. 14 MVP An MVP, or Minimum Viable Product, is a “tool” that helps you validate your idea before you allocate all your resources to it

15. Minimum Viable Product 15 MINIMUM VIABLE PRODUCT There should be just the key features that solve a specific problem. No additional, cool stuff that can be added later it should deliver enough value for your users to download it, input their personal data or pay for using it it should be an actual, working product Olgica Strezoska

16. What is a Minimum Viable Product? 16 The reported goal of the MVP is to accelerate learning in the early stages of product development with minimal investment of money and resources The concept of an MVP can also be applied to existing products as a way to understand if a new feature set is valuable to customers Olgica Strezoska

17. How do you start building an MVP? There are typically a few steps to the process of building it out: Identify and evaluate the problem Analyze the competition Define the user flow Prioritize the minimum set of features Build, test, and learn 17 “What is the cheapest and fastest way we can start learning?” Olgica Strezoska

18. What can happen with your MVP? Your Minimum Viable Product will be a success Your Minimum Viable Product will get lots of feedback on what can be improved Your Minimum Viable Product will be a total f ailure 18 Olgica Strezoska

19. MVP Advantages & Disadvantages Olgica Strezoska

20. 20 What is a Minimum Lovable Product? A Minimum Lovable Product (MLP) is an initial offering that users love from the start. It represents the minimum that is required for customers to adore a product, rather than merely tolerating it. If a customer's experience with your product leaves them feeling unsatisfied,  unheard or unappreciated, they will quickly move on to find something better. To build an MLP, you must deeply consider what customers care about, the problems they have, and how to make their lives better. Consider the customer experience as a whole and strive for love at every stage. As a result, customers will not only purchase your product or service — but they will also want to see your company thrive. Olgica Strezoska

21. Airbnb: From 3 guests to 400 million 21 The Airbnb we know and love today, started out as AirBed&Breakfast , a very basic website which provided accommodation to people who came to San Francisco for a design conference. The problem that founders Brian Chesky and Joe Gebbia were trying to solve was that they couldn’t afford the rent on their loft apartment. Short-term rentals were arduous and often involved big bills to middlemen. After testing their idea on 3 paying guests during the conference, Airbnb grew organically to the powerhouse we know today Had they not tested, they could have build an extravagant system, with all the cool features Airbnb has in 2020, only to find that people didn’t want to stay in other people’s homes. Olgica Strezoska

22. MVP vs MLP 22 MLP principles MVP principles Goal is to disrupt Goal is to increment Problem can be understood Problem cannot be understood Market can be analyzed Market cannot be analyzed Customers know what they want Customers do not know what they want Many product alternatives exist Few product alternatives exist Make architecture decisions because technology is sufficiently stable Avoid architecture decisions because technology is unpredictable Dedicated effort to the opportunity Lean effort because success is unlikely Focus Pivot Customers love your product Customers tolerate your product Olgica Strezoska

23. 23 WIREFRAMES, MOCKUPS & PROTOTYPES Visualizing your solution

24. Visualization of the solution 24 Olgica Strezoska

25. 25 What is a wireframe? A wireframe is a skeletal blueprint or framework that outlines the basic design and functions of a user interface (such as a website or application). The goal of a wireframe is to quickly and easily communicate: The contents of the page The page structure and layout The app’s functions Olgica Strezoska

26. 26 What is a mockup? A mockup is the next, more in-depth iteration of the wireframe outline. A mockup is a static wireframe that includes more stylistic and visual UI details to present a realistic model of what the final page or application will look like. A mockup typically includes additional visual details such as: Colors, styles, graphics, and typography Styled buttons and text Navigation graphics Component spacing Olgica Strezoska

27. 27 What is a prototype? A prototype is an early model of a product or design built to test the concept.  A prototype is typically a functional and interactive simulation that includes all the stylistic details intended for the final deliverable. This model allows developers to see how their product works in a real environment and test the usability of their designs. The main purpose is to test the design before investing time and money to develop the full product. A prototype can help developers work out any bugs or design flaws, see the user flow and interactions in practice, and build support and engagement from stakeholders.  Olgica Strezoska

28. Recommended tool for wireframes / mockups 28 Adobe XD Brief tutorial Olgica Strezoska

29. Thank You Any questions?