Do not try to build the perfect product! is advice I frequently give to clients. Feel free to launch a product that has bugs and definitely 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 just had. He also wanted my help with executing the idea. His idea was a digital gift which was truly unique and a forever-lasting memory. He was head-over-heels with this idea. His wife ended up in tears as she received her gift. And I must admit, I really liked the idea myself.
Ideas like this don't come around very often, so Archie jumped in head-first into execution. Creating content, building a 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 in fact, 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 is going to 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, 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 of our current assumptions about our customers:
– How do we know all the assumptions are true? – That's exactly why the product has to be perfect, so they will like it 100%.
At this point in time I recommended Archie, that he takes the one finished product he already has, the one he created for his wife, and shows it to as many people as possible. That he should create a presentation video and run an advertising campaign on that. Gather data on how many people ask him where they can get one 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 for in a year?
All this was hard for Archie to comprehend. This way of thinking is completely different to the conventional product development methods. This is also called Big Bang delivery. The traditional way of doing things is to perfect the product before launch: thorough market research and a solid strategy were indicators of likely success.
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.
What we should be asking ourselves though, is what happens if we investe 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, if we proceed developing a product in small iterations, with minimal investment of effort and continuously putting our assumptions to the test, we will be able to integrate customer feedback into the newer iterations of the product. This is called validated learning.
Validated learning exists to disperse uncertainty and therefore minimize the inherent risk in a start-up 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 at different stages of product development we will be looking for different answers to core assumptions, one thing will be certain: our most important task is to gather as much actionable knowledge as possible, in the shortest time possible.
This is done by developing experiments to validate our hypothesis. There are various ways to test different hypothesis, most often with the help of an experiment.
These experiments should be built with minimal effort (or development time in case of a software). Their sole purpose is to test (validate) our assumptions. Most often, features that are otherwise considered essential to the final product are left out 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 to, only develop an experiment for internal use. If only our inner circle has access to the experiment, we can 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.
This is the Measure phase of the Build-Measure-Learn loop, which followed immediately by the Learn phase.
Based on the feedback and metrics gathered, we should again take a look at our base assumptions. How many have been proved to be true? Are we closer to our product vision? If we are, we should define a new set of assumptions, fine-tune our experiment 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 in order 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 quite simple, because he already has a finished product 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 actually 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 start making these digital gifts and sell it to others.
At this stage, he still wouldn't have to create all the content and build a software to fully automate the process and handle every use case. 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 how he could improve the product, which he could integrate in the final product. If he would've created all the content beforehand, Archie would not have this option.
Unfortunately, Archie decided to jump in and create the perfect product. I would like to believe this is because Archie had 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!