Engineers own feature analytics with PostHog
Abdallah Absi, co-founder and CEO of Village, on using PostHog for product analytics
This setup turns analytics from a separate product manager task into part of shipping code. At Village, the engineer who builds a feature also defines the event, makes the chart, and watches usage week by week, so the same person sees whether users adopt it, where they drop off, and what to change next. That creates a much tighter build, measure, iterate loop than handing raw event data to another team later.
-
Village is not just logging clicks. Engineers create a PostHog insight for each launch, usually a trend chart or funnel, then use session replay to inspect specific users who hit an event and see where they got stuck. That means debugging product adoption with actual behavior, not just aggregate counts.
-
The practical comparison is against the older stack of Segment plus Mixpanel or Heap. In that model, one tool collects events, another visualizes them, and teams often have to plan instrumentation in advance. PostHog compresses capture, charts, funnels, replay, and experiments into one workflow, which is why it feels faster for small teams.
-
This matters even more at Village because the product itself is an evolving workflow engine for warm introductions in fundraising, sales, and recruiting. When a team is constantly testing search flows, invite loops, and conversion steps, owning the metric at feature level helps engineers make local product decisions without waiting for a separate analytics owner.
The next step is that tracking stops being feature by feature and becomes system wide product steering. As PostHog keeps expanding across analytics, flags, experiments, and replay, startups like Village can give engineers direct ownership not just of launch quality, but of growth loops, retention, and monetization paths across the whole product.