WhoBuilt

A Conversation

Sep 1, 2018· 1 h 3 min· 258K views·Watch on YouTube

Speakers

Paul Graham, Y Combinator co-founder, talks with Y Combinator president Geoff Ralston at Startup School about building startups, choosing co-founders, and learning from users.

How Viaweb began

Graham says Viaweb grew from a practical desire to avoid writing software for Windows. He and his co-founders built a browser-based store builder, even though the idea seemed unusual and the first version was clunky. He says promising ideas can seem implausible at first, and their outcomes are hard to predict.

Choosing co-founders and learning by doing

Graham describes choosing Robert Morris because they already worked well together, then recruiting Trevor Blackwell on Morris’s recommendation. He advises using trusted people to find capable collaborators, while assessing trustworthiness separately. Viaweb also served early customers manually, which taught the founders what to improve in their software.

Do things that don’t scale

Graham says founders should handle early work by hand, including finding customers and talking with them, instead of building elaborate systems before they understand the problem. Viaweb’s founders could not persuade stores to use their software, so they used it to build stores for customers themselves. He says steady growth from a small customer base can compound, while those early interactions help shape the product.

What helps startups succeed

Graham says poor execution is a more common cause of failure than competition, citing one company out of 1,900 as having been killed by a competitor. He emphasizes a strong founding team that can withstand stress, and says determination matters more than exceptional intelligence. Ralston adds that founders need to navigate as their initial ideas improve, often by listening closely to users.

Launch, learn, and stay close to users

Graham warns founders against building from private assumptions, delaying launch out of embarrassment, or avoiding sales and user feedback. He says a product is ready to launch when at least one person can use it to do something they could not do before. In the Q&A, he recommends asking users about their lives and frustrations to uncover the problem behind their requests.

Takeaways

  • Use early customer work to learn what product to build before automating it.
  • Launch once someone can get real value from the product, even if it is unfinished.
  • Talk with users about their problems and routines, not just their requested features.
  • Choose co-founders who can work through stress together, and assess trustworthiness directly.
  • Keep improving execution and customer understanding instead of fixating on competitors.

Mentioned in this talk

Search inside this talk

What was claimed 12

Related talks