Founder case study
Airbnb: Learn from a narrow group of early users
Use Airbnb's documented early history to plan direct customer learning, with a reusable observation sheet and clear limits.
When a new product attracts little activity, the problem is not always a missing feature. People may not understand the offer, trust the information or complete a necessary step. Direct observation can help distinguish those possibilities. Airbnb's early history provides a concrete case, but the practical task is to design a learning process for your own users.
What the original sources say
Airbnb's company timeline dates its first guests to October 2007. It records two bookings at its March 2008 SXSW launch and 80 bookings around the August 2008 Democratic National Convention. The business adopted the Airbnb name in March 2009. These company-reported milestones describe an uneven early sequence, rather than an instant mass-market launch.
In his 2013 essay “Do Things that Don't Scale”, Y Combinator co-founder Paul Graham recalls Airbnb's founders going door to door in New York, recruiting users and helping existing hosts improve their listings. He also describes the founders taking photos of early hosts' apartments. This first-hand account supports the use of direct customer contact; we do not use it to claim a particular increase in bookings.
Our analysis: investigate one bottleneck at a time
A marketplace has at least two groups to understand. Improving the experience for one group may not solve the other group's problem. The same distinction appears in smaller projects: the person using a tool may differ from the person choosing or paying for it.
Start with a narrow situation and a complete task. Instead of asking whether someone likes your website, ask them to use it to reach a specific outcome. Watch where information is missing, where expectations differ and where the person stops. You are collecting clues, not asking the participant to design the product.
A reusable customer observation sheet
Use one sheet per session. Write factual observations first and your explanation afterward. Obtain permission before recording or capturing personal information; anonymous notes are often sufficient for an early usability session.
| Field | What to record |
|---|---|
| Participant and situation | [Relevant role and recent problem, without unnecessary identifiers] |
| Task | [The outcome they are trying to reach] |
| Current alternative | [What they would use without your product] |
| Observed friction | [A specific hesitation, error, unanswered question or exit] |
| Manual assistance | [What you helped them do and how long it took] |
| Follow-up behavior | [What they actually did next] |
| Next hypothesis | [One proposed explanation and a way to check it] |
Turn observations into a small change
- Find a repeated problem. Compare several sessions. One person's preference is a clue, not a general rule.
- Separate explanation from evidence. “The participant reopened the pricing page three times” is an observation. “The product is too expensive” is an interpretation requiring more evidence.
- Try the smallest relevant improvement. Clearer examples, better information or a simpler step may be enough to test the hypothesis.
- Observe again. Check whether people complete the task with less help. Record both improvements and new problems.
Limits of a hands-on approach
Manual help can hide weaknesses in the ordinary experience. Keep track of what succeeds only because you are present. Direct interviews also favor people willing to speak with you, so include quieter or unsuccessful users when possible. A successful session does not establish retention, profitability or market demand.
Sources and editorial note
Historical sources: Airbnb's company timeline and Paul Graham's first-hand essay. The observation sheet and interpretation are FounderType's analysis. Unverified investor rejection totals, attributed motivational quotations and precise growth multipliers have been omitted.
Apply the observation method to a different product
The following exercise is a fictional planning example, not an additional claim about Airbnb. Imagine a two-sided service that helps people find a short-term workspace. Before building filters, choose one recent search and observe the whole sequence: what triggered the search, what options the person considered, what information they needed to compare them, what made them trust or reject an option, and what happened after contact.
Keep the two sides separate. A workspace provider may want fewer empty hours; a person searching may need predictable access, location or equipment. Those goals may overlap, but one interview cannot show that both groups will join the same service. Record who supplies the listing, who verifies the details, who handles payment and what happens if the listing is wrong. Each promise creates work and risk for the operator.
Use an observation plan, not a founder-led demo
- Define a task. Ask the participant to find and evaluate an option they would genuinely consider, using their usual method first.
- Stay quiet. Do not fill pauses or point out the feature you expect them to notice. Mark where they hesitate or ask for information.
- Ask for the reason after the action. “What made you open that listing?” is more useful after you have seen what they did than before.
- Record what required help. If you explained an unfamiliar term or supplied missing information, note it. That assistance is part of the test result.
- Follow the outcome. Ask whether they contacted anyone, completed a booking or chose another option. If no action followed, do not upgrade interest into a transaction.
Separate the service promise from the interface
A confusing page may be a presentation problem, but a failed search may also reflect thin supply, inaccurate details, a trust gap or a poor match between what each side wants. These explanations call for different experiments. Before building a new interface feature, test whether a manually prepared shortlist, a clearer listing, or a direct introduction helps someone finish the task. State what is manual and do not imply guarantees or verification you do not provide.
Use a simple review record: event observed, person's own explanation, your interpretation, alternative explanation, next evidence needed. Keep private details out of published notes. If you later repeat the exercise with more people, write down how you recruited them and which groups are missing; a convenience sample is not representative market research.
Decision rule
At the end of a limited observation period, decide whether to continue learning about the same task, narrow the audience, test another bottleneck or stop the current approach. Pick the review rule before collecting observations. The useful result is a traceable reason for your next action, not a claim that a famous company's history guarantees your outcome.