Please watch the video below and post your key takeaway(s) from the two
articles and one video on Minimum Viable Products.
How I chose my first MVP The Lean Startup advocates an iterative approach to building a business, with each iteration teaching you something actionable. An
important tool in this iterative process is the Minimum Viable Product (MVP). In his book The Lean Startup, Eric Ries briefly defines an MVP: A minimum viable
product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the
fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort. Contrary to traditional product development, which usually
involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or
concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses. Note that MVPs don't
need to be actual products; an MVP is simply the quickest thing you can make to learn about your next most pressing hypothesis. In his article Signs you aren't really
building a Minimum Viable Product, Anthony Panozzo argues that most people who claim they're building an MVP actually aren't: If you are building out a half of a
product as your first stab, you might as well just call it version one or iteration zero or something like that. No sense in polluting the MVP term. This makes a lot of
sense. Having read it, I felt strongly that I ought to be able to demonstrate whether or not there was significant demand for Agile Planner without actually having to
build it. Anthony's article goes on to lay out three key questions that he puts to people who tell him about their MVP: 1. What are you trying to learn with this particular
MVP? 2. What data are you collecting about your experiment? 3. What determines the success or failure of the experiment? It's a great article, and I recommend you
read it. So what happened when I applied Anthony's questions to Agile Planner? The answer to question 1 (what am I trying to learn?) is easy: I want to learn whether
there's a market for a less opinionated agile app, with a simple UI based on the metaphor of the index card. Questions 2 and 3 are harder to answer, but provide a good
context in which to evaluate your MVP. After a week or so of research (and some serious thought), I had three candidate MVPs: • A landing page explaining the
product, a "Buy" button, and an Adwords campaign. • A survey designed to identify how many people would pay for my app. • A demo video highlighting the
differences between existing products and Agile Planner. How do these ideas fair in the light of Anthony's three questions? Idea 1: A landing page, a Buy button and an
Adwords campaign The landing page approach is simple. You setup a simple web site explaining your concept and add a call to action. You can ask people to sign up to
your mailing list if they're interested, or take it a step further and offer them a chance to sign up for a paid product. Anthony's second question is "what data are you
collecting?". If you're building a B2B (business-to-business) product its important to prove that people are prepared to pay for your product; it's not enough that they
like it (see The Order of AARRR by Brant Cooper). I felt my call to action should validate people's intent to purchase, so I'd setup a "Buy" button rather than just a
mailing list. Anthony's third question (what determines success or failure?) is the most difficult to answer. I've no idea what percentage of my visitors I should expect to
try and buy the app. If I got 100 clicks, and only one person tried to buy it, what would that tell me? Lots of attempts to purchase the app would confirm demand for the
app. But if nobody clicked, it could just mean that I hadn't explained the point particularly well. This would have been an experiment that couldn't fail. The results
wouldn't be actionable, as I'd have felt there was plenty of mileage in my ideas even if nobody tried to buy it. It was tempting to give up on MVPs at this point and just
get on with building version 1, but I'd well and truly tethered my horse to the "maximum validated learning for minimal effort" train, and I was damned well going to
apply it. Idea 2: A survey Let's recap. What am I trying to learn? I want to learn whether there's a market for a less opinionated agile app, with a simple UI based on the
metaphor of the index card. Question 2 (what data are you collecting?) seems straightforward for a survey; you look at the answers and categorise them according to
how likely you feel each respondent is to use your product. Question 3 (what determines success or failure?) appears easy on the face of it; you could define a minimum
number of positive responses before you start. And yet, as far as applying the scientific method goes, there's a problem. If your results could be skewed by the questions
that you're asking, how do you determine whether or not you've biased your results? If your results are biased by your questions, how do you know how much you've
biased them by? And how can you reliably make decisions moving forwards from data that you know to be inaccurate? I might be able to write a survey that would
reveal whether respondents were unhappy with existing products, but I couldn't see a reliable way to find out whether or not they'd want to pay for my app. You could
argue that proving that there's discontent would be enough, but that wouldn't tell me anything I didn't already know (developers are a vocal bunch). Idea 3: A demo
video In The Lean Startup you can read about Dropbox's MVP. Drew Houston (the CEO of Dropbox) made a four minute video that highlights the main features of
Dropbox. It really gets across how simple Dropbox is to setup and use, and it's no surprise that they had 70,000 people join their waiting list within days. This approach
really appeals to me; there's no easy way to explain the intangible aspects of how Agile Planner will work in static words and pictures. It's a little bit different to the
competing products, and people familiar with the existing tools are going to need to see it in action to fully understand where I'm coming from. It's not enough for them
to decide to buy it because they think it looks pretty; I need to know whether they still want to buy it after they've appreciated what it won't do. On the face of it, it
sounds good. Let's ask Anthony's questions again... What data are you collecting? With a video you can track: • how many people visit the page, • how many start
watching the video, • how many stop watching the video part way through (and if you use Wistia, you can see how far they get), and • how many people go on to try
and purchase your app. What would determine the success or failure? I had plenty of confidence that a well made video would make it clear how Agile Planner would
behave. If few people watched the entire video or tried to buy the app I'd be confident that there was a problem with the basic premise of the idea. I knew I could post
the video to Hacker News and ask for feedback from other entrepreneurs (Daniel Tenner has some good advice on how to go about it). The Hacker News audience isn't
really an agile audience, but I felt there'd be enough overlap, and the feedback from other entrepreneurs would be useful. I realised I could also ask for feedback on agile
forums, LinkedIn groups, etc. I'd track the conversion rates from these different sources independently, in case a high number of visitors from Hacker News skewed my
results. I decided that if at least 50 people tried to purchase the app I'd be justified in building version one. If I couldn't get 50 signups, my next task would be to work
out why. So how do you make a demo like Drew's in as quickly as possible? That's a story for another post... Graham Ashton is an experienced agile team leader and
project manager, and the founder of Agile Planner. You can follow him at @grahamashton on Twitter.
The most important thing to remember when starting a new corporate venture or startup business is not to fall in
love with your first ideas. What you really want to do in the beginning is to rapidly explore different
alternatives. Don't spend time agonizing over the perfect solution and don't expect to get everything right all up
front. Use the Business Model Canvas to explore several alternative business model prototypes for your idea.
But what actually is prototyping? Prototyping (pro•to•typ•ing) The practice of building quick, inexpensive, and
rough study models to learn about the desirability, feasibility and viability of alternative solutions. Prototyping
is common in the design professions for physical artifacts but you can also apply the practice to your business
idea. Use the activity of making quick and rough study models by rapidly sketching out several canvases. Focus
on a different theme for each prototype. Explore business models that are scalable, have recurring revenues,
lock customers in, that include strategic partners, or that use different channels. To unlock the power of
prototyping, resist the temptation of spending time and energy refining towards one direction only. Rather, use
the principles described here to explore multiple directions with the same amount of time and energy. You will
learn more and discover better business models as you quickly explore radically different directions for the
same idea with the following prototyping techniques.
10 Prototyping Principles
1. Make it visual and tangible These kinds of prototypes spark conversations and learning. Don’t regress into
the land of blah blah blah.
2. Embrace a beginner’s mind Prototype “what can’t be done.” Explore with a fresh mind-set. Don’t let existing
knowledge get in the way of exploration.
3. Don’t fall in love with first ideas — create alternatives Refining your idea(s) too early prevents you from
creating and exploring alternatives. Don’t fall in love too quickly. Feel comfortable in a “liquid state” Early in
the process the right direction is unclear. It’s a liquid state. Don’t panic and solidify things too early.
7. Learn faster by failing early, often and cheaply Fear of failure holds people back from exploring. Overcome
that with a culture of rough and quick prototyping that keeps failure cheap and leads to faster learning.
10. Track learnings, insights, and progress Keep track of all your alternative prototypes, learnings, and insights.
You might use earlier ideas and insights later in the process.
5. Start with low fidelity, iterate, and refine Refined prototypes are hard to throw away. Keep them rough,
quick, and cheap. Refine with increasing knowledge about what works and what doesn’t.
8. Use creativity techniques Use creativity techniques to explore ground-breaking prototypes. Dare to break out
of how things are usually done in your company or industry.
6. Expose your work early — seek criticism Seek feedback early and often before refining. Don’t take negative
feedback personally. It’s worth gold to improve your prototype.
9. Create “Shrek models” Shrek models are extreme or outrageous prototypes that you are unlikely to build. Use
them to spark debate and learning.
Additional Tips • Spend a maximum of 5 to 15 minutes on sketching out your early prototypes. • Always use a
visible timer and stick to a predefined time frame. • Don’t discuss too long which one of several possible
directions to prototype. Prototype several of them quickly and then compare. • Remember constantly that
prototyping is an exploratory tool. Don’t spend time on the details of a prototype that is likely to change
Purchase answer to see full