The Pull
PostHog intentaba conectar el feedback de usuarios con el trabajo de ingeniería que ya estaba ocurriendo en GitHub.
Su configuración actual les bloqueaba porque el feedback vivía en llamadas, incidencias de GitHub, tickets de Zendesk, hilos de Slack, correos electrónicos y publicaciones en redes sociales.
BuildBetter lo desbloquea adjuntando contexto del cliente respaldado por la fuente a las incidencias de GitHub para que los ingenieros no tengan que pedirle a alguien que reconstruya la historia a mano.
The Catalyst
El flujo es concreto: una incidencia de GitHub debe llevar la evidencia del cliente que hay detrás.
“Tener incidencias vinculadas automáticamente en GitHub significa que nuestros ingenieros tienen acceso inmediato a contexto detallado. Esto hizo que la colaboración y la priorización fueran directas y efectivas.”
— Anna Szell, PostHog
Before BuildBetter
PostHog tenía mucho feedback de usuarios, pero vivía en demasiados lugares:
- incidencias de GitHub,
- tickets de Zendesk,
- hilos de Slack,
- correo electrónico,
- publicaciones en redes sociales,
- conversaciones de ventas,
- conversaciones de producto,
- llamadas de investigación.
Ingenieros y PM necesitaban el “por qué” detrás de una incidencia sin tener que buscar en esas fuentes.
The Blocker
El trabajo no estaba recopilando más feedback.
El obstáculo era conectar el feedback con el objeto de ingeniería que importaba: la incidencia de GitHub.
Si el contexto del cliente se queda en tickets, llamadas, Slack y notas, la ingeniería ve una incidencia vaga y el producto tiene que explicar manualmente por qué importa.
“Estábamos invirtiendo incontables horas ordenando manualmente llamadas y feedback del cliente. Fue un gran drenaje para nuestra productividad y moral.”
— Anna Szell, PostHog
El flujo de trabajo de BuildBetter
Customer feedback from calls, tickets, Slack, email, social, GitHub
↓
BuildBetter signal extraction
↓
Source-backed context
↓
Linked GitHub issue
↓
Engineer or PM acts with customer evidence attached
What Changed
- producto e ingeniería pueden ver contexto del cliente en las incidencias,
- los ingenieros no tienen que perseguir a los PM para el contexto,
- el producto no tiene que reconstruir manualmente el historial para cada ticket,
- el feedback puede informar la priorización dentro de los sistemas donde el trabajo ya ocurre.
“BuildBetter se está convirtiendo en nuestra herramienta principal para la planificación estratégica. Nos permite mantenernos por delante alineando directamente las decisiones de producto con el feedback de los clientes.”
— Anna Szell, PostHog