How to connect a PostHog feature flag rollout to the feedback it generates
Nothing in PostHog's feature flag tooling collects what people say about the feature you just rolled out. The flag implementation docs cover evaluating a flag in code, and the rollout and targeting docs cover release conditions and percentage rollout down to 0.01% precision. Neither mentions comments, sentiment, or anything qualitative. A flag tells you who's in the 10%; it has no opinion on what they thought.
So the feedback has to be wired up separately. PostHog gives you two real pieces to build that with, a survey that targets exactly the rollout cohort and an annotation that marks the rollout on your graphs so a metric shift has a cause attached to it. Neither one, on its own, catches the Slack message or the sales call where someone mentions the feature by name. Here's how to set up what PostHog does support, and where the gap actually sits once you have.
Target a survey at the rollout cohort, not everyone
PostHog surveys can target by linked feature flag: under a survey's display conditions, "Linked feature flag" restricts the survey to users for whom that specific flag evaluates true. The survey creation docs give this exact scenario as the example: roll out a new-landing-page flag, then link a survey to it so only the people who actually saw the new page get asked about it.
This is the one PostHog-native step that closes real distance. Without it, a survey asking "how do you feel about the new dashboard" gets answered by people who never saw the new dashboard, and the responses are noise. Linked to the flag, every response comes from inside the 10%.
Two things worth setting deliberately when you build it:
- Trigger it on the action, not on page load. A survey that fires the moment the flag evaluates catches people before they've used the feature. Firing on the specific event the feature enables (a button click, a completed flow) gets you people with something to react to.
- Ask one open-text question, not five. Rollout surveys get better completion and more usable quotes from "what would you change about this?" than from a five-question CSAT block nobody finishes.
Annotate the rollout so the metric shift has a cause
Separately, mark the day the flag went to 10% as a PostHog annotation. Annotations attach a note to a specific date on an insight or dashboard, and PostHog's own documentation calls out marking deployments and releases as a primary use case, with an optional emoji for quick visual scanning of a timeline.
This doesn't collect feedback, but it prevents a specific failure. Three weeks after the rollout, someone asks "why did signups dip on the 14th" and nobody remembers a flag went out that day. An annotation on the graph answers that question before it's asked, and it's the cheapest step in this whole guide, three clicks on an insight.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhere the survey and the annotation stop covering it
A linked survey and an annotation get you two structured signals: a response rate you chose to ask for, and a timestamp on a graph. What they don't get you is the feedback nobody was prompted to give.
The rollout to 10% of users doesn't stay contained to people who fill out a survey. It shows up as:
- A support ticket titled "the new checkout is confusing" from someone who never saw the survey because they closed the tab before it fired.
- A Slack message in a customer channel: "hey, did something change in the dashboard? one of my team's confused."
- A comment on a sales call, three weeks later, from a prospect whose contact at an existing account mentioned trying the new flow.
None of that routes through PostHog. It routes through whatever tool that conversation happened in, and by default it stays there, disconnected from the fact that a specific 10% cohort was seeing a specific flagged feature when they said it.
Where this needs something beyond PostHog's native tools
Below a certain volume, the setup above is genuinely enough. A survey linked to the flag, an annotation on the dashboard, and a product manager who reads support tickets and Slack with the rollout in mind will catch most of what matters when a flag is at 10% of a few hundred accounts.
That manual cross-referencing stops working once the rollout crosses a few dozen mentions a week across more than one channel, or once more than one person is on point for reading support, Slack, and sales notes. Nobody has time to hold "was this account in the 10%?" in their head while triaging a ticket queue.
Once that's the situation, we'd point at Modem. Modem's PostHog integration reads feature flags, rollout percentages, and targeting conditions directly, and separately watches Slack, support tickets, and sales call notes. It matches a mention like "did something change in the dashboard?" against the same topic as a support ticket that names the feature outright, and it can tell you whether the accounts complaining were actually in the flagged cohort, instead of leaving that cross-reference to whoever happens to be reading both channels that week. We build Modem, so weigh the recommendation with that bias in mind; a broader comparison of tools that pair PostHog data with feedback tools is in our guide to pairing PostHog with customer feedback. Pricing is unlimited users on every plan, pay-as-you-go beyond included usage, not a per-seat charge for however many people are reading tickets that week.
The underlying practice, of counting scattered mentions into one topic before deciding what to act on, isn't specific to PostHog rollouts; it's covered more generally in how to centralize customer feedback.
Create the survey before the flag goes out
If the flag is going out this week: create the survey now, linked to the flag, firing on the action the feature enables, one open-text question. Add the annotation on whatever dashboard you'll be watching. Then, for the first two weeks, when a support ticket or Slack message mentions the feature by name or by description, note in the annotation's edit or a shared doc whether the account was in the rollout. That habit alone catches most of what the automated version does, until the volume makes the habit too slow to keep up with.
