MVP - An ounce of action
2021 10 minutes read
Context Setting:
By the time we started with the product idea, we gathered some information about the challenges of potential users. But we did not have enough data to convince the sponsors for a budget. We barely managed with a tight budget to build the MVP. We had to be innovative and quick to produce proof of value.
| Defining WHY - the Vision
| Learning WHO - the impacted Users
| The RIGHT PEOPLE in the team
| Exploring HOW - to develop, validate and pivot faster
| Discovering WHAT - feasibility, functionality and usability
The "WHY" statement:
We were pressed with two challenges here — first to solve the user problems and second to demonstrate the potential value of the product. We decided to build our purpose around these two specific goals.
Furthermore, we wanted to be very objective for the MVP. So we started only with the objective, which we later extrapolated to define the overall product vision. We refined the product vision as we discovered more facts and possibilities on our journey.
Framing the MVP Objective:
Start with a specific user group — In our case we had local, regional and global users, and we saw that regional users had been vocal about the challenges. The regional users were most influential, and we had the opportunity to work closely with them.
Define User Persona — We started by creating user persona for the regional users only for the MVP. Later we did the same exercise for the other users which helped us to determine the similarities and differences between them. That helped us to extrapolate the product value in the presentation to the sponsors.
Model current behavior — We felt the need to model the current behavior of the users. This helped us to determine the behavior changes a user needs to do to use the product. This also helped us ideate the features.
Focus on specific user challenge — For MVP, we focused on usability aspect with features which would required minimal behavior changes. We also considered developing features that were feasible and had maximum business impacts.
Use 'unit equation' as a measure — We had to be careful when measuring the product success. We had two options — [1] capture value per user or [2] capture value per run. [A 'run' refers to a 'case/work/item' with a defined start and end states. ]. The selection of right unit matrix helped us to extrapolate to build the case for the larger product.
Scoping & Setting the Priorities Right:
We improvised on a 2 x 2 matrix to do our prioritization. This 2 x 2 matrix was inspired by Peter Thiel and we improvised on it and it worked out well for us. [X -axis] Determinant: The features of a value can be scoped based on parameters of which maximizes business value/impact. [Y -axis] Optimistic: The features which are technically feasible within the time frame.
With every iteration and user interaction we had more insights and revisited the "Prioritization" matrix.
Selection of Parameters: Getting the "economic denominator" right
We carefully selected our parameters to classify the features. Choosing the “right economic” denominator gave the maximum insights. In this case we chose —
Optimistic: - feature that can be built within 1-2 days [Rational: to produce something useful within budget and time]
Determinant: - No. of hours saved / run [Rational: The rational was to simplify the unit metric and choose the right denominator to justify the value. If we chose the metric as No. Of hours saved / user, we would have been reliant on the user behavior, skills and user efficiency. The denominator “run” gave us the fundamental insights on the process inefficiencies and was valid for all user types we had.]
Sense of Urgency:
We gathered a small team of good engineers and a designer. As we were discovering features, we started to problem solve and develop them in parallel.
Validate hypothesis - We presented our hypothesis on the feature ideas to our customers for early validation. These were mainly mock ups and designs which we referred to as the 'Paper Product'.
Develop to show and tell - Once we had a valid hypothesis in the backlog, we built it and presented our case to the regional users. There were no formal sprint cycles and ceremonies as we did not require them. All our features passed the feasibility/optimistic test of prioritization. The product iteration was fast and we delivered a product increment every day.
Transparency - We were transparent to our users and sponsors. Our demo failed multiple times, but our efforts were visible. The sponsors and users believed and trusted us.
The regional users saw value in the MVP. The economic value of the product was convincing to the sponsors. We got approval for a larger budget. The biggest learning were from the tweaks and deviations we did from the usual approach. Experiments can teach a lot.