It Took Six Product Pivots to Find PMF — This Company Is Sharing Its 10,000-Word Methodology | Z Talk

Z Talk is ZhenFund's column for sharing insights.

This article is a PMF playbook by PostHog CEO James Hawkins, drawn from six product iterations at PostHog and informed by consulting with over 50 YC startups. Before finding PMF, PostHog pivoted six times in its first six months, eventually achieving million-dollar revenue growth and attracting over 20,000 customers.

PostHog is an open-source product analytics tool. Open source and self-hosting were the two solutions that helped them find PMF, simultaneously addressing two shared needs among SaaS and B2B customers: the desire for deep user behavior analysis and the reluctance to depend on external third-party platforms. Currently, PostHog has earned 21.8k stars on GitHub, and its product and data toolkit is used by 70,000+ teams.

The specific challenges of finding PMF vary, but the underlying principles remain constant. The process is full of pitfalls, requires some luck, and definitely won't be a straight path. This article is republished from Founder Park; here is the full text:

01

Finding PMF is like playing a video game —

with just 5 levels

They are:

1. Find an important problem to solve
2. Validate the problem by talking to users
3. Get users to start using your product
4. Get users to keep using your product
5. Land your first five reference customers

To win the game, you need to complete all five levels. Except for the first level, each has multiple ways to fail. I've listed these — work through them in order. If you find yourself unable to complete a level, it probably means you need to make a major pivot for the entire company. I'll share notes on pivoting at the end.

Remember, in every conversation with customers or prospects at each stage, document everything in detail. You might need to revisit a specific detail later, and these records may help with other ideas down the road. At PostHog, we filled a Google Doc of over 100 pages in our first few weeks.

Let's begin.

Level 1 — First, find an important problem and solve it

Start by solving a problem you've personally encountered. You need to have not just experienced it, but actually tried to solve it — otherwise it's not truly an important problem.

Your idea and the user segment you choose to serve will profoundly shape your career and personal life. I recommend trying out multiple ideas, then figuring out what you enjoy and why.

A few suggestions:

• Choose user groups you'd actually enjoy spending time with. Early on at PostHog, we tried building a tool for sales leaders. We quickly found that people who talked a big game on calls but couldn't follow through on promises were exhausting. So we shifted toward customer support or engineers — we found them more reliable.

• Solving known problems is relatively easy to validate, but your solution must be meaningfully different. If you want to build a company that can scale, your product or service needs to be 10x better or 10x cheaper than existing options.

• Be cautious when validating problems that seem like nobody cares about. You might have genuinely spotted something others missed, but more likely, the problem simply isn't important.

• Stay wary of hot trends. Competing against unsexy, poorly managed, innovation-starved companies is usually easier than going up against VC-backed, cutting-edge startups. Don't be fooled by large funding rounds and media coverage — they don't equal PMF. In fact, the hotter a space is, the lower the odds of success for any given company.

• Conservative buyers demand differentiation. It's easy to get someone to try a new social app, but much harder to get a business to adopt an unproven CRM system. A replacement strategy is harder than a new-category strategy. Selling to customers with no existing solution is far easier.

Many people spend months or even years validating their ideas upfront and get nowhere. Actually building something and getting users on it always gives you clearer direction, so don't hesitate — move fast at this stage.

Level 2 — Validate the problem really exists by talking to users

Now you think there's a problem, and you need to figure out if others feel the same way. To do that, you need to talk to them. This is hard because you're asking people to spend time helping you validate a problem they might not even care about, which you might not end up solving anyway.

It's a bit late to say this now, but if you've been consistently helpful throughout your career, this stage will be much easier!

Here are some ways to get meetings, ranked from easiest to hardest:

Meeting tips:

• Keep outreach brief. Two to three sentences max — don't write a wall of text. Remember: on the internet, everything you do is competing with cat videos.

• Be explicit about what you want, both in your outreach and during the meeting. If you want feedback, say so. If you want to sell, say that too. This time, just validate the problem; come back to sell later if validation succeeds.

• Don't over-rely on automated outreach — it's a waste of energy. Send more messages, but you don't need dedicated software to blast out thousands of emails. If you go to that extreme, you're probably close to failure — it means nobody actually cares what you're saying.

• Some groups have inherently low response rates. For highly competitive segments or executives, cold emails to complete strangers may be completely useless. If your product only targets Fortune 500 companies, think twice before proceeding without sufficient connections.

• Speed is critical. If someone replies, respond within 30 seconds — yes, that fast. I used to run a call center business; if we could call back within 5 minutes, the chance of booking the customer jumped 90%. Startups win on speed, so watch your messages like a hawk.

Note that most people you talk to will express interest out of politeness or because they think they might use it someday — this won't get you real users. The Mom Test is an important book on how to talk to potential customers and users, and it's worth reading.

If the problem is high-priority, prospects have probably already spent significant effort trying to solve it. A quote from YC partner Dalton Caldwell is worth remembering: "If a company has a bad but homegrown system that they rely on heavily, there's a big opportunity to provide that product."

Early at PostHog, we found that teams needing more data control would build their own analytics infrastructure rather than use existing SaaS products. These homegrown solutions were usually complex and ineffective.

Try to identify a specific problem. The clearer the problem, the easier it is to validate and solve. Specificity comes not just from product features but from target users. For example, PayPal realized that high-volume eBay sellers had a payments problem.

Even so, there's a limit to what you can validate this way.

The best feedback is whether users actually use, repurchase, and pay for your product — which is why I say get to the next stage as fast as possible. Don't drag out the validation phase; this should be a quick, sharp process — measured in weeks, not months.

Early at PostHog, my best strategy with my cofounder Tim was to have him focused on coding while I spent massive amounts of time gathering feedback. We were always ready to scrap everything and start over, and we did — six pivots in total. This let us validate our ideas much faster.

If users explicitly express that they want you to solve their problem, stay in close contact with these early prospects. Most people's inboxes are stuffed with spam that feels impersonal. Instead, try pulling customers into WhatsApp groups, private Slack channels, or Discord servers. These communication channels will become extremely important in the next stages.

Get to Level 3 as quickly as possible. Typically, Tim and I spent just one week per idea in Level 2. If we couldn't crack it in two weeks, it was probably time to go back to Level 1 and start over.

Level 3 — Validate your MVP by attracting real users

Once your product is ready for users, rush to Level 3. At this stage, keep talking to users, but now that you have an actual product, validation becomes much more effective.

The goal here is to confirm as quickly as possible whether users actually care. No matter how well you understood their problems in interviews, watching actual usage is far more reliable.

Before pivoting to PostHog, Tim and I worked on a project where 15 companies said they'd "give it a try." When we finished the product and sent invite links, only one person clicked through to start using it. Fortunately, we hadn't spent six months polishing a "perfect" version.

The ideal starting point is users you've already engaged with in Levels 1 and 2. In those conversations, you should have identified their problems. Now that you have a solution, reach out proactively and let them know.

Some users won't use your product. Here are some possible reasons why:

• They don't understand what your solution is, so it feels like a waste of time. The product may be free, but users' time isn't. The higher their position, the more this matters. Can you work with their subordinates to trial the product? If there's no response at all, there may be a deeper issue — even executives will make time if the problem is severe enough.

• You haven't explained the product clearly. How you describe it matters; too complex and people won't get it. Explain it like you're talking to a friend, and directly ask users what they think of your explanation.

• You lack credibility. If your website is a mess or looks unprofessional, businesses won't risk trying it out. At best, they'll think it's a waste of time; at worst, they'll see security risks or potential problems. This is why it's best if you chose this idea in Level 1 because you encountered a similar problem yourself — it means you're qualified to help others solve it. When engaging with them, mention your relevant credentials, especially the convincing parts. People usually won't voice their concerns directly; they may go silent or give misleading feedback, saying the problem lies elsewhere.

