XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

MVP is NOT about Building a Miniature-Version of your Product

Saturday, October 12th, 2013

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.

Vision to Validated Learning

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.

Feature Stub

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.

Experimentation Driven Decision Making Workshop

Tuesday, March 19th, 2013

In the last couple of months, I’ve got several requests from top-notch product companies in India, asking me to facilitate a hands-on workshop on decision making using Lean-Startup’s hypothesis validation techniques for their Executive and Senior Management. I’m thrilled to know that companies are seriously exploring these options.

Following is a 1-Day workshop which I’ve successfully ran a few times:

Experimentation Driven Decision Making Workshop

Large number of products/services fail today, not because they cannot be built and delivered, but because the entrepreneurs building those products/services are disconnected from the people consuming them. This disconnect, leads to early assumptions about consumer’s behavior and motivations. To one’s surprise, these decisions can turn out to be based on stupid (read as: deadly and risky) assumptions.

Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best product/service in that category, launch it, and then observe user behavior. And of course the big bucks spent on marketing campaigns. Surprise! Surprise! This can be a very time consuming & expensive process; not to mention the huge opportunity cost.

Learn Measure Build Cycle

(src: Kent Beck)

Luckily today, we know that many entrepreneurs are using Lean-Startup methodology’s Customer Development practices to help them make important product/service decisions (cheaply) based on Validated Learning.

This workshop will give you a hands-on experience to formulate and quickly test out your value and growth hypothesis.

Process/Mechanics

This is a group activity and the participants have to work in small groups.

In the first one hour of the workshop, each group has to come up a product/service idea, which they believe will really succeed. Then they craft out the elevator pitch about the product/service and put together a basic business model. Post that, the group has to clearly highlight what are their value and growth hypothesis.

The rest of the workshop is dedicated to the participants trying to validate their hypothesis. They can use phone and/or Internet to do their research and validation. The best results, of course, are got when the participants meet real people face-to-face to validate your hypothesis. I’ve seen participants wait outside restaurants, cafes, health-clubs, malls, etc. to run their tests. Some participants also get really creative and build some paper prototypes or fake products to validate their hypothesis. Using a fake credit card swiping machine to see if people will really pay is one of my favorite validation techniques so far.

It always amazes me how creative people can get during this process. Also it’s very fulfilling to see the “Aha moment” on the participant’s face. I can’t describe in words, the shocked look on their faces, when they spend the day validating their hypothesis and discover various hidden assumptions about their target user’s behavior.

Learning Outcome

  • Learn how to decide which assumptions you MUST absolutely test.
  • Understand why just marketing metrics won’t help you make a better product/service.
  • Master the art of leveraging the Minimum Viable Product to create maximum validated learning for minimum cost.
  • Learn how to systematically decide when to Pivot to a new strategy.

Workshop style

Interactive dialogues, case studies, hands-on group activities, and on-field exercise.

The Ever-Expanding Agile and Lean Software Terminology

Sunday, July 8th, 2012
A Acceptance Criteria/Test, Automation, A/B Testing, Adaptive Planning, Appreciative inquiry
B Backlog, Business Value, Burndown, Big Visible Charts, Behavior Driven Development, Bugs, Build Monkey, Big Design Up Front (BDUF)
C Continuous Integration, Continuous Deployment, Continuous Improvement, Celebration, Capacity Planning, Code Smells, Customer Development, Customer Collaboration, Code Coverage, Cyclomatic Complexity, Cycle Time, Collective Ownership, Cross functional Team, C3 (Complexity, Coverage and Churn), Critical Chain
D Definition of Done (DoD)/Doneness Criteria, Done Done, Daily Scrum, Deliverables, Dojos, Drum Buffer Rope
E Epic, Evolutionary Design, Energized Work, Exploratory Testing
F Flow, Fail-Fast, Feature Teams, Five Whys
G Grooming (Backlog) Meeting, Gemba
H Hungover Story
I Impediment, Iteration, Inspect and Adapt, Informative Workspace, Information radiator, Immunization test, IKIWISI (I’ll Know It When I See It)
J Just-in-time
K Kanban, Kaizen, Knowledge Workers
L Last responsible moment, Lead time, Lean Thinking
M Minimum Viable Product (MVP), Minimum Marketable Features, Mock Objects, Mistake Proofing, MOSCOW Priority, Mindfulness, Muda
N Non-functional Requirements, Non-value add
O Onsite customer, Opportunity Backlog, Organizational Transformation, Osmotic Communication
P Pivot, Product Discovery, Product Owner, Pair Programming, Planning Game, Potentially shippable product, Pull-based-planning, Predictability Paradox
Q Quality First, Queuing theory
R Refactoring, Retrospective, Reviews, Release Roadmap, Risk log, Root cause analysis
S Simplicity, Sprint, Story Points, Standup Meeting, Scrum Master, Sprint Backlog, Self-Organized Teams, Story Map, Sashimi, Sustainable pace, Set-based development, Service time, Spike, Stakeholder, Stop-the-line, Sprint Termination, Single Click Deploy, Systems Thinking, Single Minute Setup, Safe Fail Experimentation
T Technical Debt, Test Driven Development, Ten minute build, Theme, Tracer bullet, Task Board, Theory of Constraints, Throughput, Timeboxing, Testing Pyramid, Three-Sixty Review
U User Story, Unit Tests, Ubiquitous Language, User Centered Design
V Velocity, Value Stream Mapping, Vision Statement, Vanity metrics, Voice of the Customer, Visual controls
W Work in Progress (WIP), Whole Team, Working Software, War Room, Waste Elimination
X xUnit
Y YAGNI (You Aren’t Gonna Need It)
Z Zero Downtime Deployment, Zen Mind
    Licensed under
Creative Commons License