Over the past few years, I have built side projects, read extensively about startups, and followed the journeys of founders I admire. This is a distillation of the lessons that come up again and again - the playbook I wish someone had handed me before I started.

Idea Validation

The most common mistake is building something nobody wants. Validation comes before code.

Talk to people first

Before writing a single line of code, talk to at least 10-20 potential users. But do it right. Most people ask leading questions ("Would you use an app that does X?") and get misleading yes answers because people are polite.

Instead, follow the approach from The Mom Test:

  • Ask about their life, not your idea. "Tell me about the last time you tried to do X."
  • Ask about specifics in the past, not hypotheticals about the future. "How do you handle this problem today?" not "Would you use a tool that..."
  • Ask about money. "How much do you spend on solving this currently?" If the answer is zero, they probably will not pay you either.

Look for strong signals

Good validation signals include people who actively search for a solution, people who have built hacky workarounds (spreadsheets, manual processes), and people who are already paying for an inferior alternative. Bad signals include people who say "that sounds cool" but have never tried to solve the problem themselves.

Building the MVP

The MVP (Minimum Viable Product) is the smallest thing you can build to test your core assumption. Most developers overbuild their MVPs because building is comfortable and shipping is scary.

Rules for the MVP

  • One core feature. What is the single thing your product must do? Build that and nothing else. Dropbox's MVP was a video showing the product concept. Buffer's MVP was a landing page with a pricing table.
  • Time-box it. Set a hard deadline of 2-4 weeks. If you cannot build a testable version in that time, your scope is too large. Cut features until it fits.
  • It should be embarrassing. Reid Hoffman's famous quote: "If you're not embarrassed by the first version of your product, you launched too late." The MVP should make you uncomfortable. That discomfort means you shipped before over-polishing.
  • Manual before automated. If your product needs a recommendation engine, you can manually curate recommendations for the first 100 users. If it needs an onboarding flow, personally onboard each user via email. Automation comes later.

Getting First Users

Building the product is the easy part. Getting the first 100 users is where most startups die.

Do things that do not scale

Paul Graham's advice is timeless. Your first users will not come from a viral loop or SEO. They come from direct, personal outreach:

  • Personal network. Tell everyone you know. Not a mass announcement - individual conversations where you explain the problem and ask if they know anyone who has it.
  • Communities. Find where your target users hang out (Slack groups, forums, subreddits, Twitter communities) and participate genuinely before promoting anything.
  • Cold outreach. Identify 100 people who fit your target user profile and email them personally. Not a template - a real, personalized message explaining why you think they specifically would benefit.
  • Content marketing. Write about the problem your product solves. This attracts people who are actively searching for a solution. It is slow but compounds over time.

Retention before growth

Getting users to sign up is useless if they leave after one session. Focus on retention first. Are your first 20 users coming back? Are they using the product regularly? If not, fix the product before spending energy on acquisition. A leaky bucket does not need more water - it needs fewer holes.

Metrics That Matter

Most startups track vanity metrics (total signups, page views, social media followers) because the numbers go up and feel good. Focus on metrics that reflect real value:

  • Retention rate - What percentage of users are still active after 1 week? 1 month? This is the most important metric for any early-stage product.
  • Net Promoter Score (NPS) - Would users recommend your product to a friend? Ask them directly with a simple 1-10 survey.
  • Revenue (or willingness to pay) - If you charge, are people paying? If you do not charge yet, ask users if they would pay and how much. Money is the strongest signal of value.
  • Engagement depth - Not just whether users come back, but what they do. Are they using the core feature or just poking around?

Pick 2-3 metrics and review them weekly. Ignore everything else until those metrics are healthy.

When to Pivot

A pivot is not a failure. It is a strategic adjustment based on what you have learned. But knowing when to pivot versus when to persevere is one of the hardest judgment calls in startups.

Signs it is time to pivot:

  • No retention. Users sign up and never come back, despite your best efforts to improve the product and onboarding.
  • You cannot give it away. Even when the product is free, people are not interested. The problem is not pricing - it is that the value proposition does not resonate.
  • Your best users are using it for something unexpected. This is actually the most positive reason to pivot. If users consistently use your product in a way you did not intend, follow them. They are showing you where the real value is.
  • The market has spoken. You have talked to 100+ potential customers and the feedback is consistently lukewarm. Not "I hate it" (that can mean you just need to iterate) but "it's fine, I guess" (that means they do not need it).

Signs you should persevere:

  • A small number of users love the product intensely, even if total numbers are low
  • Retention is improving with each iteration
  • Users give specific, actionable feedback (they care enough to help you improve)

The Meta-Lesson

The most important thing I have learned is that startups are a search process, not an execution process. You are searching for a product that solves a real problem for a specific group of people who will pay for it. Every experiment, every conversation, and every failed feature narrows the search. Speed of iteration - how quickly you can test and learn - is the primary competitive advantage of a small team.