May be I don’t understand the Lean-startup lingo, but to me a MVP has always been about finding the cheapest, safest way to validate your product hypothesis. Sometimes you might need to build a miniature version of your product or service to test your hypothesis and obtain validated learning. But it is not always necessary or even desirable to build something.

Let’s zoom out for a minute. Let’s say you have an idea or a vision for a product or a service. You devise a series of possible strategies you could use to fulfill your vision. However it is important to acknowledge that each of your strategy is based on a list of hypothesis, which needs to be validated using a series of cheap, safe-fail experiments (via MVPs) to obtain validated learning. Then based on real data, we pivot or persist the direction of the vision. Either ways, you need to constantly keep running a series of experiments with real fast feedback cycles to calibrate/validate your progress/direction.

MVP is a safe-fail experiment. The best MVPs are those which give you maximum validated learning for minimum investment (time, effort & opportunity cost.)

For example:

• NeedFeed used a GreaseMonkey script to quickly validate their hypothesis about their social purchasing app on Facebook – http://vimeo.com/24749599
• At EdventureLabs we used presentations to create quick videos to test different learning techniques and their retention power with kids.
• Or we used dummy meters to validate the business model of an energy company, which wanted to build energy saving products for rural India. We visited a few farmers and small factories, explained how the device (dummy meter) would save them 50% on electricity bill each month. We quickly discovered that our business model was flawed and surprisingly we co-created a better model. Also through this process we learned about certain key concerns these folks had which required a very different conceptualization of the product.

Your ability to quickly (almost on the fly) tweak a little parameters and quickly test a corollary hypothesis is another very important characteristic of an MVP.  This is extremely important because when you go out there in the field to run your experiment, in the moment, you might find new data or ideas which might need to be validated to solidify your validated learning. If you have to make code changes and deploy stuff, it might not be easy for you to test new hypothesis, right then and there. Which is very important IMHO.

Next time you think of a MVP, think about a cheap, safe-fail experiment you can run to validate your hypothesis.

Note: Its important to distinguish MVP from Features Stubs. Feature stubs are also a quick way to validate your hypothesis, however they are mostly applicable once you have a product and want to validate how useful certain feature might be.

For example: Recently, I wanted to test if liking a comment on the Agile India Submission system is a feature people would find useful.

I added a like button which would simply show an alert message saying “Coming Soon..”. Using Google Analytics, I was able to measure that out of 36,000 impressions, only 6 people clicked on the Like button. A cheap way to validate my hypothesis. But this does not affect my product strategy and hence its different from MVP.

At EdventureLabs, we were trying to teach kids age (5-7,) to represent numbers on the Abacus. First we created a small animation video with a little story line. We took help of a professional animation expert. However, we quickly realized that kids have very little attention span and if they are not able to interact with what they are seeing on the screen, they quickly (in less then 30 secs) zone-out. Also animation was expensive and had a huge turn-around time even if we wanted to make a small change. Clearly a bad strategy.

Inspired by lot of mobile games, we came up with a hypothesis that if we created inline instructions and used micro-simulations, then the kids would have a better retention power and hence be able to learn much better. We wanted to quickly test this hypothesis.

However we had not yet built an app, so building an app and creating a simulation would take us a few days. But we wanted to quickly test the simulation hypothesis to see its effectiveness. So we took a short-cut.

We quickly (in less than 10 mins) found a bunch of images on the net, created a presentation and added a bunch of transition to create an animation effect. Then we exported this presentation out as a movie.

Now the kids were able to watch this 10 second movie, like they would see a simulation/inline instruction in our app. Once the simulation showed how to represent a number, we would ask the kid to move the right beads on the abacus. Of course the beads would not move, but we would be able to test whether the kids tried to move the right beads and hence assert if they remembered how to represent number. If they could, we would ask them to represent other numbers which were not shown in the simulation to see if they can extrapolate what they just learned and apply the logic for other numbers. Most kids could do simple numbers, but were not able to do all the numbers. Another good learning from this experiment.

Anyway, here is the very first video we created to test our simulation hypothesis.

Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This day long workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

Detailed Activity Breakup

1. PART 1: UNDERSTAND PRODUCT CONTEXT
   • Introduction
   • Define Product Vision
   • Identify Users That Matter
   • Create User Personas
   • Define User Goals
   • A Day-In-Life Of Each Persona
2. PART 2: BUILD INITIAL STORY MAP FROM ACTIVITY MODEL
   • Prioritize Personas
   • Break Down Activities And Tasks From User Goals
   • Lay Out Goals Activities And Tasks
   • Walk Through And Refine Activity Model
3. PART 3: CREATE FIRST-CUT PRODUCT ROAD MAP
   • Prioritize High Level Tasks
   • Define Themes
   • Refine Tasks
   • Define Minimum Viable Product
   • Identify Internal And External Release Milestones
4. PART 4: WRITE USER STORIES FOR THE FIRST RELEASE
   • Define User Task Level Acceptance Criteria
   • Break Down User Tasks To User Stories Based On Acceptance Criteria
   • Refine Acceptance Criteria For Each Story
   • Find Ways To Further Thin-Slice User Stories
   • Capture Assumptions And Non-Functional Requirements
5. PART 5: REFINE FIRST INTERNAL RELEASE BASED ON ESTIMATES
   • Define Relative Size Of User Stories
   • Refine Internal Release Milestones For First-Release Based On Estimates
   • Define Goals For Each Release
   • Refine Product And Project Risks
   • Present And Commit To The Plan
6. PART 6: RETROSPECTIVE
   • Each part will take roughly 30 mins.

I’ve facilitated this workshop for many organizations (small-startups to large enterprises.)

More details: Product Discovery Workshop from Industrial Logic

Techniques

Focused Break-Out Sessions, Group Activities, Interactive Dialogues, Presentations, Heated Debates/Discussions and Some Fun Games

Target Audience

• Product Owner
• Release/Project Manager
• Subject Matter Expert, Domain Expert, or Business Analyst
• User Experience team
• Architect/Tech Lead
• Core Development Team (including developers, testers, DBAs, etc.)

This tutorial can take max 30 people. (3 teams of 10 people each.)

Workshop Prerequisites

Required: working knowledge of Agile (iterative and incremental software delivery models) Required: working knowledge of personas, users stories, backlogs, acceptance criteria, etc.

Testimonials

“I come away from this workshop having learned a great deal about the process and equally about many strategies and nuances of facilitating it. Invaluable!

Naresh Jain clearly has extensive experience with the Product Discovery Workshop. He conveyed the principles and practices underlying the process very well, with examples from past experience and application to the actual project addressed in the workshop. His ability to quickly relate to the project and team members, and to focus on the specific details for the decomposition of this project at the various levels (goals/roles, activities, tasks), is remarkable and a good example for those learning to facilitate the workshop.

Key take-aways for me include the technique of acceptance criteria driven decomposition, and the point that it is useful to map existing software to provide a baseline framework for future additions.”

Doug Brophy, Agile Expert, GE Energy

Learning outcomes

• Understand the thought process and steps involved during a typical product discovery and release planning session
• Using various User-Centered Design techniques, learn how to create a User Story Map to help you visualize your product
• Understand various prioritization techniques that work at the Business-Goal and User-Persona Level
• Learn how to decompose User Activities into User Tasks and then into User Stories
• Apply an Acceptance Criteria-Driven Discovery approach to flush out thin slices of functionality that cut across the system
• Identify various techniques to narrow the scope of your releases, without reducing the value delivered to the users
• Improve confidence and collaboration between the business and engineering teams
• Practice key techniques to work in short cycles to get rapid feedback and reduce risk