Author: Nuno Santos

Demystifying MVPs, Prototypes and Others in the BA Landscape

Written by Nuno Santos on March 7, 2024. Posted in Articles.

Let’s get some confusion out of the way. There are many different concepts and related acronyms that aren’t always used in the best way. Let’s try to clarify them.

Terms like MVP (Minimum Viable Product), MMF (Minimum Marketable Feature), MLP (Minimum Lovable Product), prototype, and proof of concept are all concepts used in product development, but they serve different purposes and have distinct characteristics. Here’s a breakdown of the differences between them:

Prototype:

Purpose: A prototype is a preliminary version of a product used for design, testing, and demonstration purposes.
Focus: It primarily focuses on illustrating the product’s design, user interface, and user interactions.
Development Stage: Prototypes are created early in the product development process to visualize ideas and concepts before full-scale development begins.

2. Proof of Concept (PoC):

Purpose: A proof of concept is a small-scale project or experiment designed to verify the feasibility of a particular technology, concept, or approach.
Focus: It concentrates on demonstrating that a specific idea or technology can work in a real-world scenario.
Development Stage: PoCs are often done at the very beginning of a project to assess technical feasibility.

3. Minimum Viable Product (MVP):

Purpose: 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.
Focus: It focuses on delivering core functionality to test the product’s intended value to the customers.
Development Stage: MVP comes after the idea and concept but before extensive development.
Goal: The primary goal is to validate assumptions and learn from user feedback with minimal development effort.

4. 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.

5. 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. In IIBA’s Guide to Product Ownership Analysis (POA®), the concepts of MVP, MMF, and Minimal Marketable Release (MMR) and Minimal Marketable Product (MMP) are introduced in terms of decision-making on what to build. The figure below is from the POA Guide and orders these four concepts. To know more about MVP with PoC and prototyping, check out a great article (with a video interview) with Fabricio Laguna (“The Brazilian BA”) and Ryland Leyton here.

Fig. 2: MVP, MMF, MMP, and MMR in the POA Guide

Business analysis Behind Proof of Concept (PoC)

We may use a PoC when the goal is to make a very small experiment around a business idea, from which we need to assess its feasibility.

A well-known way to explore ideas in an early phase of design is by conducting Design Sprints.

Business analysis work within this process is of extreme importance. First of all, a BA professional may use their facilitation skills to facilitate the entire workshop. When framing the BA scope to the ideation process, their work starts when applying the “How Might We” technique. If you want to know more about the “How Might We” technique, you can check it out here.

After ideating a range of “How Might We?”’s, the BA work includes facilitating the following workshops, from which the ideas are refined until a (possibly very bad) prototype is built and tested with users. BAs are usually comfortable with conducting the tests. At the end, they gather the insights from the tests and assess the PoC.

Business Analysis Behind MVP

When planning to build an MVP, don’t forget you’re targeting and validating 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 work around framing a problem and further elicitation, analysis, modelling, refinements, etc. relies on hypotheses to be validated rather than fixed requirements, allowing for greater flexibility and adaptation to changing customer needs.

Business Analysis If You’re Not Targeting an MVP

Sometimes, when building an MVP, it 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, so the mindset for building it focuses more on scope modelling to decide which features have to be included.

