The future founder of an online booking service is sitting in his sister's nail salon in Almaty, watching the receptionist answer three Instagram DMs at once at half past ten at night. The idea is ready: an app where a client sees free slots at salons nearby and books in two taps, and the salon pays 1,000 ₸ for every new client. A developer friend estimated the first version at four months of work for two people. The numbers are made up.
Four months of development is a bet that the idea is right in every part. Marketing before the product is there to find out where it is wrong before you place that bet, and to pay for it in weeks and tens of thousands of tenge rather than months.
Write down what the idea rests on
Every product idea rests on a few assumptions. If even one is wrong, the product will not take off, however well it is built. The free-slots app has four:
| Assumption | If it does not hold |
|---|---|
| Clients choose where to go by free time | Nobody needs a catalogue of slots: clients go to their own stylist |
| Salons share their free slots and keep them up to date | The app shows stale times, and the client arrives to find the chair taken |
| A salon pays 1,000 ₸ for a new client | The service has no revenue |
| A new client can be acquired with ads for less than 1,000 ₸ | Every booking loses the service money |
What the list does not contain is "people want convenient booking". Anyone will agree with that, and nothing could disprove it. An assumption is useful when you know in advance which observation would disprove it.
Which risk to test first
Test first whatever could kill the idea and is also cheapest to check. Here that is the first row. If clients pick a stylist rather than a time, the other three questions no longer matter. And a week of conversations can answer it.
The second and third rows cost more: you need salons willing to take part, and a few weeks before you can see whether they pay. The fourth needs ads and a page for them to point at.
The classic mistake is to start with whatever is more pleasant to test: the app design, or the name. A good-looking mockup tells you whether people like the interface, not whether clients choose a salon by time.
Each test along the way costs more and gets closer to money. A conversation shows how the person actually chose, a page with a form shows the response to a promise, a signature on terms shows a willingness to commit, and a paid hand-run pilot shows a purchase. You do not have to climb this ladder from the bottom: if the business is already running, some of the answers are in its data. Steve Blank called the practice of testing assumptions about customers before building Customer Development, and Eric Ries later made it part of the lean startup.
What the booking service found
The founder talked to 15 women he knew and asked each about her last visit to a salon: where she went, how she booked, why there. Eleven had messaged their own stylist on WhatsApp or Instagram. Four were looking for a new place: two chose by reviews on 2GIS, one by photos of the work, and one by the nearest free slot.
One in fifteen is weak support for the first row of the table. But fifteen of the founder's acquaintances are not a market either: they move in one circle. The conversations did not settle the question, they narrowed it: a catalogue of slots might help people looking for a new place, but there were four of them, and only one chose by time.
With the owners and receptionists of eight salons the conversation went somewhere else. Six of them complained first not about a shortage of new clients but about their regulars, who message late in the evening and, if nobody answers, book somewhere else by morning. The founder wrote that down as a separate line. He had not asked about it, and no such hypothesis was in his table.
Then he tested the response to the promise. He spent 40,000 ₸ on Instagram ads for a page that said "Free slots at salons near you. Launching soon: leave your number and we will send you the link first", and collected 260 numbers on the waiting list. That is interest in a promise, in one channel. How many of those people will book through the app and turn up, the page does not say.
He signed up salons in person. He walked into 30 salons in two districts, 12 wanted to try, and 10 signed the pilot terms: four weeks, 1,000 ₸ for every new client who turned up, invoiced at the end. A signature on terms is a commitment, but not a payment yet: nobody had paid anything.
Decide in advance what you will do with the result
Before the pilot the founder wrote down three thresholds: how many of the ten salons must pay the invoice, how many new clients must turn up, and how much each may cost in ads. He also decided to log the hours of manual work every day. A threshold written down in advance stops you from calling any result a success afterwards.
He also made a note about the channel. He found the first ten salons by walking in, but the next hundreds would have to come from ads. How easily the first ten signed up says nothing about what a salon will cost at scale.
Four weeks later the hand-run pilot passed the payment threshold and missed the other two: fewer new clients turned up than needed, and each cost three times more in ads than she brought in. It also showed that salons needed something quite different from what the founder was offering.
Do not pass a promise off as a product
While there is no product, a page can only collect a promise, and people should see that before they leave a number. "Launching soon, we will send you the link" is fine. A "Book now" button that leads nowhere misleads people and gives you a number you cannot rely on: you cannot tell which of the people who clicked would really have booked.
The same goes for money. If the pilot is paid, the terms are written before it starts: what is included, what it costs, when the invoice comes and what happens if no new clients arrive. In your data, signed terms, a prepayment, a refund and a paid invoice are separate events. Merge them into one "payments" line and you lose the difference between those who promised and those who paid.
Exercise: an assumptions table for your own idea
Take a product idea: yours, a client's, or a friend's who is planning to "build an app".
One last question, the kind you get on your very first project. A week after visiting the salons, the founder has 260 numbers on the waiting list and 10 salons with signed terms. His partner writes in the investor deck: "260 users and 10 paying customers". What is wrong with that?
There are no users yet: 260 people left a number in response to a promise and have never booked anything. There are no paying customers either: ten salons agreed to pay for new clients, but they will only be invoiced at the end of the pilot, and nobody knows yet how many will pay. The deck could say: "260 numbers on the waiting list, 10 salons signed the terms of a paid pilot, payment after four weeks". Each number is named after what actually happened. And product-market fit is still two steps away: a payment, and then a repeat payment.
Video: the link to Product-Market Fit
Every test in this lesson leads to the same place: a product people pay for again. That is what the video is about.