The story of Airbnb’s early host visits is often reduced to a slogan: do things that do not scale. That slogan leaves out the question a founder needs to answer before spending time on manual work.
Which uncertainty will this intervention resolve, and what will the company be able to do differently afterward?
This case examines the limited historical record in Paul Graham’s account, then develops an original operating method for applying the lesson. It is not a claim that Foundshore participated, that the intervention alone caused Airbnb’s success, or that a similar action will produce the same outcome elsewhere.
The documented record
In his July 2013 essay, Graham describes Airbnb’s founders visiting New York during their YC period, recruiting hosts and helping improve listings. He also refers to the founders photographing early hosts’ apartments. Graham was an involved advisor, and his account presents direct user engagement as important to the company’s early progress. 1
That is the evidence used here. The essay is not a randomized comparison or a complete cost-and-revenue analysis of the visits. It does not support calculating a general return on founder visits, attributing Airbnb’s entire later growth to photography, or turning a historical anecdote into a universal operating rule.
The narrower, useful observation is that the founders worked directly on the conditions under which a customer experienced the product.
What makes the intervention interesting
Manual work can serve at least three purposes. It can recruit a user, improve the user’s immediate experience, and reveal why the experience was difficult. Those purposes overlap but should not be confused.
Imagine a marketplace where supply exists but buyers cannot judge it confidently. Adding more listings might increase quantity without improving the decision. Working with a small number of suppliers could expose missing information, presentation problems or process friction.
That is an analytical example, not an additional fact about Airbnb. It shows why the location of the intervention matters. The founders are not simply adding labor wherever it is convenient; they are inspecting a part of the experience that might influence use.
Choose manual work by the learning it can produce
For a current startup, begin with the task that is failing. “Customers are not activating” is a symptom. Identify what a particular person is trying to accomplish and where the process stops.
Then choose an intervention small enough to observe. It might be helping a user configure an integration, preparing a permitted sample, explaining an unfamiliar output or watching someone attempt the workflow. You should be able to state what you expect to learn and what would contradict the expectation.
Do not choose the intervention solely because it will impress the customer. Delight can be valuable, but an expensive gesture without a connection to the problem may teach little about the product.
Preserve the boundary between service and product
Suppose a fictional founder helps a customer produce a report. The customer receives a useful result, but the founder manually corrected the data and supplied the interpretation. That is an assisted outcome.
The next question is which parts the product can eventually support, which remain expert work, and what the customer is actually paying for. It is acceptable to learn that the business is partly a service. It is misleading to present the assisted result as fully automated performance.
Keep a work log that distinguishes customer action, product behavior and founder intervention. Record failures and corrections, not only the final artifact. This prevents the polished result from erasing the work required to obtain it.
An intervention record for a modern team
Field | What to record |
|---|---|
Observed difficulty | The specific task or decision that is not working |
Proposed intervention | What the founder will do and why it may help |
Customer permission | Agreed access, data use and scope |
Before-and-after evidence | Comparable observations, with limits |
Manual effort | Preparation, delivery, repairs and follow-through |
Learning | Which assumption changed and which remain unresolved |
Repeatability question | What must change for the next customer to succeed with less help? |
This is Foundshore’s proposed analysis tool, not a reconstruction of Airbnb’s internal process. It is designed to make the transferable lesson explicit without pretending the historical company used this exact worksheet.
Test what happens when assistance is reduced
A successful assisted result creates a next experiment. Can another suitable user complete more of the task with clearer guidance, a product change or a simpler setup? Does the work remain valuable when the founder is not providing immediate interpretation?
Do not remove support recklessly, particularly where failures have serious consequences. Instead, design the reduction within appropriate safety, privacy and customer-service conditions.
The aim is to distinguish a product improvement from a founder temporarily filling every gap. Sometimes the correct outcome is a better-supported service model rather than a fully self-serve product. The experiment should inform the choice, not force a predetermined answer.
Account for the customer you selected
Early users willing to accept close founder involvement may differ from later buyers. They may be more tolerant, more interested in the problem or more willing to spend time helping. That possibility should remain part of the interpretation.
Record how the participant was found and why they agreed. Do not generalize one person’s enthusiasm to an entire segment. Look for a repeated pattern across appropriately varied cases before making stronger claims.
Likewise, note what the intervention did not test. A successful setup does not establish retention, purchasing authority or an economically viable delivery cost. Those are subsequent questions.
Why the story should not become a license for endless custom work
“Do things that do not scale” can be used to justify almost any founder activity after the fact. A more demanding standard asks whether the work has a bounded purpose, an observable result and a decision it will change.
Set an effort limit and review it. If every new customer requires a different project, examine whether the business is serving a common task or a series of unrelated requests. Both may generate revenue, but they should not be evaluated as the same product strategy.
Manual work becomes an asset when it improves understanding, creates a repeatable approach or clarifies what should remain human. It becomes a distraction when it expands without improving those decisions.
The transferable lesson
The Airbnb account is valuable because it directs attention toward the lived customer experience, not just the product interface. Its limits are equally important: it is a historical account of one company, told by an involved observer.
For your company, choose a specific friction, help responsibly, preserve the evidence and test what you can repeat. A mentor, founder community or specialist can help inspect the result, but the team still owns the interpretation.
The useful inheritance is not a famous tactic to copy. It is a disciplined willingness to work close enough to customers that the next product decision is informed by what actually happened.
Sources and research scope
[1] Do Things that Don't Scale — Paul Graham. First-person historical essay. Published 2013-07. Reviewed 2026-10-04. Airbnb account from an involved advisor. No controlled causal result or present-day performance inference.