Also, if the mindset focuses more on delighting customers (sometimes 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 that, you may define your strategy to test your assumptions. There are different techniques, which depend on the testing context. And such contexts have different approaches to use.

As a BA, we can support decision-making about the technique to choose. But also to help in setting up those tests.

How Product Discovery Deals with Requirements

Written by Nuno Santos on October 4, 2023. Posted in Articles.

If you are working in products, you certainly have realized product management handle requirements differently. There is a shift from eliciting stakeholders’ wishes to discovering better and faster ways to solve stakeholders’ problems. This article presents how discovery techniques popular within product management fit in the three types of requirements: business, stakeholder and solution. Understanding where the techniques fit in this spectrum will allow a better understanding of how and when to use them.

Keywords: Requirements; Elicitation; Product discovery

What is Product Discovery and this “Modern” Elicitation

There may have been times in the past where business analysis was (incorrectly) seen as a passive discipline. Some might have viewed that a business analyst’s job when “gathering” requirements, most of the time, was attending meetings where they interviewed a group of people. Typically, these people had significant roles in the product (although most of the time they wouldn’t be the future users of the solution) and the business analyst would simply be a clerk and register all their dictated “wish list” items.

This approach is based on the premise that your sources know what they need and dictate the solution, yet how often is this actually realistic? More often there will be experimentation, change and the need for flexibility. The emergence of agile development methods and frameworks like Dual Track Agile, influenced organisations to split their efforts into product discovery and delivery.

The main shift on the premise of product delivery, compared to bespoke or market-driven requirements engineering, is that teams have to discover what the user’s problems are based on a set of assumptions and validate if a delivered solution contributes to the desired outcome. For business analysts, this means being involved in both the discovery and delivery processes, and it requires a shift in how requirements are elicited and managed. BAs need to challenge stakeholders’ perceptions on any assumed solutions and get to the underlying need using modern requirements techniques. They have to discover the requirements rather than gather them.

The Requirements Engineering Cycle

The cycle that typically involves elicitation, documentation, validation, and management of requirements is often associated with the broader field of Requirements Engineering or Requirements Management within the context of software development or project management. This cycle is iterative and continuous throughout the project lifecycle. Here’s how it works:

Elicitation: Requirements are gathered from stakeholders, users, and other relevant sources. This step involves understanding their needs and expectations for the software or project.
Documentation: The collected requirements are documented in a clear and comprehensive manner. This documentation can take various forms, such as a Software Requirements Specification (SRS), user stories, use cases, or other requirement documents.
Validation: The documented requirements are then validated to ensure that they accurately represent the stakeholders’ needs and are feasible to implement. This involves checking for consistency, completeness, and correctness of the requirements.
Management: Throughout the project, requirements are actively managed. This includes change management to handle updates or modifications to requirements, traceability to link requirements to design and testing, and prioritization to determine which requirements are most important.

The requirements process doesn’t end after the initial elicitation, documentation, and validation. It’s a continuous and iterative cycle because requirements may change over time due to evolving project goals, stakeholder feedback, or other factors. Therefore, effective management of requirements is essential to ensure that the project remains aligned with its objectives and stakeholder expectations. It often involves feedback loops, revisions, and ongoing communication with stakeholders to refine and adjust requirements as needed throughout the project’s lifecycle.

1. Discovery Techniques for Elicitation

“How might We…” Technique

The “How Might We” technique is a crucial aspect of the design thinking process and is often used in design sprints to frame problem statements and generate creative solutions. The “How Might We” technique involves rephrasing challenges or problem areas into open-ended questions that invite elicitation through brainstorming and creativity. The challenge is to rephrase it as an open-ended question that begins with “How might we…?” The “How Might We” statements invites participants to generate creative ideas without feeling restricted by existing limitations. It shifts the focus from problems to possibilities, and it helps teams explore solutions from different angles, often leading to innovative and unexpected outcomes.

Jobs-To-Be-Done

“Jobs-To-Be-Done” (JTBD) encourages us to appreciate why a product or service was “hired”, not only in a functional dimension, but also in circumstances and emotional dimensions. 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, the different kinds of jobs (core, related, emotional, consumption chain and purchase decision jobs), and setting the desired outcomes.

The behaviours of the customers that afterwards lead to definition of the “hired” job are identified by observation. Observation is a common elicitation technique. In this case, rather than observing (or shadowing) in order to replicate a given process, an observation within JTBD aims to relate a behaviour to customer’s outcomes.

Continuous Interviews

Teresa Torres described a set of “continuous discovery habits” to engage customers in a continuous cadence. 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.

As the name states, it uses interviews techniques. Once more, a very popular way to perform elicitation. As mentioned, the main shift is that questions that are asked focus on their past experiences to discover an opportunity.

The Mom Test

the Mom Test is another interesting approach for conducting stakeholder interviews. It has similarities with “Continuous Discovery Habits”, as the questions should focus on their past experiences to discover an opportunity. The premise of the Mom test is: your mom will always like your idea, but doing the right questions can make her tell what you really need to hear. Elicitation by performing these kinds of interviews allows us to depict the problem in question, rather than waiting for the interviewees to tell us the solution they want.

2. Discovery Techniques for Analysis

Value Proposition Canvas

The Value Proposition Canvas is a strategic tool used in business and product development to understand and communicate how a product or service creates value for customers. It’s typically used in conjunction with the Business Model Canvas to create a holistic view of a business. The canvas helps businesses design their offerings by gaining a deep understanding of customer needs and how their products or services fulfil those needs.

It demonstrates a clear understanding of customer pains, gains, and jobs to be done, and introduces alignment of the pain relievers, gain creators, and product(s) benefits.

User Journeys

User journeys, also known as customer journeys or user experience (UX) journeys, are a product discovery technique that originated from the field of User Experience Design (UXD) and User-Centered Design (UCD). User journeys provide a visual representation of the user’s interactions and experiences while using a product or service. They aim to capture the user’s perspective, emotions, actions, and touchpoints across different stages of their interaction with the product.

Opportunity Solution Trees

Opportunity s olution t rees are a visualisation 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.

It is our analysis work in getting insights from conducting the Continuous Interviews, allowing us to identify opportunities for our product.

3. Discovery Techniques for Documentation

Epic Alignment

“Epic alignment” is from Nils Janse’s book with the same name, proposes a single source of truth about the requirements, in form of a “lightweight” documentation that is based around epics. The structure that is proposed for this documentation includes information that is incrementally added to what we know about a given epic throughout the product development stages (namely, Ideation, Discovery, Prioritization, Refinement, Development and Testing). The structure of these documents allow to follow the information about an epic, which user stories are included, and the details that are needed for their implementation.

4. Discovery Techniques for Validation

User story mapping

The last technique I want to discuss in the article is u ser story mapping. This is a technique where team members collaboratively discover how a set of user stories solve a customer problem. The method consists of sequencing the user’s activities, and allows further elicitation to take place so that detailed stories and tasks can be captured. This in turn ensures that the solution will support the user’s activities that were presented.

Classifying this technique in a single stage can be tricky. I rather believe it encompasses elicitation, analysis and validation of requirements.

It’s a technique where team members collaboratively discover how a set of user stories solve a customer problem. End users may be involved in the collaborative process as well, most probably giving inputs in the user journey and the sequence of activities – which makes it an elicitation technique. Sequencing activities may be an output of previously performed elicitation, resulting from analysis of that information. Lastly, acceptance criteria may be included in the details of the story mapping, which forces the team to start stepping up into the requirements validation. In the case of users not have been part of collaborative process, the model may be used to validate together with users that the user journey is indeed correct.