How to run a PMF survey with PostHog

If you already run PostHog for product analytics, you're sitting on the exact data that makes a PMF survey trustworthy: who used what, how many times, and how recently. Most teams still send the survey to everyone in their database instead. Here's how to use PostHog's own targeting to fix that.

Step 1: Define your core action

Before you build anything in PostHog, decide on the single event that best represents someone getting real value from your product, not a login, not a page view. For a project-management tool that might be "task completed." For a design tool it might be "design exported." Pick one that's specific enough to mean something and common enough that engaged users trigger it repeatedly.

This is the same principle behind who to survey in general: someone who's used the core of your product at least twice in the last two weeks. PostHog just lets you define and enforce that rule with actual event data instead of a guess.

Step 2: Build the engaged-user cohort

In PostHog, create a cohort filtered on your core event firing at least twice in the last 14 days. This is a behavioral (dynamic) cohort, it recalculates automatically as usage changes, which is exactly right for tracking who's currently engaged.

There's one technical step you can't skip: PostHog's own documentation notes that dynamic cohorts need to be duplicated into a static cohort before they can target a survey, feature flag, or experiment, because live behavioral calculation is too slow for real-time targeting. Duplicate the cohort, and target the static copy, not the live dynamic one.

Step 3: Build the survey

PostHog's survey tool doesn't ship a PMF template, so you build the question set yourself. Use the exact wording from the PMF survey questions guide: the core "how would you feel if you could no longer use [product]" question with the very/somewhat/not disappointed options, plus the three open-ended follow-ups on who benefits, the main benefit, and what to improve.

Set the survey's targeting to the static cohort you built in step 2, not "all users." This single setting is what turns a generic feedback popup into a survey whose result you can actually trust.

Step 4: Collect toward 40, not toward a deadline

Let the survey run for 2-3 weeks so it catches engaged users across their normal usage pattern rather than a single snapshot. Watch the response count, not a calendar date. You're aiming for at least 40 valid responses for a directional read, 100+ for an investor-grade number. If you're short after a few weeks, see the response-rate playbook before you widen who counts as engaged.

Step 5: Score and segment

PostHog will collect the raw answers, but it won't calculate a PMF score or segment respondents into an ICP for you, that's a separate analysis step. Two ways to close the gap:

• Direct cohort connection. Point PMFtracker at your PostHog cohort so the same engaged-user definition drives both the survey targeting and the scoring.
• Export and import. Pull your PostHog survey responses as a CSV and import them into PMFtracker for scoring and segmentation. This is the exact path used in the UX Pilot case study, where 303 paid users were surveyed in-product via PostHog, then the responses were exported to CSV and imported into PMFtracker to produce a 49% PMF score with a full ICP breakdown.

Either path gets you to the same place: a Sean Ellis score calculated on the 40% rule, plus the segmentation and open-ended analysis that turns a percentage into a roadmap. For a broader look at where PostHog fits among other options, see the best PMF survey tools compared.