The analysis behind small experiments in product discovery
Exploring the power of proof of concepts (PoC)
More often there will be experimentation, change and the need for flexibility. Frameworks like Dual Track Agile from Marty Cagan’s book “Inspired” influenced organizations to split their efforts into product discovery and delivery. The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software. One can also say that, in the Discovery track the goal is to “build the right solution”, to discover the product to build. Whereas in the Delivery track the goal is to “build the solution right”, to deliver that product to the market in the best way of working that team can.
The main shift on the premise of product delivery, compared to traditional requirements engineering, is that teams have to discover what the user’s problems are. They discover it based on a set of assumptions and validate if a delivered solution contributes to the desired outcome. For that, here are two groups of activities:
- Exploring the Problem Space to understand and define opportunities (problems, needs, desires):
- Performing customer interviews (e.g., weekly, as defined by Teresa Torres).
- Learning from usage analytics (collecting and analyzing data on how users interact with a product or service, e.g., Pendo.io).
- Learning from data analytics (analyzing large datasets to uncover trends, patterns, and relationships, e.g., Microsoft Power BI).
- Leveraging other tools: customer surveys, market trends, and benchmarking.
- Mapping opportunities (e.g., Opportunity Solution Tree, as defined by Teresa Torres).
- Exploring the Solution Space:
- Explore possible solutions to those problems (ideas).
- Formulate testable assumptions related to those ideas.
- Run experiments to prove or disprove those assumptions.
Initial vs. Continuous Product Discovery
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 prototypes, proof of concept (PoC) or MVP (Minimum Viable Product)
First, 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. In another article (available here) I explored these concepts. So, in this article, I describe them briefly. 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.
In summary, while MVP is related to the development and release of a product, 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 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.
A design sprint is a time-constrained (5-days), collaborative process used to tackle complex problems and develop innovative solutions. Throughout the workshops, you first define the idea, design and build it, and finally validate it closely with users.
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.
The “How Might We” technique involves rephrasing challenges or problem areas into open-ended questions that invite brainstorming and creativity. By using this technique, you encourage your team to think beyond constraints and generate a wide range of potential solutions. The challenge is about rephrasing ideas as an open-ended question that begins with “How might we…?” For example, “How might we create a more intuitive onboarding experience for new users?”
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. In the end, they gather the insights from the tests and assess the PoC.
