The analysis to do in product discovery of MVPs
(and also what’s not MVPs)
To do a proper product discovery is finding the most valuable way a product can provide. Business analysis is powerful for discovering what an organization values most. There are different approaches that you can use in Discovery, depending on what you want to experiment. I already explored the power of proof of concepts (PoC) in another article. Now, I dive into another powerful (and commonly known) approach for Discovery: Minimum Viable Product (MVP) — but also what’s not MVPs.
What is product discovery and how it works
With the emergence of agile development methods, there was a shift from project thinking to the product mindset. Additionally frameworks like Dual Track Agile from Marty Cagan’s book “Inspired” influenced organizations to split their efforts into product discovery and delivery.
There are two distinct ways of doing product discovery: a first-time (i.e., initial) discovery and a continuous one.
The Initial Product Discovery runs without Product Delivery. Its goal is to discover the product that has a chance of achieving Product-Market Fit.
The Initial Product Discovery may result in a Product Vision, Product Strategy, and initially validated Business Model that can serve as a base for investment decisions.
A continuous product discovery runs intertwined with Product Delivery, as assumptions from discovery are assessed through the delivery.
Using concepts as MVP (Minimum Viable Product), MMF (Minimum Marketable Feature), or MLP (Minimum Lovable Product)
In a previous article, I have summarized the difference between these concepts that are often misunderstood.
But let’s review the essentials again. Terms like MVP (Minimum Viable Product), prototype, and proof of concept are all concepts used in product development. There are also other terms used, such as MMF (Minimum Marketable Feature), Minimal Marketable Release (MMR) and Minimal Marketable Product (MMP) or MLP (Minimum Lovable Product). They serve different purposes and have distinct characteristics. In another article (available here) I explored these concepts. Here is a short summary of the differences between prototype, PoC and MVP:
- Prototype: A prototype is a preliminary version of a product used for design, testing, and demonstration purposes.
- Proof of Concept (PoC): A proof of concept is a small-scale project or experiment designed to verify the feasibility of a particular technology, concept, or approach.
- Minimum Viable Product (MVP): An MVP is the most basic version of a product that contains just enough delivery work to satisfy early customers and gather feedback for further development.
In this article, we introduce as well:
- Minimum Marketable Feature (MMF):
- Purpose: MMF is a subset of features within a product that is sufficient to make it marketable to a specific target audience.
- Focus: It concentrates on delivering features that are essential to meet the needs of early adopters and generate sales or user adoption.
- Development Stage: MMF typically follows the MVP phase, where you refine the product based on initial feedback and prioritize features for marketability.
2. Minimum Lovable Product (MLP):
- Purpose: MLP aims to create a version of the product that not only satisfies basic needs but also elicits an emotional response from users.
- Focus: It goes beyond functionality to provide a delightful user experience and build strong user loyalty.
- Development Stage: MLP often follows the MVP and MMF stages and is focused on making the product more appealing and engaging.
In summary, while MVP, MMF, and MLP are related to the development and release of a product, each serves a different purpose in terms of features, user experience, and market readiness. Prototypes and proof of concepts, on the other hand, are more focused on testing and validating ideas and technologies before committing to full development.
Business analysis behind MVP
When planning to build an MVP, don’t forget you’re targeting to validate if a business idea, through a product, has value for customers that you believe it has. However, before investing in a solid product, the mindset is that you’re making the least effort possible to have something that technically works.
This means that the workaround framing a problem and further elicitation, analysis, modeling, refinements, etc., relies on hypotheses to be validated, rather than fixed requirements, allowing for greater flexibility and adaptation to changing customer needs.
For framing the problem, a technique that has gained traction is “Jobs-To-Be-Done” (JTBD). JTBD technique was developed based on jobs theory and outcome-driven innovation processes. By observing users’ behaviors, it encourages us to appreciate why a product or service was “hired” (a JTBD metaphor). The book “Jobs to be Done — Theory to Practice” by Anthony Ulwick describes a framework that you can use to define your jobs, from setting your different customers, to the different kinds of jobs (core, related, emotional, consumption chain, and purchase decision jobs), and setting the desired outcomes.
Interviews are a crucial part of the elicitation of the product’s requirements. A business analysis professional may register all the stakeholders dictated “wishlist”. Or it can engage with the stakeholder and elicit what is their actual needs.
Techniques like “continuous discovery habits” and “The Mom Test” advocate stakeholder interviews but with a different structure. The main shift in doing interviews is that questions don’t focus on what customers want. Rather, questions should focus on their past experiences to discover an opportunity (or opportunities). Below it’s a template for the interview notes from Pawel Huryn, based on the suggestions of the intended outputs of these interviews by Teresa Torres.
The insights from conducting the Continuous Interviews should allow us to identify opportunities for our product. Another one of the “continuous discovery habits” proposed by Teresa Torres is opportunity solution trees. Opportunity solution trees are a visualization of potential solutions to a customer problem. They involve breaking down the problem into smaller opportunities, generating multiple solutions for each opportunity, and then evaluating and selecting the most promising solution.
The model of the opportunity solution tree also addresses prioritization. Your top priorities concerning opportunities range from the left side to the right side. Thus, the opportunity(ies) to address within the MVP are placed on the left side.
The decision as to which opportunity to address first may combine opportunity solution trees with assumption mapping. Assumptions Mapping is a team exercise where desirability, viability, and feasibility hypotheses are made explicit and prioritized in terms of importance and evidence.
List all of your assumptions. we recommend that teams write these down as best they can using the “We believe that…” format (similar to the “How might we” from the Design Sprints). This format helps you shift mentally to the idea of testing. The idea that you might be wrong in your beliefs.
We use the labels of “have evidence” and “no evidence”. It’s not about who is the loudest or who gets paid the most. It’s about having observable evidence, qualitative or quantitative, to support your hypothesis. On the y-axis, we use the labels of “important” and “unimportant”. not everything is the most critical. By asking yourself “Which hypothesis, if proven wrong will cause our business idea to fail” you’ll be able to determine which are the most important.
Once you start refining the hypothesis, the technique of the Lean Canvas helps bring clarity to the assumptions, as well as the advantages and obstacles probably facing when building the MVP.
Then, the Lean Inception method — authored by Paulo Caroli, the book with the same name — refers to a 5-day workshop to discover how to compose a minimal viable product (MVP), by including concepts such as product vision, personas, customer journeys, and others.
Business analysis if you’re not targeting for an MVP
Sometimes when building an MVP is planned in a way that has a minimum set of features that can be delivered to customers. As already discussed, that’s not an MVP but an MMF instead, thus the mindset for building it focuses more on scope modeling to decide which are those features that have to be included.
Also, in case the mindset focuses more on delighting customers (sometimes even disregarding the business value delivered), that’s not an MVP but an MLP instead. The BA work focuses more on user research, interviews and partnering (if existing) with UX/UI professionals. Personas and empathy maps are commonly used techniques.
After, you may define your strategy to test your assumptions. There are different techniques that depend on the testing context. And such context has different approaches to use.
As a BA, we can support decision-making of the technique to choose. But also to help in setting up those tests.
