I'd like to talk about how we validate our processes.
One of the techniques that comes up, often is the minimum viable product. And what's interesting
is that the meaning of the minimum, viable product has
taken a lot of twists and turns since its Inception. These days, I'm
seeing a lot of companies take it to mean Phase 1. The
first phase of the actual product itself.
But in reality, the minimum viable product is the
smallest thing that we can make.
Or do to test our hypothesis.
That is the actual MVP. It is the first version of our product
but it's the smallest thing that we can make or do
to answer the questions that we have.
And there are different types of MVPs that feed it to different types of experiments that help us
validate whether our assumptions are
correct or incorrect and I'd like to go through three
examples of MVPs that feed into specific types of
experiments. The first being a pre-sales
experiment where you can use something like a landing page. Your Kickstarter will talk about that.
The second is a call to action button sometimes called the fake door. And the last is
the
Years for The Wizard of Oz MVP.
Pre-sales MVP and kickstarter's a terrific way to test this, but any kind of landing
page or opportunity for customers to commit to backing. Your
product is an opportunity to test your ideas. Kickstarter
essentially, you have to create a marketing page. That sells your idea that
convinces people to give you money for your idea. You
actually don't have to create anything other than the marketing
page for the site itself and whether you use a Kickstarter page or a
landing page that the
Vibes your product and asks, people to sign up or to back it or to tell
their friends about it or to give you an email address.
All of these things are very low threshold experiments that
allow you to practice a couple of things. The first and foremost is to understand how
to tell the story of your product. For example, you may build a
landing page or a Kickstarter page and you may not get any backers or any
clicks or any conversions. Does that mean your idea is a bad idea.
Maybe or maybe that you have not told your story in such a in a
compelling enough, fashion that people are buying in. So you have the opportunity to
iterate that forward
Very quickly and very rapidly. You can get a landing page up and
running in a half a day with halfway decent design. You can certainly get a Kickstarter page up and
running very very quickly to see if people will give you money. And again you don't have
to build a single part of your product. You're promising a service,
you're promising a product, and you're asking people if they're willing, if it's if it's
compelling enough of a proposition for them to give up some kind of
information or potentially, even to give up money for it.
And that's a terrific signal from the market that says, yes, this is interesting to me.
And in the process, you're learning how to market the product, how to tell the
story, what words to use, how to be compelling
in describing the benefits of this particular service or
product?
Get Low, Low threshold, low cost, lots of
learning, lots of iterations. And what you're doing in the process is also you're
collecting a list of people who are interested in using your product in the
future. So when the product does exist, you can actually let them know that this thing
exists and engage them further in later experiments that are of
higher fidelity.
Another type of any piece of the call to action button, sometimes called the button to
Nowhere or the fake door. And the reason for this is that
this the the idea behind this is that it's cheaper
to create a fake version of a feature than it is to actually
create the feature. For example, this is this is a company
called speak their startup out of Washington DC and they create an
online conference calling service surprisingly enough.
One of the features that they were testing was the ability for you to put your number into the
service and have the service dial you into your conference
call. So no more remembering 800 numbers and long pins.
Simply put your number in press the call me now button. And your dialed into the
call, it calls your number and dials you in this is an extremely expensive and
risky feature for them to implement especially as a start-up with limited Runway and
limited funds. And so the first thing that they did was they
implemented a form.
That provided the talked about this feature, that provided the ability to
engage in this feature, but that actually didn't do anything.
It's a fake button. They can get this form up and running in two hours and
as people transacted through their system they got a
sense of whether or not people actually wanted this feature.
Within the context of use, of their application. So if you went to your
customers and you ask them, hey, would you like this feature? Oh yeah,
absolutely. That feature sounds great. I'd love that. But then when you
actually build that feature, would they actually use it is unclear. People
say into and do two very different things.
The buttons to know where allow you to create the perception of a feature
within the workflow of your application and it's
a capture people's clicks, their intent to use the feature
within the context of views.
Now, of course, you can't put a bunch of these in your product because you end up with a Swiss cheese
product with a bunch of links that don't do anything. And as a level of
frustration that's going to drive your customers away. So your goal
is to get insight very very quickly that there's interest in this feature that people are clicking
through to capture those clicks.
And then to decide whether or not to invest in this, in the take this down. Now, in this case, especially if
you're working with an existing product in an existing user base, you can
figure out who click this button as well.
And once they fall into your mouse trap, you can get back to them and say, Hey listen, you fell into
this feature that we're just testing. It's not ready. Maybe we can give you a month's free
service just because we appreciate your participation in our test, right? To
sue things over at the click of the button will generate some kind of a form. This
is oh you caught us off guard or we're not ready to with this
particular feature but we'll let you know when it's ready. The
goal again is to capture a threshold something that says to you
based on the number of users that you've got traffic
Looking through your system that says of the 10,000 people that use our service
every day. If we get 50 people to click this button, it's worth the
investment and so you can you can get that Insight very very quickly
and learn whether it's worth to invest further in this beyond the two hours. It takes to set
this up.
The last of the next type of MVP is the concierge or The Wizard of Oz
and would be the concept here is that there's there's a person behind the
curtain, running the service, there's a facade of a service.
And if there's a person behind that facade manually running what appears
to be a digital service.
The example, I like to use is a service that has shut down. Now called City Pockets
City Pockets was a service set up, during the Heyday of the daily deal
craze LivingSocial and Groupon, and people were not redeeming their
daily deals. They were buying a bunch of them and they were losing track of them. And so the
service that was set up, here was called City pockets in the idea, was this, this was a
wallet for your daily deals.
So, you would sign up for the service.
You would get an email address. You would forward all of your daily deals to this email
address. The daily deal email would be automatically parsed
into a database under your name.
And you can come back here and redeem the deals as needed or the service would email you. And
let you know that your deal is about to expire and you should come here and redeem it
Now the most expensive part of setting up the service was the automatic parsing of the database,
the automation, of the database.
And so the woman who started this company created a concierge MVP and
she created literally two pages for this product. There was the
landing page that promoted the service and taught her how to sell and tell her
story with a sign-up button. And there was the sign up
page, which allowed people to sign up for the service. Everything
else behind the scenes was done manually. When you signed up for the
service, she would generate that email to you.
every time that you forwarded, a daily deal to that email address,
She would manually parse out that daily deal into the
database.
And give you a heads up as your daily deals, were about to expire. Now for
her, there was a threshold of 500 emails a day. When she got
500 of these emails a day, she could no longer support that process
manually and it was worthwhile at that point you get clear signal from the
marketplace. That said it's worthwhile for you to invest in the
automation of the service.
Until then there was no proof that people would actually use the service
to a level where it was worth investing. In once she hit that
threshold, she hired a team and invested in the back end of that service.
But until then that service was literally a landing page and a
sign of page and a couple of people behind the scenes. Moving data around between
databases and email programs.
What she did here with d risk, her software project she could have built
the whole thing from from the beginning. But if people didn't want the
service, or didn't use the service, that would have been waste. She didn't
know if that was going to be the way it worked. And so she was slowly moving
from doubt to certainty.
The definition of MVP that I laid
out a few minutes ago, was the smallest thing that you can make or
do to test your hypothesis. This is an example of the smallest
thing that you can do to test your hypothesis is a non-technical
MVP. The company here is order in
there a white label food delivery infrastructure. Startup based in New York City, the
idea being that if you'd like to offer food delivery either through your service or
through.
Your hotel chain. You can they provide the pipes, you provide The
Branding, and voila, instant food, delivery services, with
your name, on it. The gentleman who started this company was not a designer,
not an engineer. Not a product manager. He was a Salesman
and so he had a vision for this and he wanted to test the waters and so he did
what he knew, how to do, which was sell, he wrote a
contract that describe the service, it had a price for the service.
Yes, and it said you don't have to pay me until I actually deliver the service,
and he went out, and he sold that contract, that contract was
his minimally viable product, that was his MVP. And his
threshold for Success was 10 signed contracts. When
he had 10 signed contracts, he then went and hired the
team and started to build this company, which exists
today.
He tested his hypotheses, doing the smallest things, that he knew
how to do.
And I would urge you to test your assumptions and your hypotheses based on
the things that you're very good. At one of the things that we can make or do
to test our assumptions to take us a step closer from doubt
to certainty and to de-risk the project as quickly and
efficiently as possible. That's your minimum viable product and that's your
experiment.