YC Root AccessLecture 8 - How to Get Started, Doing Things that Don't Scale, Press
CHAPTERS
- 0:00 – 1:31
Stanley Tang’s origin story: building DoorDash while still a Stanford student
Stanley Tang opens with a personal snapshot of juggling college life and startup life, highlighting how early DoorDash was built alongside coursework and everyday responsibilities. He frames the talk as a practical story of how the company started and what mattered most in the earliest days.
- •DoorDash described as an on-demand delivery network for local cities
- •The “speeding ticket + tax forms + Series A paper” moment illustrates startup chaos
- •Context: founded while still at Stanford (class of 2014)
- •Sets up the talk as a lessons-learned narrative about starting from scratch
- 1:31 – 2:31
Discovering the problem: delivery pain for local merchants (macaron shop insight)
The initial spark comes from interviewing a Palo Alto macaron shop owner who reveals she has to turn down delivery orders due to lack of drivers. This real-world merchant pain becomes the seed for exploring delivery as a broader small-business infrastructure gap.
- •Interviewing small business owners to understand their operational problems
- •Merchant shows a thick book of delivery requests she can’t fulfill
- •Delivery is framed as missing infrastructure, not just a nice-to-have feature
- •Founders become curious: why hasn’t an ‘obvious’ problem been solved well?
- 2:31 – 3:32
Validating demand: 150–200 merchant conversations and a key hypothesis
After the macaron shop meeting, the team talks to hundreds of local businesses and repeatedly hears delivery is a major unmet need. They consider the possibility that previous attempts failed due to insufficient consumer demand, prompting an experiment-focused approach.
- •Broad customer discovery across many local businesses
- •Consistent signal: delivery is a large, recurring pain point
- •Hypothesis: maybe lack of consumer demand explains past failures
- •Decision: run a test before building real infrastructure
- 3:32 – 4:04
The scrappy MVP: paloaltodelivery.com with PDF menus and a personal phone number
To test demand quickly, they launch a bare-bones landing page in an afternoon: PDF menus, a list of restaurants, and a phone number that routes to their own cell phones. The goal is simple: see whether anyone actually tries to order.
- •Built a minimal landing page instead of a full product
- •Used existing PDF menus found online
- •Order intake via personal cell phone number
- •Objective: measure inbound calls as proof of demand
- 4:04 – 6:15
First orders and early traction: delivering food themselves to learn the workflow
A phone call arrives immediately—forcing the founders to fulfill the order by driving to pick up and deliver food themselves. Orders grow day by day, and the team realizes users will tolerate a rough experience if the need is strong.
- •First real order comes in right after launch
- •Founders personally pick up and deliver the order
- •Order volume grows quickly (2 → 5 → 7 → 10+)
- •Key signal: strong need shows up as willingness to endure a clunky UX
- 6:15 – 8:13
Launch fast and “do things that don’t scale”: the early DoorDash operating system
Stanley emphasizes that none of the later “serious” infrastructure mattered at the beginning; speed and learning did. The founders handled delivery, support, marketing, and dispatch manually, stitching together tools like Square, Google Docs, and Find My Friends.
- •Launched in under an hour; avoided overbuilding upfront
- •Founders acted as drivers, dispatch, and customer support
- •Hacked together tooling: Square, Google Docs, Find My Friends
- •Early growth sometimes breaks systems (Square flagged them for ‘money laundering’)
- 8:13 – 9:14
Why manual work is strategic: becoming experts through hands-on operations
Doing unscalable tasks wasn’t just survival—it was a way to build deep understanding of delivery mechanics and customer pain. Personalized outreach and manual dispatching produced rapid feedback loops and directly informed what to automate later.
- •Driving teaches the full delivery workflow and where bottlenecks are
- •Manual dispatching helps define future assignment algorithms
- •Personalized emails to every new customer generate insights and loyalty
- •Direct customer support provides real-time product feedback
- 9:14 – 10:43
The “ice cream” moment and the transition to scaling systems
A spike in demand forces the founders to choose operations over leisure, becoming a symbolic motivator for scaling. Stanley notes that sophisticated automation only becomes important after demand is proven and product-market fit is emerging.
- •Demand spikes create constant operational tradeoffs
- •Scaling becomes a way to reclaim time and reliability
- •After traction: build automated dispatch and supply-demand matching
- •Principle: validate first, then scale the tech
- 10:43 – 16:15
Stanley’s three takeaways + audience Q&A on early growth, timing, and vision
Stanley closes with three core lessons—treat ideas as experiments, launch fast, and embrace non-scalable tactics early. In Q&A, he addresses how customers discovered them, why delivery became viable, competitive differentiation, incorporation timing, and the longer-term vision beyond food.
- •Three lessons: test hypotheses, launch fast, do things that don’t scale
- •Early growth largely word-of-mouth; minimal marketing
- •Key enabler in hindsight: mobile + on-demand contractor model
- •Incorporated when entering YC; long-term focus on helping all local merchants
- 16:15 – 17:45
Walker Williams’ framework: ‘don’t scale’ across acquisition, champions, and PMF
Walker defines ‘things that don’t scale’ as fundamentally unsustainable but crucial early tactics. He organizes the talk into three areas: getting first users, turning them into champions, and iterating quickly to find product-market fit.
- •Defines ‘don’t scale’ as strategies that break with time or volume
- •Three focus areas: first users, champions, product/market fit
- •No ‘silver bullet’ acquisition tactic for most startups
- •Early traction typically requires intense founder effort
- 17:45 – 20:47
Finding the first users: founder-led, unglamorous, high-effort acquisition
Walker describes early Teespring as a business that looked terrible from the outside—free design work, long revisions, and minimal revenue per campaign. He argues founders must personally push the boulder uphill without obsessing over short-term ROI, while generally avoiding giving the product away for free.
- •Early Teespring required heavy manual service to sell small orders
- •Founders are naturally bad at selling at first (no proof, no clarity)
- •Acquisition tactics: relentless emails, calls, and network leverage
- •Caution: avoid free-as-a-strategy; paid demand signals true value
- 20:47 – 25:49
Creating champions: obsessive customer conversations and making problems right
Walker emphasizes that great growth depends on user ‘champions’ who advocate for the product, and the fastest way to create them is memorable service and constant user dialogue. He outlines doing customer service yourself, proactively contacting churned customers, and monitoring social channels—then over-correcting when something goes wrong.
- •Champions drive word-of-mouth; delight creates advocacy
- •Do customer service yourself to learn and improve faster
- •Reach out to churned users to recover and diagnose product gaps
- •Fix issues aggressively; one detractor can undo many champions
- 25:49 – 32:59
Iterating to product-market fit: optimize for speed, not perfect architecture
To reach PMF faster, Walker advises sacrificing clean scalability in favor of rapid learning and shipping. He shares Teespring’s example of duplicating the codebase to quickly serve enterprise customers, and the rule of only building for the next order of magnitude.
- •Early product is rarely the one that scales; iterate fast
- •Speed beats elegant code early; accept technical debt temporarily
- •Tactical hack: duplicate systems to ship in days, then integrate learnings
- •Build for 10→100→1,000 rather than 1,000,000 prematurely
- 32:59 – 44:38
Justin Kan on press: set goals, craft real stories, and run the PR ‘sales funnel’
Justin demystifies press as a non-meritocratic, goal-driven process rather than something that ‘just happens.’ He explains what makes a story, how to pitch reporters through warm intros, and why effective PR resembles a funnel requiring volume, preparation, and follow-through.
- •Press is not automatic; define the audience and business goal first
- •Match press targets to objectives (investors vs local customers vs industry)
- •Common story types: launches, fundraising, milestones, stunts, hiring, op-eds
- •Mechanics: warm intro → lead time → meeting/call → structured pitch → follow-up
- 44:38 – 52:13
PR firms, sustainability limits, and the Twitch Plays Pokémon case study
Justin warns that PR agencies are expensive and can’t invent what’s interesting about your company; founders should learn the process themselves first. He explains that press is a short-term bootstrap, then illustrates how Twitch amplified (but didn’t originate) the Twitch Plays Pokémon story by being available and extending the narrative with follow-ups.
- •PR firms mainly add contacts/logistics; founders must supply the ‘interesting’ angle
- •High cost ($5k–$20k/month) often unjustified early
- •Press is a vanity metric unless tied to customers, recruiting, or positioning
- •Twitch Plays Pokémon: community-created; company helped provide context and follow-up angles
