Lean Discovery Practices help us validate our MVP to ensure we are building the right thing.
Eric Ries, author of Lean Startup, reminds us that
“The big question of our time is not can it be built, but should it be built?”
Eric Ries
To know that, we have to go through quick build, measure, and learn cycles and with each cycle we have to decide on whether to persist or pivot based on new learnings. We have to accept the fact that our so called requirements are really hypothesis that are only proven true when we get real data that validates that what we build is actually usable and valuable.
We have a target solution in mind, and through successive iterative deployments we validate our assumptions. We get there by applying some qualitative analysis (before deployment), as well as quantitate analysis (after deployment) and with each step we decide to pivot or persist until we reach our desired solution which will likely end up different from the original target solution we had in mind. Through validated learning, we are able to build a more valuable product.
The solutions we are building need not only be viable from a business perspective and feasible from a technical perspective. The solutions also need to be usable from a customer perspective. To do that, we need to understand what end users need and use data to drive decisions. The solutions need to address the whole user experience while making it simple and intuitive to use.
To do that we apply Lean Discovery practices rooted in Lean UX to help us quickly take a concept, validate it internally, prototype it, test it externally and learn from user behavior.
Techniques such as a Value Proposition Canvas make it explicit how we are creating value for our customers by mapping customer gainers and pain points to product features that relieve these pain points and increase their product engagement.
Test cards help us setup the concepts or hypothesis along with the tests, metric and success criteria to validate. It follows the format of:
Hypothesis: We believe that …,
Test: To verify that, we will …,
Metrics: And measure …,
Criteria: We are right if…
This way each requirement is really setup as a hypothesis that later becomes a requirement or a feature if the hypothesis is proven true. This in turn leads to an MMF.
Problem interviews and solution interviews whether in person or via surveys help in validating internally that we are solving the correct problem and the solutions proposed properly address these problems.
Creating personas help in understanding the different user groups, their demographics, behaviors, and needs.
Creating journey maps through the entire process from beginning to end help in understanding specific pain points for each persona.
Storyboarding, sketching, and building prototypes help in validating the solution proposed. Running usability testing on our prototypes and later on our product ensures the feature is meeting its intended purpose.
Feedback from these learnings is applied into the next cycle and is used to determine the next MMF to work on.
It’s important to note that Lean Discovery is not a phase we do at the beginning of a project, but it’s an ongoing activity of discovery feeding an ongoing activity of delivery as well as validating the ongoing results of delivery and determining what to build next. This is referred to as Hypothesis Driven Development (HDD). To make this work we need to apply Agile Delivery techniques that allow us to quickly build and deliver a feature to further validate it’s viability, feasibility and usability.
Also check out the Lean Discovery, Agile Delivery, and DevOps Mindset presentation slides here as well as the entire Digital Service Delivery blog series: