"Do not try to build the perfect product!" — is advice I frequently give to clients. Feel free to launch a product with bugs, and do not worry if it is missing features. Before you hang me, hear me out.

I recently had lunch with an acquaintance. Let's call him Archie. Archie invited me to lunch because he wanted to discuss a great idea he had just had. He also wanted my help with executing the idea. His idea was a digital gift that was truly unique and a forever-lasting memory. His wife ended up in tears as she received her gift. He was head-over-heels with this idea, and I must admit, I liked the idea myself.

Ideas like this don't come around very often, so Archie jumped in head-first into execution. He was creating content, building software, drafting a marketing plan. The whole package. But he didn't quite understand why I wasn't as eager to jump in with him. He would, after all, provide us with months worth of development work!

– Don't we have the necessary capacity? – We do. – Don't we have the necessary capabilities? – We most definitely do. – Don't I like the idea? – Yes, I do like it. – Then what's the issue?

I asked Archie to write down how the project would make him money. – Nothing easier: we'll have at least 100k customers/month who will buy the product for $1 each.

– Great! What are these numbers based on? – Well, we can easily reach this many people by running social media campaigns. The receiver of the gifts will like it so much that they will re-gift to others themselves.

I could've proceeded with the interrogation, but I felt that I had enough munition at this point.

– Listen, Archie. Let's take a look at our current assumptions about our customers:

• that they will certainly like the product (– That's a given. 3 out of 3 people like it! – Doesn't matter. It might be just us that are strange. I for one, know that for sure about myself.);
• that they are prepared to pay $1 for it (– Why is it $1 anyway? – Because that's peanuts! Everyone would pay that much. – How do you know they wouldn't pay more? – Well uhm…);
• that we will be able to reach 100k buying customers;
• that it won't be only a seasonal gift;
• that customers will like it so much, they will re-gift;
• that we are going to have returning customers;

– How do we know all the assumptions are valid? – That's precisely why the product has to be perfect so that they will like it 100%.

At this point, I recommended that Archie take the one finished product he already has, the one he created for his wife, and show it to as many people as possible. To create a presentation video and run an advertising campaign on that. Gather data on how many people ask him to get a similar product. Ask them how much they would be willing to pay for it? How many times and for how many people would they buy this product in a year?

Validated learning: a nonconventional way to build products

All this was hard for Archie to comprehend. This way of thinking is entirely different from conventional product development methods, which is to perfect the product before launch: thorough market research and a solid strategy were indicators of likely success. We call this traditional way of launching a product a Big Bang delivery.

We could ask ourselves, what happens to the energy and money invested in the product if we get negative reviews from the clients because the product is not perfect? Fair enough.

We should be asking ourselves, though, what happens if we invest multiple times that energy and money into developing a product that customers will not buy?

If we strive for a perfect product, we will most likely never find out which of our base assumptions were wrong, leading to the complete overhaul of our product. Instead, suppose we proceed with developing a product in small iterations, with minimal effort and continuously putting our assumptions to the test. In that case, we will be able to integrate customer feedback into the newer iterations of the product. In product development, we call this validated learning.

Build. Measure. Learn!

Validated learning exists to disperse uncertainty and minimize the inherent risk in a startup project. In practice, validated learning is easiest to achieve through the Build-Measure-Learn feedback loop.

The Build-Measure-Learn loop helps us to find answers to our assumptions or hypothesis. Although we will be looking to answer different core assumptions at different stages of product development, one thing will be certain: our most important task is to gather as much actionable knowledge as possible in the shortest time possible.

There are various ways to test a different hypothesis, most often with the help of an experiment. We should build these experiments with minimal effort (or development time in the case of software). Their sole purpose is to test (validate) our assumptions. We often leave out features that are otherwise considered essential to the final product because of this.

Creating an experiment will be the Build phase of our Build-Measure-Learn feedback loop.

It's not enough to, in fact, it is crucial not only to develop an experiment for internal use. If only our inner circle had access to the experiment, we could easily get the false sense that everything works and our assumptions are correct.

We should get the experiment in front of potential customers as soon as possible, gauge their reactions and gather feedback and actionable metrics.

Getting feedback from customers is the Measure phase of the Build-Measure-Learn loop, followed immediately by the Learn phase.

Based on the feedback and metrics gathered, we should again look at our base assumptions. How many have did we proven to be true? Are we closer to our product vision? If we are, we should define a new set of assumptions, fine-tune or create new experiments and start the Build-Measure-Learn loop again.

If some of our assumptions are proven to be false, we should consider a pivot. A pivot means planning a new strategy to achieve our vision.

"Although we write the feedback loop as Build-Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn, (...) figure out what we need to measure to know if we are gaining validated learning, and then figure out what product we need to build to run that experiment and get that measurement."

Archie's situation is relatively simple because he already has a finished product that he can use to validate his assumptions: the gift he gave to his wife. He could show this product to potential customers and gauge if they like it or not and if and how much they would be willing to pay for it.

If feedback were to be positive, that's great. Archie could start another iteration of the Build-Measure-Learn loop. He could now begin making these digital gifts and sell them to others.

At this stage, he still wouldn't have to create all the content and build software to automate the process and handle every use case fully. It would be enough to take these orders one at a time, write the content and assemble the gift.

Although this takes some effort, this would allow him to test further assumptions: will he have enough customers and how many of them will return to buy again? He would also get feedback from the customers on improving the product, which he could integrate into the final product. Archie would not have had this option if he had created all the content beforehand.

So what happened to Archie in the end?

Unfortunately, Archie decided to jump in and create the perfect product. I would like to believe this is because Archie had an industry background in a field where Big Bang delivery is the de facto standard, but it might just as well be that my arguments weren't strong enough. Time will certainly tell if the project ends up being a success.

Our experience is that most founders fail at first because they fall in love with their idea. Their product cannot be anything short of perfection, with endless eye-catching features and glitter. Most successful founders have already failed 1 or 2 projects because of this, but they have learned from their mistakes.

They, as well as Archie, wanted to build the Death Star from the get-go. You don't have to be like Archie!