# Message test — https://posthog.com/ After reading your page, only 3 of 15 personas could name a reason to pick you over a similar option. - **Page tested:** https://posthog.com/ - **Audience tested against:** mid-market and high-growth tech startups led by product engineers rather than traditional marketing or data teams - **Personas:** 15 simulated - **Report:** https://grader.wynter.com/r/posthog-we-make-your-product-self-driving-xGExEYE > These answers are generated by AI, scored on Wynter's B2B Message > Layers framework using behaviorally-diverse simulated personas. The > methodology is real and the critique is directional. What a simulated > persona cannot have is a live budget, a renewal coming up, or a boss > asking about this quarter. --- ## 01 · The scores Every persona answered all four questions. These are four independent proportions of the same panel, not stages of a funnel. | Layer | Question | Cleared the bar | Strength | Of those who passed | | --- | --- | --- | --- | --- | | 1. Clarity | Do they understand what you do? | 15/15 | 79% | 1 without hesitation, 14 with reservations | | 2. Relevance | Can they tell what it solves, and who it's for? | 10/15 | 59% | all with reservations | | 3. Value | Do they actually want it? | 7/15 | 48% | all with reservations | | 4. Differentiation | Is there a reason to pick you over the alternatives? | 3/15 | 33% | all with reservations | **Brand alignment** (a side metric, not one of the four layers) — 9/15, 56% strength (all with reservations). Does the page read like the company you actually are? **Fix first: Value.** Earliest failing layer, walking the sequence in order — not simply the lowest score. --- ## 02 · What to change, layer by layer Ordered worst-first. Specific edits, not a restatement of the score. ### Differentiation **Move usage-based pricing and per-event rates above the fold.** Transparent per-event rates, a real free tier and 'you never have to jump on a quick call with sales' were the only elements readers pointed at as genuinely distinguishing. They are buried at the very bottom, below a duplicated 18-item tool list. Surface the headline rates and the no-sales-call promise in the hero area so the strongest reason to choose is the first thing a comparing reader sees. *effort medium · impact high · tested against Give a reason to choose you* **Say what the context warehouse does that separate tools cannot.** 'All your data, working together' and 'you should be operating with the full context' could be said by any analytics vendor. The actual argument — an AI agent that has replays, flags, experiments and warehouse data in one store can diagnose a bug a bolt-on agent cannot — is never stated. Rewrite the section heading and opening line to make that comparison explicit. *effort medium · impact high · tested against Concrete over abstract* **Replace the duplicated 18-tool list with grouped, outcome-labelled capabilities.** 'Built-in tools for your agents' lists Product Analytics through No-code A/B Testing twice with no indication of what any of them lets the buyer do. Cut the duplication and group them under two or three outcome lines — what the agent can see, what it can test, what it can ship — so scope reads as a coherent advantage rather than a feature dump. *effort medium · impact medium · tested against Tie the feature to the outcome* ### Value **Add one named customer story with a linked merged PR.** There is a logo wall captioned 'Yes they actually use us' but no story attached to it. Readers specifically wanted a named team plus a clickable merged pull request. Add a short block near the Inbox section: team name, the bug, the PR PostHog opened, whether it shipped, and time saved. That converts the logos from decoration into evidence. *effort high · impact high · tested against Proof next to the claim* **Put a merge-acceptance number beside the auto-PR claim.** 'Diagnoses problems, fixes bugs, and generates pull requests' is asserted and never substantiated anywhere on the page. Readers said the value is real if the claim holds, and asked for the share of AI-filed PRs that get merged, typical time from report to PR, and the class of bugs covered. Put one such figure inline under the hero claim, sourced to a period and a customer set. *effort medium · impact high · tested against Proof next to the claim* **Cut 'self-driving mode' and '500,000+ teams' or source them.** Both lines were read as trust-killers: 'self-driving mode' is an undefined internal metaphor that overclaims autonomy the page never demonstrates, and '500,000+ teams' is an unattributed round number. Replace the H1 metaphor with what the product literally does — diagnose bugs and open the pull request — and either footnote the teams figure with a definition of 'team' or drop it. *effort low · impact medium · tested against Specifics beat superlatives* ### Relevance **Replace the Slack broken-link demo with a production bug example.** The one worked example on the page is an AI fixing a dead localhost link in a handbook page. Readers treated this as evidence the product only handles trivia, not the production bugs they actually triage. Swap the thread for a real defect — a checkout error spike traced to a null-check regression, with the resulting PR — so the demo matches the claim 'diagnoses problems, fixes bugs'. *effort medium · impact high · tested against Concrete over abstract* **State who the product is for in the hero subhead.** The page never says who it's built for — readers had to infer audience from the logo wall, and came away with contradictory guesses (seed-stage startups vs. large orgs). Add a line directly under the H1 naming role and situation, e.g. 'For product engineering teams who own their own analytics — no data team required.' That single line settles the size and function question the logos currently leave open. *effort low · impact high · tested against Name the audience* **Name the problem before the 'self-driving mode' promise.** The page opens on the answer with no statement of the pain. Precede the hero claim with the reality the buyer feels — bugs found in session replays that sit in a backlog while engineers hand-reproduce them, triage eating the sprint. Then 'PostHog diagnoses it and opens the PR' lands as a response rather than a boast. *effort low · impact medium · tested against Problem before solution* ### Clarity **Front-load the H1 with what PostHog actually does.** 'Shift your product into self-driving mode' spends the most-read line on a metaphor, and the concrete claim — automatically diagnoses problems, fixes bugs, generates pull requests — only appears two paragraphs down. Promote that into the headline so a scanning reader gets the offer in the first three words, and let the AI capability read as part of the product rather than a layer bolted onto analytics. *effort low · impact medium · tested against Front-load the meaning* ### Brand alignment (side metric) **Add an enterprise-substance line to the self-serve pricing section.** The playful, self-serve voice reads as authentic but signals a startup-only motion, and senior buyers at mid-sized companies did not see themselves in it. Inside the pricing block, next to '97% of users pay us $0', add a concrete line about what scale looks like — event volumes handled, data residency, SSO, SLA — in the same plain voice. Keep the humour; add the substance under it. *effort low · impact medium · tested against Answer the live objection* **Reconcile the conflicting '97%' and '98%' free-usage figures.** The hero says '97% of users pay us $0' and the pricing section says '98% of our customers use PostHog for free'. Two different numbers for the same claim on one page invites doubt about every other figure, including the AI claims. Pick one, define whether it counts users or accounts, and use it in both places. *effort low · impact medium · tested against Specifics beat superlatives* --- ## 03 · What is working ### The value of auto-diagnosis and auto-filed PRs is understood and wanted, conditional on… Three respondents said automatic diagnosis and PR filing would cut manual triage and bug-to-fix time, and stated the value is real if the claims hold. Each attached an explicit condition: proven autonomous merges, named customer proof, or before/after metrics. > bugs getting auto-diagnosed and real PRs filed off usage data without me having to prompt it — that would take a chunk of the grunt work off my plate and off my team's plate: less manual triage, less "who's going to pick up this bug ticket," faster time from "customer hit an error" to "fix is in review." > > — Principal Product Engineer, Software Development, 201-500 > If it worked as promised, it'd take manual bug triage off my plate — the Slack example of tagging @PostHog to find and fix a broken link, or the Inbox "clustering findings into researched reports" so my team just reviews PRs instead of chasing issues, would genuinely cut grunt work. > > — Senior Product Engineer, Software Development, 201-500 > A named customer our size showing the auto-PR workflow actually shipped fixes safely in a real codebase — with a before/after on triage time and how many of those PRs needed human rework > > — Product Engineer, Software Development, 201-500 ### Transparent usage-based pricing with per-event rates is the one thing respondents named… Five respondents independently pointed to the pricing table — concrete per-event rates and a free tier — as a rare, comparison-friendly differentiator that lets them model cost without a sales call and avoid lock-in. This was the most consistently positive element on the page. > "$0.00005/event" with a 1M/mo free tier is concrete and comparable, unlike most vendors who hide behind "contact sales." That's a real reason to shortlist it. > > — Product Engineer, Technology, 11-50 > The usage-based pricing table is the one concrete thing that could tip me toward PostHog over a competitor — "1 million events/mo free, $0.00005/event" is specific and lets me actually model cost against our current tool, versus every other analytics vendor hiding behind "book a demo." > > — Senior Product Engineer, Startups, 51-200 > The usage-based pricing table is the one thing that would actually pull me toward PostHog over a competitor on this page — "$0.00005/event" with a stated 1M free tier and "98% of our customers use PostHog for free" is concrete and checkable, unlike almost everything else on the page > > — VP of Product Engineering, SaaS, 501-1000 > the pricing table — "$0.00005/event," "1 million events/mo free," "98% of our customers use PostHog for free." That's concrete, checkable, and tells me they're not going to trap me in a sales call to find out what this costs at our volume > > — Principal Product Engineer, Software Development, 201-500 --- ## 04 · What the personas said ### The broken-hyperlink Slack demo is read as a toy example that disproves the… Respondents repeatedly singled out the Slack demo of an AI fixing a dead hyperlink as the only concrete evidence offered, and said a trivial link fix does not demonstrate handling real production bugs. Eight points across clarity, relevance, value and differentiation treat this demo as actively undermining credibility rather than supporting it. > If it actually diagnosed and PR'd real bugs unprompted, that's meaningful — it'd cut down triage time that currently eats into our custom logging workflow. But the only proof shown is a broken hyperlink getting fixed, which isn't a bug in the sense I care about (race conditions, data pipeline breaks, whatever). > > — Product Engineer, Technology, 11-50 > the Slack example with Ian Vanagas fixing a broken doc link is a toy demo, not evidence it handles real production bugs > > — Product Engineer, Technology, 11-50 > The Slack demo with the broken link fix was the one bit that made that concrete for me; everything else (the "self-driving" framing) was fluffier marketing talk I'd want a real case study to back up. > > — Senior Product Engineer, Startups, 51-200 > fixing a broken doc link is a trivial diagnostic task, not proof it can handle real production bugs across a codebase > > — Product Engineer, Startups, 51-200 > the Slack screenshot with a fake-looking bot fixing a broken link isn't proof, it's a mockup > > — Principal Product Engineer, Software Development, 201-500 > The usage-based pricing table is the one thing that could actually tip a shortlist decision — "$0.00005/event" with a 1M event free tier is a concrete, checkable number I can model against our current spend, unlike most of this page. But it doesn't rule anything in on its own since competitors publish similar tables. > > — Senior Product Engineer, Software Development, 201-500 > Show me a real, messy production bug — not a dead link — where the agent diagnosed root cause and shipped a merged PR with minimal human rework; give me that with a number attached (e.g. hours saved or % of PRs merged as-is) and I'd book the call. > > — Principal Product Engineer, SaaS, 501-1000 > I'd need to know mergeable-PR rate on a codebase our size, not a docs typo, before I'd take a meeting; the broken-link demo is a toy example, and nothing on the page tells me this holds up at 500-1000 headcount scale > > — Engineering Manager, SaaS, 501-1000 ### The AI layer reads as bolted onto an analytics product, and the core value proposition… Respondents described the core product as analytics infrastructure with an AI ops layer on top rather than a coherent single offering, with one calling the AI-fixes-bugs claim 'bolted on'. Another said the value proposition required scrolling to reach before the AI diagnosis claim became clear. > The problem it claims to solve is buried under the tagline — "Shift your product into self-driving mode" tells me nothing, and I had to scroll to the "Ask PostHog anything" and Slack-screenshot section to actually get it > > — Principal Product Engineer, Software Development, 201-500 > the "self-driving" AI-fixes-bugs pitch feels like a newer layer on top rather than the core product, and I'd want a real case study showing the AI actually shipped a correct PR unsupervised before I believed that part. > > — VP of Product Engineering, SaaS, 501-1000 > call it "product analytics platform with an AI ops layer." The pricing table (per-event, per-recording, per-request costs) tells me it's still fundamentally analytics infrastructure > > — Principal Product Engineer, Software Development, 201-500 ### Who the product is for is inferred from logos rather than stated, and the signals conflict Respondents could not tell the target company size or industry from the page and said audience had to be guessed from logos. Some read the positioning and free-tier limits as tuned for startups rather than enterprise scale, while another read it as targeting larger orgs, and one saw no evidence of fit at 200-500 person scale without a data team. > But the "who" — company size, team structure — is inferred, not stated; there's no "for startups" or "for teams of X" framing, just logos and "500,000+ teams," which is too vague > > — Senior Product Engineer, Startups, 51-200 > 98% of our customers use PostHog for free" and the small free-tier ceilings (5,000 recordings/mo) tell me their pricing and support model is built around small teams, not a 500-1000 headcount org > > — Engineering Manager, SaaS, 501-1000 > the audience is right, the evidence that it works at my scale isn't there yet; I'd want a named 200-500 person eng team saying this caught and fixed a real production bug > > — Principal Product Engineer, Software Development, 201-500 > there's no size or industry signal — "500,000+ teams" is the only scale reference and it's unsourced, so I can't tell if this is built for a 200-person shop like us or mainly proven out on scrappy startups. > > — Senior Product Engineer, Software Development, 201-500 > the AI-agent pitch and the "context warehouse" language assume you already have complex data pipelines and Slack workflows, not a T11-50 team on custom logging. > > — Engineering Manager, Technology, 11-50 ### The AI bug-diagnosis and auto-PR claims arrive with no metrics, case study or named… Respondents said the central AI claim lacks quantified scope, merge-acceptance rates, success metrics, sourced proof or a verifiable customer story. Several asked specifically for a named team and a clickable merged PR, and one called unverified figures like '500k teams' and 'self-driving mode' trust-killing. > A verified merge-acceptance rate from a real customer at our scale — something like "X% of AI-generated PRs for error-tracking issues were merged without material edits over N weeks." Give me that one number with a named source and I'd pilot it; without it, it's just a pitch. > > — VP of Product Engineering, SaaS, 501-1000 > "Automatically diagnoses," "fixes bugs," and "generates pull requests" — none of those are quantified or scoped, so I can't tell if that means catching a null-pointer typo or actually resolving a logic bug in production code. > > — VP of Product Engineering, SaaS, 501-1000 > A verifiable case study from a company our size — named team, real bug, real PR that merged, with a link I can click myself, not a curated screenshot. > > — Principal Product Engineer, Software Development, 201-500 > Everything else — "500,000+ teams," the Slack screenshot fixing a broken link, "self-driving mode" — is exactly the kind of unverified claim that would make me rule a tool out, not in, because it's the same "trust us" packaging that burned me last time. > > — Principal Product Engineer, Software Development, 201-500 > A named customer our size showing the auto-PR workflow actually shipped fixes safely in a real codebase — with a before/after on triage time and how many of those PRs needed human rework > > — Product Engineer, Software Development, 201-500 > I'd need a concrete example at our scale — a small team's actual bug volume, what the PR success/rejection rate looked like, and how much engineer review time it saved versus just doing it manually. > > — Engineering Manager, Technology, 11-50 > The "500,000+ teams" and "98% use it free" numbers are unsourced, so I'd want named case studies before believing the AI-fixes-your-bugs pitch actually works in production, not just on a fake Slack screenshot. > > — Senior Product Engineer, Software Development, 201-500 ### The developer-first, self-serve tone lands as authentic but reads as PLG rather than… Respondents consistently described the brand as engineer-focused, humorous and self-serve, and several said it aligns well with an IC developer audience. The same respondents flagged that this tone signals a PLG motion without enterprise substance, and two said it skews toward younger founders and startup hype rather than VPs at mid-sized companies. > Feels like a mid-size, developer-first company that's grown past its early "quirky startup" phase but still leans hard on that voice — the "Shameless CTA," "Notendorsed by Kim K," fake floppy disk Rickroll bit. That's a company confident enough in its product-led growth to spend copy space on jokes instead of a sales pitch > > — Product Engineer, Technology, 11-50 > The tone — "Bedtime reading," the fake shopping-cart gag, "Notendorsed by Kim K," the Rickroll floppy disk joke — is clearly written for a technical, in-the-weeds engineer who'll find that funny, and it does land for someone like me who reads fast and likes that they're not managing me with corporate fluff. But it's not written for a 500-1000 headcount buyer specifically > > — Engineering Manager, SaaS, 501-1000 > the jokey packaging (the fake floppy disk Rickroll story, "self-driving mode") reads more like it's aimed at a younger, scrappier founder-engineer than at a VP at a 200-500 person shop who's been burned before and needs a case study, not a bit. > > — Principal Product Engineer, Software Development, 201-500 > the "self-driving" hero claim swings into hype-speak that a startup CEO writes at 11pm, which is a bit at odds with the otherwise credible, numbers-first pricing section > > — Product Engineer, Startups, 51-200 > The tone absolutely feels written for someone like me — the Slack screenshot with a broken link, the "npx @posthog/wizard" terminal option, the snark in "Digital download," "Notendorsed by Kim K," "1 left at this price!!" — that's an engineer-to-engineer voice, funny and self-aware, not a VP-of-whatever deck. > > — Principal Product Engineer, SaaS, 501-1000 > the "500,000+ teams," the honest "98% of our customers use PostHog for free," and the flippant "eco-friendly digital download / Notendorsed by Kim K" bit at the bottom all scream engineers who sell to other engineers > > — VP of Product Engineering, Startups, 51-200 --- ## 05 · The hardest read An adversarial pass over the findings. Every claim below was checked against the panel's own answers; unsupported ones were dropped. - **The page's only concrete proof point is the thing most likely to sink the sale.** *(high)* Seven of 15 respondents singled out the Slack broken-hyperlink demo as the sole piece of evidence offered, and eight separate points across clarity, relevance, value and differentiation treat it as undermining credibility. A demo that reads as a toy example is worse than no demo: it sets the ceiling of perceived capability at 'fixes dead links' while the copy claims production bug diagnosis. Five more respondents independently noted the AI claim has no metrics, case study or named customer to… - **Demand for the product exists and the page fails to convert it.** *(high)* Three respondents said auto-diagnosis and auto-filed PRs would cut triage and bug-to-fix time and that the value is real — but every one attached a condition: proven autonomous merges, a named customer, or before/after metrics. Five respondents separately named the absence of exactly those artifacts, with specific asks for a named team and a clickable merged PR. The page created qualified want and then withheld the single class of asset needed to close it. - **The page cannot state who it is for, so readers assign themselves out of it.** *(high)* Five of 15 respondents could not determine target company size or industry and had to guess from customer logos, and those guesses actively conflicted — some read startup positioning from free-tier limits, another read enterprise, and one at 200-500 people saw no evidence of fit without a data team. When the audience signal is inferred rather than stated, contradictory reads are the default outcome and the page loses buyers who otherwise qualify. - **The tone is doing audience-selection work that contradicts the deal size the page is chasing.** *(high)* Six respondents read the brand as authentic developer-first and self-serve, and the same respondents flagged it as signalling PLG without enterprise substance, with two saying it skews toward younger founders and startup hype rather than VPs at mid-sized companies. Combined with five respondents unable to identify the target segment, the voice is the loudest audience signal on the page — and it is pointing away from budget holders. - **Pricing is the only differentiator the page earned, and it differentiates on cheapness rather than capability.** *(medium)* Five respondents independently named the transparent per-event pricing table and free tier as the standout — the most consistently positive element on the page. Nothing else was named as a differentiator. Meanwhile seven respondents dismissed the capability demo and five found the AI claims unproven. The page is winning on the axis competitors can match in an afternoon and losing on the one it built the product around. - **The product reads as two products stapled together, which is why no single value proposition survives the page.** *(medium)* Respondents described analytics infrastructure with an AI ops layer 'bolted on' rather than one coherent offering, and one had to scroll before the AI diagnosis claim became clear. This structural incoherence compounds the audience problem five respondents reported: a reader cannot self-identify as the buyer when the page has not decided what it sells. --- ## 06 · Who answered | # | Role | Industry | Company size | | --- | --- | --- | --- | | 1 | VP of Product Engineering | SaaS | 501-1000 | | 2 | Product Engineer | Technology | 11-50 | | 3 | Senior Product Engineer | Startups | 51-200 | | 4 | Principal Product Engineer | Software Development | 201-500 | | 5 | Engineering Manager | SaaS | 501-1000 | | 6 | VP of Product Engineering | Technology | 11-50 | | 7 | Product Engineer | Startups | 51-200 | | 8 | Senior Product Engineer | Software Development | 201-500 | | 9 | Principal Product Engineer | SaaS | 501-1000 | | 10 | Engineering Manager | Technology | 11-50 | | 11 | VP of Product Engineering | Startups | 51-200 | | 12 | Product Engineer | Software Development | 201-500 | | 13 | Senior Product Engineer | SaaS | 501-1000 | | 14 | Principal Product Engineer | Technology | 11-50 | | 15 | Engineering Manager | Startups | 51-200 | --- ## 07 · Before you act on this The methodology is real, and the critique is directional. What a simulated persona cannot have is a live budget, a renewal coming up, or a boss asking about this quarter. **Validate anything you're betting on with real ICPs who are actually in-market.** Being wrong is more expensive than you think. Finding out is cheaper than you'd guess. Wynter runs message testing with verified B2B professionals — trusted by HubSpot, RingCentral, Shopify, Cognism, Paddle, Veeam, Rippling and Miro. This report is kept for 60 days from 2026-08-20, then deleted along with the personas and their answers.