• Users doubt your solution will actually solve their problem, so they don't see a reason to try it. If potential customers don't buy into your approach, they won't try your product. Common objections: "Software can't fix people problems" or "AI sounds nice, but it's not accurate enough in real-world use."

• Users can't access your solution. This was one of the early problems PostHog's users faced. Triple-check that people can actually get started with your product smoothly.

• Users have concerns about your solution. Does your product require access to personal or company data? Just ask: "I noticed you haven't started using the product — can you tell me directly what makes you uncomfortable?" Can you reduce data access requirements? Can you make your product or website look more professional and trustworthy? If the perceived security risk outweighs the benefit of solving the problem, the problem itself probably isn't big enough.

• Users don't actually want to solve this problem. Many problems aren't high priority, and your solution feels like too much hassle. Can you make your product 10x easier to use, or 10x more appealing? If not... pick a different problem. Go back to Level 0.

• Users never encountered the problem you described. Pick a new problem and restart from Level 0.

Level 4 — Validate Through Retention

Great, people are using your product! Now see if they come back. Figure out your expected usage frequency, then check if users are roughly following it. If you keep solving their problem, they'll naturally return. If not yet, set up analytics to track retention.

Try not to rely on reminder emails or push notifications to drag users back. If you need these tactics to retain users, your product probably isn't compelling enough for them. Focus on building more powerful or more usable features instead.

Once you have some usage data, start collecting qualitative and quantitative feedback. See which features have the highest usage, schedule feedback calls, observe how users interact with your product.

If users are willing, ask them to walk you through their usage live, ask why they clicked certain things. You'll be amazed at how many ways users can confuse themselves — but if they keep coming back, that's actually a good problem to have.

Start "closing the loop" with users. The process is simple and highly effective for improving your product:

Benefits of closing the loop:

1. Faster product improvement. Rather than developing features on intuition, prioritize user feedback for more effective improvements.
2. Word-of-mouth effects. You can compete on speed — give early users such an excellent experience that they actively recommend you to friends.
3. User feedback is a virtuous cycle. Like a snowball, the more you listen to users and act, the more valuable feedback they give you.

Failure modes:

• Users don't activate. They signed up but couldn't configure or start using your product, so they got no value. You have two options:

  • Manually activate users. The Stripe founders are a classic example — they personally found their first users and helped them set up the product. These unscalable efforts help you build tighter relationships and get more feedback.
  • Simplify the activation/onboarding flow. Can you make it 10x simpler?

• Conflicting feedback, unsure what to build. Move to Level 5 — this will help you distinguish between your Ideal Customer Profile (ICP) and non-ICP users, giving you clearer direction.

• Product doesn't solve the user's problem, so they have no reason to return. Build a new product for the same problem, or fix the existing one. Re-enter Level 3.

• Product is hard to use. Get user feedback, watch session replays, or directly observe users operating your product.

• Users don't need to use it repeatedly. Maybe the problem has been automated away and requires no further user action. Move to Level 5 to verify if they're willing to pay. If the problem is solved without ongoing interaction, don't force usage.

• Users use the product but rarely encounter the problem you solve. Move to Level 5. Infrequent problems can be hard to monetize substantially, but demand is demand. If the market potential is large enough, low ACV can work. But if recruiting users is very difficult and pricing is constrained, the problem probably isn't big enough — go back to Level 1.

Level 5 — Win Your First 5 Paying Reference Customers

First, define your Ideal Customer Profile (ICP).

List the needs, characteristics, and attributes you believe your ICP might have. These should be very specific, at either the individual or company level. For example:

What PostHog considers when thinking about ICP:

You can also list "anti-needs" or characteristics they don't have or need.

List all potential users in the first column, score them against these attributes, and color-code the table to make patterns easier to spot. This will be helpful when evaluating whether users are willing to pay.

Be transparent with customers. If you haven't been clear about commercial expectations early on, this step can get tricky. If so, it may be easier to pitch to new users who have clearer expectations. Use your website to clearly state that the service is paid, or will be charged after the test period.

