You have an idea for a new product and you think it’s really, really good. You’re tempted to dive straight into building it. “People are going to LOVE this!”

This is a trap.

Many founders learn this the hard way by spending weeks, months (maybe even years?!) building something people don’t want because they never stopped to do something very simple from the outset.

Validate their idea.

We know a bit about this. PostHog’s co-founders, James and Tim, pivoted five times before settling on PostHog. James admits “we had a lot of terrible ideas” and validation was there to tell them just how bad they were.

I wouldn’t be writing this newsletter without the success of the validation process they did back in the day, so I’m sharing their playbook here.

It has three simple steps, but you’re going to need something first…

A list of problems to solve

One idea is good; many are better.

Your ideas should be in the form of problems: jobs-to-be-done by your product for a specific customer.

Often, the specific customer is you and the problem is one you’ve had:

• Mercury’s founder “was just really frustrated” that, as an entrepreneur, “banking was this kind of static thing that I was forced to use and rely on.”

• Deel’s founders had faced repeated problems hiring internationally in past startups, such as a lack of legal legitimacy and high costs.

• ElevenLabs’ founders thought movies dubbed into their native Polish “were flat and monotonous” and thought they could do better using AI.

James started with a three-page Google Doc of ideas based on problems he encountered in his career up until then. More were added as he worked through validating them with Tim.

Many of their ideas were bad and never got past the first step of validation – seriously guys, a “1:1 tool for managers with predictive analytics?”

Others got further before being invalidated. Only PostHog, AKA “open-source product analytics built for engineers,” made it to the end. Ironically, they landed on this idea through the process of validating their other ideas.

Every time they built something and tried to deploy analytics, they were frustrated by hard-to-implement tools not designed for builders. They literally stumbled on the right idea by failing multiple times.

So, once you have some problems like these to solve (or at least one), you’re ready for…

Step 1: Validate your problem is real

You do this by talking to potential users.

No one else is going to do this for you and not working hard enough is a common failure mode here.

James got at least two meetings a day, five days a week while doing other random tasks, like building a website. He was constantly asking for intros and doing cold outreach via his network.

Another risk is caring too much too soon.

You don’t need to care about audience, solution, or even that it’s unique yet. If people have a burning problem, these details sort themselves out.

How to get meetings

Many guides to validation focus on analysis, but anyone who’s actually done validation will tell you that getting people to talk to you is the hardest part:

1. Use your network. Find people who want to respond to you, such as friends, former teammates, followers, members of communities you’re a part of.

2. Ask for intros. Sometimes the people you know can introduce you to other relevant people. Mercury’s founder, Immad Akhund, says “some of the most useful people were four intro chains down.”

3. Be concise. Two to three sentences, not walls of text. Be clear you want feedback on your idea – say it’s an interview. Don’t try to sell to them yet.

4. Be quick. Follow up fast. Startups win on speed, be glued to your messages.

5. Do interviews in-person (if possible). This helps you better understand their context and you can catch more non-verbal cues. Video calls are second best.

What to ask people

1. Validate that they’ve actually had the problem. Focus on their situation and get specific. The clearer the problem, the simpler it’ll be for you to validate.

2. Figure out how they have tried to solve it. What have they done and what are they doing now? If they have a crappy self-built system, there’s probably a good business in providing that thing for them.¹

3. Get into the details. Go beyond “it’s hard.” Listen and get into the details. Open-ended questions can reveal why you’re close but not quite right.

If it’s not a “hair on fire” problem for them, or they’re not excited to talk about it with you, it’s probably time to pivot to a new problem.

If you can see people are desperate for a solution, and you’re excited to work on the problem, then you’re ready to move on to Step 2.

Common failure modes

• Just asking people if they like your idea: Most people will just say “yes” or “it’s interesting” to get you to stop talking to them. This doesn’t equal validation. You need to know if they’ve encountered the problem and tried to solve it.

• Asking the wrong people: Sometimes the problem is right and the audience is wrong. Double check your assumptions here before pivoting to a new idea.

• Telling people what they need: If you are reading advice on how to validate your product, you probably don’t have a product or design sense to “just make it work” like Steve Jobs. Validation fills in for this.

• Doing big business validation: You don’t need to run focus groups, start product managing, build a pitch deck, or spend weeks on competitor research. Validating your problem exists isn’t like writing an academic research paper.

• Going slow. James once said “the quicker you are, the worse you can be at product. If you are bad at product and slow, you are doomed.” Don’t worry about looking dumb because you are dead by default.

Step 2: Validate users want your solution

This phase is similar to the first, but now you’re validating your solution to the problem, not whether it’s a real problem or not.

Having two co-founders helps here. One can focus entirely on building, while the other does everything else necessary for validation.

In the early days of PostHog, Tim built it, James sold it. One of the first products they built leveraged James’ experience as a salesperson. It was a complicated sales territory management tool to help reps move on from accounts that weren’t moving forward.

After 15 sales leaders said they would use it, they built it and sent them a link. Only one person clicked the link and they didn’t even log in. This was a clear sign this wasn’t what users wanted and it was time to build something else.

Beyond just building the wrong thing, there are two other big problems you can run into at this phase:

Problem #1: Not explaining your solution clearly

Articulating the problem is only half the battle. You need to articulate your solution, too. Square the circle and explain how your solution solves their problem.

If you do this well, you might not need to do anything else. Many startups have built huge waitlists before their product even launches, validating demand.

A classic example is Dropbox, whose viral demo video led to thousands of signups before they built anything.

Problem #2: You lack credibility

If you’re still struggling to convince users of your solution, it may be because you don’t have enough “street cred.”

There is a reason every YC founder brags about their past startup and schooling successes. Even though they might not be successful yet, this gives them the credibility to convince others they can pull it off.

For PostHog, James and Tim thought of reasons why people wouldn’t want to use it:

1. Users might not believe there was a real company behind it. Publishing the handbook gave the company some legitimacy. They took inspiration from GitLab.

2. Users might not trust others with their data. Making PostHog open source and self-hostable was the solution to this.

Airbnb hosts famously weren’t getting bookings because their photos sucked. Brian Chesky and Joe Gebbia flew to New York to take better photos for them (while doing more validation).

The GOAT founders did something similar with sneakers, buying some and taking photos on different types of flooring to make their stock look more robust.

A bit of polish in the right places goes a long way at the early stage.

Step 3: Validate your solution works

You do this by retaining users.

If you can retain users, you are repeatedly solving their problems. This is rare, valuable, and a sign you should start investing more into product development.

At an early stage, this doesn’t need to be complicated. You can follow this simple product improvement loop:

Closing the loop above is the way to cement your product-market fit because:

1. Your product improves fast. Weight user feedback very heavily compared to your instincts around what to build.

2. It generates word of mouth growth. The one thing you can compete on is speed. You can outperform any competitors by providing an excellent experience to your early users so they tell their friends.

3. Listening to users compounds. The more you listen to users and act on their feedback, the more useful feedback they’ll share with you.

You should have deployed some analytics by now to track how people use your product, and you can create retention insights (like the one below) to track this.

You’re looking for a retention curve that flattens out like the one above. Other useful signals include:

1. Qualitative feedback. Talk to users. Run a feedback survey. Ask the PMF question → “How would you feel if you could no longer use the product?”

2. Session replays. Watching real users use your product shows which areas are most important and which ones they struggle with or are confused by.

3. Activation. Before you can retain a user, they have to activate. If they don’t, they can’t experience the value of your product. Get them to this point faster if you can, even activate them yourself if you have to.

4. Revenue. As long as you’re not selling dollar bills for 50 cents, having people pay you (or desperately want to pay you) is clear evidence.

If you’re getting conflicting feedback, you might have multiple user personas using your product. Defining your ideal customer profile can help you figure out whose feedback to listen to.

What’s after validation?

If you can clear all three stages, congratulations: your idea is validated and you’re on your way to the promised land of product-market fit.

The next step is really to turn your validated idea into a successful startup (this makes it seem easy, doesn’t it?). Some of our other posts will be helpful now like:

• The Product-Market Fit Game (Level 5)

• 50 things we’ve learned about building successful products

• How we got our first 1,000 users

• An engineer’s guide to talking to users

• How first-time founders fail

But the reality is you never stop validating. You still need to:

• Validate the features and products on your roadmap

• Talk to users and figure out their real problems

• Get people to try what you’ve built

• Activate and retain them

• Iterate on feedback

This can all be clouded by the success of the larger business, so you’ll probably need to work harder to find the real signal.

The nice part is that this gets easier when you have existing users. It’s easier to recruit them, they want to help you as it helps them. As Ali Rowghani once said “As you get more users, you can start to see around corners.”

Validation is thought of as a skill of only the earliest of startups, but it shouldn’t be. It’s a fundamental one that is useful at all stages of a company’s journey. Even if you’re not a founder, getting better at validation (and practicing it) will create dividends.

Words by Ian Vanagas, who believes liking, subscribing, and sharing is a good enough validation signal for this newsletter.

Subscribe and share to help me validate this newsletter

Subscribed

🦔 Jobs at PostHog

Want to help us validate more products? We’re hiring product engineers and more roles like:

• Software Engineer — Language Design

• Technical Account Manager

• Product Manager (ex-founder or ex-product engineer)

• AI Product Engineer

📙 More good reads

• How To Get Startup Ideas – Paul Graham

• (User) Interviewing Tips – Christina Cacioppo

• How we built user behavior analysis with multi-modal LLMs (in 5 not-so-easy steps) – Alex Lebedev

• 8 learnings from 1 year of agents – Michael Matloka