PG Canon · Chapter 02
Do Things That Don't Scale
Nearly every successful startup starts with manual, unscalable, even embarrassing effort. Recruit users by hand, overdeliver, and treat the inefficiency as strategy — not a phase to rush past.
After this lesson
- Give up the fantasy of a purely automatic launch
- Recruit and onboard your first users manually
- Turn manual delivery into learning, not just labor
Almost all successful startups do this at first
A large fraction of successful startups do things at the start that don't scale. Recruiting users manually and providing embarrassingly overqualified customer service are the two most common examples — and both feel wrong to founders who signed up to be engineers, not door-to-door salespeople. The discomfort is the point: if it felt scalable and dignified, everyone would already be doing it, and it wouldn't be a source of advantage.
Case
Case: the scheduling tool that didn't schedule anything
Two founders building a shift-scheduling product for retail managers spent their first two months writing no scheduling logic at all. Instead, they personally built the actual weekly schedules for six pilot stores by hand, over text message and a shared spreadsheet, copying the manager's constraints and preferences exactly as if the software already existed.
Takeaway: The fake-it-by-hand version taught them which constraints mattered in practice — shift-swap requests came in three different unstructured ways nobody had mentioned in an interview — before a single line of that logic got built. Manual delivery is a research method, not just a stopgap for acquisition; it front-loads the mistakes you'd otherwise make in code.
Manual recruiting playbook
- Go where your users already are — physically or in the specific Slack, subreddit, or forum they actually use, not a generic ad channel
- Recruit users one at a time; a hundred passionate users beats ten thousand indifferent signups
- Fake the automated version of the product by hand before you build any of the automation underneath it
- Treat every interaction as a chance to learn what to build next, not just to close one more user
Delight, don't just satisfy
Being 'too good' to early users feels inefficient — a handwritten note, a same-day fix shipped for one customer, a founder personally onboarding someone on a video call at 11pm. But at the start you want to overdeliver so dramatically that the first users become evangelists who tell other people unprompted. You can dial efficiency up later; you cannot manufacture word of mouth retroactively once the moment for a first impression has passed.
Turning unscalable work into a system
- Do the ugly, fully manual version first, with your own hands, for real customers
- Notice which parts are painful because they're genuinely hard, versus painful only because no one has automated them yet
- Automate the second kind; keep doing the first kind personally as long as it keeps teaching you something
- Know when to stop: once manual work stops producing new information, it's just busywork wearing a founder costume
Should you automate this yet?
A part of onboarding still requires you to do it by hand.
Case
Case: the founder as the entire support team
A solo technical founder answers every support ticket personally through year one — more than two hundred a week by the end — long after the company can afford to hire someone else to do it, and long after his cofounders start pushing back on the time it eats.
Takeaway: Direct contact with unhappy and happy users is the highest-bandwidth product research available anywhere in the company. Outsourcing it too early is a common way founders go blind to their own product — the fix isn't never delegating support, it's delegating only after you've personally absorbed enough of the pattern to know what a good ticket-handler should catch.
Read the original
Do Things that Don't ScalePull this one idea: manual recruiting and hand-delivered service aren't a phase to survive, they're how you learn what to build.
This chapter is a working summary. When the idea matters, read the source once — then come back and do the practice.
Read the original
Superlinear ReturnsPull this one idea: performance pays off superlinearly, not proportionally — which is why overdelivering to a handful of early users can generate outsized word of mouth instead of a merely fair share of it.
This chapter is a working summary. When the idea matters, read the source once — then come back and do the practice.