Next, you'll need some pricing strategy, and you'll probably need to iterate multiple times:

• Step one: Create some internal pricing tables and adjust them after every few sales calls.

• Step two: Consider showing pricing publicly, but only do this when step one is working reasonably well.

• Step three: If the company is focused on self-serve, you can complete payment without talking to users. But only do this after step two is complete and if it fits your go-to-market strategy. If your product is enterprise-facing and requires top-down sales, this approach probably isn't suitable. If you're product-led, give it a try.

Important! Don't jump straight to self-serve. Remember, at this stage you're optimizing for learning, not revenue. Moving to self-serve too early reduces your learning opportunities. In hindsight, I think discussing with early users what they'd be willing to pay is extremely important.

Now, it's time to land your first paying customer! This means a customer who pays full price, uses your product as expected, and is willing to recommend it to others. If you can land five of these in a row, congratulations — you've successfully completed the PMF challenge.

Once you have 5 such customers, you're on the path to PMF. Here's what to do next:

• Replicate this pattern and grow revenue to roughly $1 million in Annual Recurring Revenue (ARR). If you're confident in your sales, feel it's smooth and repeatable, then aim for at least $500K; if every sale feels hard or the process varies, push for $1 million.

• Next, see if others can succeed using your method. Have two other people do sales, so you can confirm the issue is product-market fit, not a particular individual.

If growth becomes easy at this point, congratulations — you're probably close to product-market fit.

But there are still pitfalls that can trip you up:

• Don't outsource sales. Finding PMF is already a complex problem — don't add the extra variable of "is it a product problem or a sales problem." No matter how experienced an outside salesperson is, founders are always the best people to sell their own product. Founders may hand this off due to fear of failure, lack of confidence, laziness, or overconfidence — resist this impulse. Ensuring a viable business model is critical, and this usually requires multiple adjustments to product, pricing, and positioning. Founders can make these adjustments faster and more effectively than employees.

• Can't land the first customer. If users are willing to try your product but won't pay, it's likely because: (i) they have a problem they hoped your product would solve, but it doesn't actually solve it; or (ii) the problem exists but isn't valuable enough. For the former, you need to figure out how to make the product solve the problem better. Are critical features missing? Too many bugs making users unwilling to pay? For the latter, you may need to go back to the beginning and find a more valuable idea.

• Users paid but aren't satisfied. This could be because you charged very little but didn't actually solve the problem — users may have paid a small amount out of politeness or hoping you'd solve it in the future. If they paid a lot but aren't satisfied, their problem may be so severe they were just hoping you could solve it. In either case, go back to the previous step and make sure the problem is actually being solved.

• Your customers are too different from each other. Making sales is good, but you can't sell a different product to each customer and call that product-market fit. Can you repeat one sales experience four more times? If yes, you're doing it right. If not, go back to the previous stage and keep optimizing.

• Stuck at this step. If you keep making small progress but can't convert it into substantial revenue, you may lack the ability to fully solve the problem you're tackling, even if the problem genuinely exists. If you want to keep trying, persist a bit longer. But if this pattern keeps repeating, choosing a simpler target might be wiser.

02

The 5 Key Items Needed to Complete the Game

A Co-founder

The PMF challenge is a cooperative game, especially if you want to build a company that can attract venture capital. It's a long process where you'll face thousands of decisions. The only thing that can truly make you fail is giving up. And with two founders pushing through together, your odds of persisting are much higher.

For a SaaS company, I'd suggest following these principles:

• Ideally, both of you are technical. You need an "execution machine" that can rapidly advance through each stage, and in the early days, the ability to build software quickly is often the biggest bottleneck. (Optional)

• At least one of you must be willing to devote most of your time to selling. You don't need extensive sales experience, but you must be willing to take on the challenge. Startups are actually full of "sales" work — recruiting early users, building a team, attracting investment, and so on. (Critical)

