Skip to content

Add persona section to Surveys team page #14213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
fivestarspicy wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Add persona section to Surveys team page #14213

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions contents/teams/surveys/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,37 @@ hideAnchor: false
template: team
---

## Who are we building for?

### Personas

- Primary (churn signals product failure):

- **Product engineer**
- JTBD: Validate assumptions without meetings, tie feedback to behavioral events, minimize eng overhead for survey ops
- Why prioritize: Champion persona who instruments + acts on data. Want "instant context" without Slack threads.
- **Product manager** (product-minded, technical)
- JTBD: Prioritize based on demand signals not opinions, connect feedback to conversion/retention drops, avoid telephone game between users and product
- Why prioritize: Key owners of survey processes. Running discovery sprints that need tight feedback loops.
- **Growth engineer**
- JTBD: Diagnose funnel drop-offs with qualitative context, validate experiment hypotheses, auto-push survey data into workflow tools
- Why prioritize: Leverage surveys for rapid experimentation. Minimize cycle lag between signal and action.

- Somewhat support (should work, churn acceptable short-term):

- **UX researcher**
Copy link
Contributor

@adboio adboio Dec 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe not UX research specifically... but my gut says we should maybe prioritize these "non-tech roles" a bit higher

TL;DR i think my feedback is our product should be accessible to anyone at a given company:

  • the UX should be sexy, buttery smooth, self-explanatory
  • if we water down any controls for the sake of better UX, everything should still be accessible to "power users" - e.g. technical roles
  • i think we can do this without sacrificing our attention to core persona. we don't necessarily need to build more features specifically for marketing/UXR/support, but a bit of polish on the UX unlocks a lot of potential users, i think
  • i'm realizing this might all sound like word salad and maybe not even super relevant to this particular doc, but pls give me your thoughts haha

looking back to some of the highest value user interviewers i've done (for product tours and surveys, i think ICP overlaps) and support tickets, the users are generally somewhat technical, but not always developers - and i think there's a bit of "survivorship bias" in play there too (in the current state, a user has to be pretty technical to use our product)

examples:

maybe this goes against the posthog ICP as a whole(?) but i think as a company grows, the dev teams end up with a task "implement posthog", and it's non-developers actually using the platform from there

the trend i think i'm seeing is small companies / startups => developer / product eng / solo founder / etc is creating surveys (ex1, ex2). then as company grows => it's someone else entirely (examples above)

- JTBD: Collect feedback at scale for lightweight/high-frequency product triage
- Why somewhat: Will churn to specialist tools for complex and rigorous research. Acceptable while we build intelligence layer.

- Not building for (actively okay with churn):
Copy link
Contributor

@adboio adboio Dec 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when we say "actively okay with churn" here, can you clarify?

is this churn in the sense that a marketing team or support team signed up for posthog on their own, decided it was too complex or lacked features, and then churned? or like an existing company uses posthog, support/marketing tries to adopt surveys, they decide they do not like it?


- **Marketing teams**
- JTBD: Market research, NPS/CSAT tracking, compliance surveys
- Why not: We're product feedback not market research. They need localization, broad external survey tools we won't prioritize.
- **Support/CS**
- JTBD: Support quality scores, post-ticket satisfaction
- Why not: Derivative of product eng workflows. Uses overlap features.

## Slack channel

[#team-surveys](https://posthog.slack.com/messages/team-surveys)