[SOUND] Earlier in this course, we took our initial business idea and

expanded on it to explore all sections of a working business model.

What do you think our next step should be?

The most common advice and

what we tend to do naturally, is to start building our product or service.

So, that's what I should probably do, right?

Immediately start building my project management software, so that I

have a fully functional product that I can show my customers and get excited.

Now this software should include all the features I listed down, and

be all shiny and glossy so my customers really want to use it.

Unfortunately no, that's counter-productive.

At this point we have absolutely no idea what our customers want.

We think we know our customers because we sat here brainstorming, but remember,

those were only assumptions.

You may be thinking, well I am a customer, I am in need of this product, so

I am sure there are others out there who need this product too.

Now that may be true, but you will find that there are lots of

people who say that they would find the product useful, and they would use it.

But only a small portion will actually pay real money for

the set of features that you offer.

The best thing that you can do is to build a product that you

know with certainty that your customers want.

And how do you know exactly what they want?

By getting out in the real world and talking to them.

After developing our initial business model,

the next phase of starting a business can be broken down into the following steps.

Conducting an experiment to test each assumption we built in the business model,

engaging with customers and

testing their understanding of the model, understanding our customers better.

Implementing the insights gained from conducting each test.

Why do we test though?

All this seems like a waste of time and

effort when we could be launching our business to the public.

Validation is an extremely important process and

crucial to succeeding as a business.

Anytime spent building a product before validating our assumptions can be

a waste of time.

There are many reasons why validating is a good idea.

We've made a lot of assumption when fleshing out our business model.

We need to get out and test these assumptions, so

that we can validate whether our hypotheses are correct.

Validating your ideas before you build can save you a lot of time and

money, by avoiding a situation where you build a product that no one wants.

Validating your assumptions gets you connected with your customers.

This is invaluable, and

the first step towards a methodology called validated learning.

Validating will give you a fresh set of eyes on your product or

service, and help you refine your ideas.

And finally, and most importantly, by validating your idea with customers, you

figure out real quick if there are people out there willing to pay you real money.

When we put together our business model, we made a lot of assumptions.

We assumed that there are groups out there who didn't have a perfect product to

fit their needs.

We assumed that existing products didn't cut it for them.

And finally, we assumed a lot of things about our service.

Value proposition and all down to the individual features.

When validating, it's good to break all this up into different segments so

that we get meaningful insights.

Test your riskiest assumptions first,

since a lot of other things depend on them.

In conducting our experiments, first we're gonna validate our market, and

then the problem.

My hypothesis, or assumption, is that there are lots of small groups out there

who find current project management software complicated or too complex for

their uses.

Is this true?

When validating our assumptions, we need to gauge the size of the market.

Just because a few people confirm your assumptions,

that's not enough to run a business off of.

Make sure you have a sizable market, and I really mean sizable.

Withe each successive filter, the number of people that drop off will be

quite large, so make sure your market hypothesis stands up to a large number.

Then we need to validate the problem.

New customers have the problems you think they have?

Do they suffer the same pain points you do?

My claim is that existing software is focused too much on

either the individual or enterprises.

There is a gap in between where smaller organizations need certain tools, but

they're priced too high.

We need to get out there and make sure that this is true.

When validating our problem, like when we validated our market,

it can be tempting to talk to family and friends, or people that you know for

certain experience the same problems that you have.

Now this will wrongly influence your learning and

decisions, take pains to identify the right groups of people.

Understand how they currently solve your perceived problem, and

how they would like to see it solved.

Don't force your assumptions on them, because that pollutes your findings.

You are not there to convince them that they need your product,

you just want to validate the problem and

figure out how you can craft a solution to fit your customer's needs.

The experiments we design to test our assumptions should not be complicated, and

they should not take much time.

They should be simple pass or fail tests that let us quickly gather data.

Go out and talk to a bunch of customers.

Do they experience the same problem we're trying to solve.

Yes or no?

Set a bar that you need to cross.

For every 50 people you talk to, at least 35 need to say,

yes, we're experiencing the same problem.

The larger the test, the greater the pass rate needs to be.

If only ten people confirm that they experienced the problem,

that means only a smaller subset of this may validate the product, and

an even smaller subset will pay for it.

Once you have validated the market and

the existence of the problem, then it's time to validate your product.

Traditionally, when people think there's a problem to be solved,

they spend six months to a year building something.

Only to launch and

find out that the product fails because it doesn't adequately solve the problem,

the problem doesn't exist, or the market isn't even sizable to begin with.

By validating first, we make sure the product we build, and the time and

money we invest, is actually worth it.

If you think of these different stages of validation as filters to our assumptions,

then each stage of validation eliminates a bunch of assumptions.

The ideas that we are left with in the end are what makes for

a potentially successful product.

Your thought process should go something like this.

[SOUND] Do consumers recognize that they have the problem you're trying to solve?

[SOUND] If there was a solution, would they buy it?

Would they buy it from us?

And can we build a solution for that problem?

And how do we test these things?

By talking to customers.

There's no other way.

Don't substitute Google keyword research or

Facebook data for actual customer insights.

Testing the market and your problem, the first step, will be hard.

You have to identify potential customers.

Now this is important, don't just ask your friends and family.

Contact them and then convince them to give you some of their time.

You should aim to talk to around 30 customers per week during the initial test

phases, so keep looking for potential customers you can get in touch with.

You don't need exactly the right customer, you just need to find someone who

loosely fits the hypothetical customer archetype that you developed.

Now that we know why we should conduct experiments,

let's look at how we can do that.

But before we move on, let's recap.

After you develop the first iteration of your business model,

you need to test all the assumptions.

Validating our assumptions is an important activity,

because validating your ideas before you build can save you a lot of time and

money by avoiding a situation where you build a product that no one wants.

Validating your assumptions gets you connected with your customers.

You start by validating your market.

If this test passes, validate the product.

Your experiments should be simple pass fail tests that enable you

to quickly gain feedback and move on to validated learning.

Finally, all experiments should happen through customer interaction.