• Both of you must be willing to talk directly to users. The person who ultimately writes code needs to discover problems and provide solutions through user conversations. Developers typically gain deeper understanding of user needs, so their communication with users is crucial to the product. (Also critical)

Remember, you're committing to a partnership that may last longer than a marriage, so think it through carefully. The goal isn't to determine who's right or wrong, but to solve problems together as true partners to each other.

If the CEO simply issues orders to the CTO and makes all the decisions, that's not a "co-founder" relationship.

How do you truly collaborate? Here are the ways we handle it:

• Company design / people and hiring / culture: Your company is also one of the core products you're building, and it's the only input you have complete control over. You should regularly discuss what kind of company culture you want to build, and what you value most when it comes to people, hiring, and decision-making.

• Strategy / vision: While strategy may be primarily led by one founder, the other should be deeply involved. If you can't align on vision, the problem will only be magnified for your team and company.

• Roles and responsibilities: You need to flexibly swap roles to play to each other's strengths. Getting to your first $1 million in sales is a different challenge than scaling to $10 million. What the product needs before PMF is different from what it needs after. Throughout PostHog's growth, Tim and I regularly exchanged roles.

• Board / fundraising: This is closely tied to company strategy. While the CEO handles all investor calls — so the other founder can focus on driving the business forward — maintaining transparent communication is essential. You can update each other through shared meeting notes or weekly discussions. Both founders should attend board meetings and meetings with existing investors together, each taking their share of responsibility.

When choosing a co-founder, here are some questions you can discuss with potential partners:

• How long are we willing to try to achieve PMF?

• How long can we afford to try?

• Do we want to raise funding or bootstrap?

• What do you hope to have accomplished when you look back at age 80?

• What kind of company do you want to run? How does it operate day-to-day?

• What are our respective roles? Will you still be happy with these roles in five years?

• If someone offered $1 million / $10 million / $100 million / $1 billion, would we sell?

• What kind of work do you want to do / not want to do?

A Simple, Thoughtfully Designed Website

The importance of website design may exceed your imagination.

Most people quickly build a website using templates in the early stage, which is fine — especially when you're just starting out. PostHog's lead designer Cory once called himself a "webmaster," and he had a good summary of this: "We didn't set out to make the flashiest website, so we just made one that looked different."

For your product, you want it to look credible, but it doesn't need to be top-tier from the start. In fact, when you first start attracting user signups, website design becomes particularly important, because this step might cause you to lose 90% or more of potential users.

The good news is that design starts with copy. If you can use simple, clear language on your website to explain what you're doing, and it happens to meet visitors' needs, then you've already surpassed 75% of other websites out there.

Don't make every pixel perfect. Stripe's design lead Malthe Sigurdsson told me that great designers work fast and iterate — they don't expect to get it perfect the first time. Before meeting him, I had assumed he would tell me they had spent months grinding in Figma design panels before finally launching their website.

A Rapid Iteration Mindset

Like most early-stage startups, you'll probably make mistakes (after all, most startups fail), so you need to optimize this process.

Your top priority is figuring out whether any users actually care about your product. Therefore, shipping your first feature quickly is most important. Scalability doesn't matter at this point — just use a tech stack you know and that's popular. We chose Django and React.

Ship new features early, even if they're not fully polished, to attract users who are eager to try new products.

Unless your product's core selling point is design, it's far more meaningful to quickly launch a rough, imperfect feature and iterate continuously than to spend months polishing something nobody cares about.

An Open and Efficient Communication Style

Don't put any barriers between developers and users. This only slows things down and creates confusion. Turning user feedback directly into product features is far more efficient than simply handling issues, and users are more willing to communicate with the people who actually build the product.

Be clear about role division with your co-founder. When Tim and I started acquiring users, I focused on continuously expanding to new users while he was responsible for fully serving existing users.

Remember, users are people, and your success depends entirely on them. How you start a call sets the tone for the entire conversation. Be enthusiastic and show that you're genuinely happy to talk with them. Go the extra mile for them — help them log issues, create tickets, and keep information transparent. If possible, respond within minutes.

