16 lessons from Paul Graham on starting a startup

Paul Graham runs Ycombinator, a Silicon Valley based startup incubator. He previously started and sold Viaweb to Yahoo.

Paul’s essays have had a tremendous impact on how I think about projects, business, and life.

Below are just a few of my own reflections as I’ve read through a few of the posts on his website.

Perhaps these lessons might help someone on their own startup journey.

Lessons from Paul Graham’s Essays

  1. Build something people want, will use, and pay for.
    • Create an easy way for people to pay you for it.
    • Create something that “a small number of people want a large amount”.
    • The initial customer should initially be a single human, not an enterprise. While it may be an enterprise in the future, the first delivery channel should be via solving a unique and specific problem for someone.
  2. Build something where you are the first user. Product or service should solve a real, specific problem that you have.
    • In order to do this, keep a list of stuff that annoys you, stuff that irritates you… Use it as fuel for the company.
    • As the founder, you should use the product all the time.
    • Simplicity: it should be simple, not complicated. Do the simple things really well.
      • The problem should be easy for the founder to solve.
  3. Pick a project you can work on every day. You have to be consistent and it has to be a habit.
    • Consistency is the greatest predictor of success.
    • Execution wins 99% of the time, and persistence wins all of the time. 
    • Many days you won’t be able to spend much time. However, daily practice will create a positive habit. On rare days (Friday afternoon perhaps) when you find a chunk of extra time, sprint.
      • You will be able to make headway and really push the ball forward because the project is fresh in mind. 
  4. Do things that don’t scale.
    • An unscalable process can become a service-based business, which can later be productized. Service co’s are easier to brute-force into existence.
    • The activation energy of a service co. is much much lower than a product co. 
    • Use the tool on behalf of the user if necessary.
      • Remember, users have other important stuff to think about besides your co.
    • Recruit users manually.
      • This can be done via a niche community that you are in some way a part of. If you’re not part of any special-interest groups, find one on reddit, twitter, or facebook groups from which to create a spark of interest. 
  5. Build a minimum-viable-product ASAP, and show it to users. Hack a product together that is quick and simple.
    • Leverage ChatGPT to get to MVP. This new LLM technology is a massive catalyst to build / prototype fast.
    • Get out of the building and talk to users immediately.
      • When reaching out to people, create an environment of needing their expertise and feedback.
      • There are a million and one prospects. Just call someone. Worst case they hang up on you and you never talk to them again.
    • Think of your initial version not as a product, but as a trick for getting users to start talking to you after they initial icebreaker. The MVP is just a way to have those 2nd level conversations with users.
    • Use a medium that lets you work fast and doesn’t require much commitment up front… such as spreadsheets, notion, performing a service, typeform, stripe, email, airtable, google sheets, convert kit, etc. Lookup “email first startups” for more ideas
  6. Build a “core component” with a slight bit of novelty that brings users value.
    • Be careful if you charge for the core component… you may charge for add ons.
  7. Iterate, test, learn, improve.
    • Use the scientific method to formulate hypotheses about the “killer feature” in the product.
    • Conversations with users are your way of testing the hypothesis.
  8. Think of your project as a way to learn and not just as a way to make something.
    • Even if the project itself is a failure, you’ll still be better from it.
    • You need at least one reference-able customer and sale. This will help with future projects and customer acquisition.
  9. Consider the build in public movement
    • Could even write about “following the PG Approach”… basically just following Paul Graham’s advice that he shared on building a startup.
    • Refer to the “micro-saas” movement on making modest but adequate stream of money. 
  10. Pick a name that you buy the .com of.

Anti-advice: follies to avoid

  1. Avoid risk & ruin.
  2. Avoid anything that feels scammy or incurs undue financial, regulatory, or compliance risk.
  3. Avoid creating a company that relies on yourself or another’s “personal brand”.
  4. Don’t build something that is bad for people.
  5. Don’t try to build a marketplace, and definitely don’t try to build a 2-sided marketplace.
  6. Don’t worry about competition. Competition is never the reason that a startup fails — lack of customers is.
    • Worrying about competition is like going swimming in the ocean any worrying about sharks. The real dangers are drowning, or getting in a car crash on your drive to the beach.

Comments

3 responses to “16 lessons from Paul Graham on starting a startup”

  1. […] about what other people want. Paul Graham echos this sentiment for startup companies: “Build something people […]

  2. […] understand how important “getting out of the building” is when building something. Talk to users and experts and bounce ideas off of other […]

  3. […] its a bit silly but it is a stepping stone towards building something people will pay for, as Paul Graham […]

Leave a Reply

Your email address will not be published. Required fields are marked *