A Simple, Repeatable Sales Model

In the search for PMF, don't rush to scale sales. Focus on one deal at a time. Make full use of your network, directly contact companies you think are a good fit, and attend relevant events.

Generally, don't expect to acquire customers through marketing (such as paid ads or content promotion) — these methods are better suited for the scaling phase. Instead, do it yourself. Early success depends more on the quality and personalization of the sales process.

Stay disciplined. Set goals, such as how many meetings to schedule each week, and stick to them. Just like with feedback calls, try to exceed customer expectations by being efficient and responsive.

In each call, let potential customers talk about the challenges they face and see if your product can solve their problems. At the same time, qualifying potential customers is also important. The simplest method is using the BANT framework (Budget, Authority, Need, Timeline).

Here are some practical examples of layered questioning techniques:

Level one: "What are the requirements for this project?" "How do you select vendors?" "Do you have a fixed budget?"

Level two: "This sounds like an important project — why?" "If a product is missing certain features, would you consider it?"

Level three: "If users are eventually trained and effectively use this product, what impact would it have on your revenue?" "What does solving this problem mean to you?"

Prioritize spending time communicating with the most qualified prospects, filtering out those with high product fit.

Once a customer decides to move forward, you need to present an agreement for them to sign. YC has a free SaaS sales agreement template (https://www.ycombinator.com/sales_agreement/). For your earliest customers, stay flexible on contract terms — the focus isn't on maximizing revenue or contract length, but on closing the first deal and getting feedback and learning from it.

A Risk-Free Pricing Model

The core goal of early pricing is to close the deal first.

This means minimizing risk for early customers. Charge monthly rather than annually, unless customers prefer annual contracts. If customers lean toward annual contracts, offer termination clauses that let them exit under certain conditions, reducing their decision risk.

You can also offer limited free usage or set a free trial period of a certain length, letting customers experience your software before buying. This also helps alleviate their concerns and reduce their risk.

03

Finally, let's talk about pivots:

Why, when, and how to pivot?

Much of startup culture would have you believe that the best startups require years of grinding hard work to get off the ground. But we discovered at YC that the reality is exactly the opposite.

Most top companies at YC went through pivots. Because most startups fail, if you're not pivoting, you might be doing something wrong. At PostHog, we pivoted six times in our first six months!

The five stages of PMF should help you determine when to pivot, but here are a few additional suggestions:

• Motivation matters. If you're not interested in what you're doing, pivot. It's that simple. Doing what interests you will take you much further.

• Decide decisively. In our YC batch, we saw some companies have one founder work on X while the other worked on Y. Finding PMF is already complicated enough — don't make it harder by dividing your attention. Pick one thing and go all in. If it fails, quickly move to another idea.

• Don't go looking for problems to fit your solution. It's easy to become attached to existing code or problems. Be especially wary of very minor pivots. One of our initial ideas was building a tool to monitor technical debt — plugging into GitHub, asking engineers where they were running into problems and wasting time. When we couldn't sell it, we had to pivot, then used the same approach to monitor engineer happiness instead, reusing our code. The result was wasting a week in meetings before ultimately abandoning it anyway.

04

One more thing,

Make time to reflect, no matter how busy you are

Achieving PMF is hard because it's a multivariate problem. Most of the time, you don't fully know why something works or what doesn't. So in the early days, you'll be full of doubts (this is normal).

Looking back, one key factor in PostHog's success was the idle time Tim and I enjoyed several times a week — driving to YC, driving back from YC dinners.

Why?

Because the ultimate failure mode is not understanding the big picture. These long drives without computers gave us the opportunity to reflect, to step away from the daily grind and examine everything we had learned so far.

Without hard work and persistence, you can't get through the PMF challenge. But sometimes you need to stop, look at the map, find your direction, and carefully choose your next target. So make time to reflect every week!

Recommended Reading