Cómo construir el caso interno para invertir en una herramienta de analítica

En el artículo 20 cerramos el debate del cuándo invertir y en el 21 el de qué herramienta elegir. Si has llegado hasta aquí, ya tienes el momento y el candidato. Te queda la parte que casi todos los responsables de producto creemos que es fácil: convencer a tu director financiero, al comité o al fundador de que firme la factura.

Y este caso tiene una particularidad que lo hace más difícil que cualquiera de los que defendiste en el artículo 19: la herramienta de analítica no genera ingresos por sí misma.

Quédate con:

El caso para una herramienta de analítica es un caso habilitador, no de resultado directo. No defiendes que la herramienta vaya a subir los ingresos recurrentes anuales. Defiendes que sin ella vas a decidir peor las próximas grandes decisiones del año.

Prometer esta herramienta nos va a aumentar la conversión es un error clásico. La herramienta no es la causa de la mejora, es el instrumento de medida que permite a producto trabajar sobre la causa con más criterio. Confundir las dos cosas es la forma más rápida de perder credibilidad en el comité.

Vamos a ver por qué este caso es distinto, cómo adaptar la plantilla del artículo 19, cómo conseguir cifras que aguanten una repregunta, las cuatro objeciones que casi seguro te van a hacer y el caso de Algora, que ya tiene herramienta elegida y le toca defender la compra.

Por qué este caso es distinto

Tres diferencias con un caso de producto normal.

Primero, el beneficio es indirecto. En el 19 la métrica era del producto (adopción, retención) y podías enseñar el valor actual y el esperado. Aquí la herramienta solo hace posible medir otras iniciativas. Su beneficio aparece en la calidad de las decisiones, y eso no sale en ningún cuadro de mando.

Segundo, el coste de no hacer es acumulativo. Si no construyes una funcionalidad, la pierdes y ya está. Si no instrumentas, cada trimestre pierdes un histórico que no se puede reconstruir (lo vimos en el artículo 20). Es un coste invisible, pero real.

Tercero, los beneficiarios son varios, y eso ayuda. La usan producto, éxito del cliente, marketing y crecimiento. Puedes llevar al comité apoyos cruzados: el equipo de éxito del cliente dice esto me quita las preguntas pendientes sobre clientes y marketing dice me deja segmentar con eventos reales. Conseguir esos apoyos antes de la reunión multiplica la probabilidad de que salga adelante.

A quién tienes que convencer

Antes de preparar nada, haz un mapa de apoyos. Hay dos tipos de interesados y se tratan de forma distinta:

• Compradores: Líderes que aprueban o pueden frenar la compra: dirección de producto, ingeniería, seguridad, legal, datos y, al final, finanzas. Tendrán preguntas y objeciones, así que llévalos contigo desde el principio, no el día del comité.
• Usuarios: Los equipos que usarán la herramienta para trabajar mejor: producto, diseño, éxito del cliente y marketing. Si no quieren la herramienta, el caso no se sostiene. Necesitas que entiendan qué ganan.

Y una pregunta de partida para ambos: ¿qué valor aporta esto al negocio? Cualquier compra de software tiene que hacer al menos una de tres cosas: aumentar ingresos, reducir costes o mitigar riesgo. Es la misma familia del artículo 18, y te toca elegir cuál pesa más para quien decide.

• Ingresos: entender cómo usan el producto los clientes permite darles más de lo que quieren y retenerlos. Y ver qué acciones llevan a conversiones o ampliaciones permite empujar a más usuarios hacia ellas.
• Coste: sustituye trabajo manual y lento. Si hoy un analista o un ingeniero arma cada informe a mano, la herramienta libera esas horas. Y detectar fricción reduce solicitudes de soporte.
• Riesgo: sin datos se decide por intuición o por quien habla más fuerte. Con ellos baja el riesgo de construir lo que no toca.

Aquí viene el matiz: no hace falta defender las tres, elige una o dos, las que más le importen a tu comité.

La plantilla del 19, adaptada

La plantilla de una página del artículo 19 (Resumen general, Datos de soporte, Información adicional) sigue valiendo. Cambia lo que hay dentro de cada parte.

Parte 1: Resumen general

• Para quién. En lugar de un segmento de clientes, los usuarios internos (producto, éxito del cliente, marketing, ventas) y los compradores que tienen que aprobarlo. Ojo con la firma fácil: si todos dicen que sí pero nadie asume nada, el apoyo no vale. Una firma cuenta solo si incluye tres líneas: la pregunta concreta que esa área va a contestar, la decisión que tomará con la respuesta y el uso que se compromete a hacer (cuántas personas, cuántas consultas al mes).
• El dolor. No es de un usuario externo, es del propio equipo: las cinco preguntas que hoy solo podéis contestar bloqueando durante días al equipo de datos, o aplazando hasta el siguiente ciclo de planificación. Conecta con el criterio 1 del artículo 21.
• Familia principal. Casi siempre se defiende mejor por coste (horas del equipo de datos, decisiones más lentas) y riesgo (decidir a ciegas, no poder defender una inversión), no por ingresos. Apóyate en las tres familias del artículo sobre conectar producto y negocio.
• Inversión anual. Licencia, implementación inicial y horas de mantenimiento del equipo interno. Que esté completa. Si pones solo la licencia, pierdes credibilidad.

Parte 2: Datos de soporte

Aquí los datos cuantitativos no son los del producto, sino los del estado actual de la toma de decisiones: cuánto cuesta hoy obtener una respuesta que la herramienta resolvería de forma autónoma y qué se quedó sin medir por ese coste.

• Cuantitativo: horas mensuales del equipo de datos dedicadas a preguntas puntuales de producto, número de preguntas que se aplazaron, número de decisiones que se tomaron sin base previa.
• Cualitativo: palabras textuales de tres a cinco responsables internos que explican qué necesitan medir y por qué hoy no pueden. Llevo seis meses sin poder defender X porque no tengo el dato. Es la misma combinación cuantitativo + cualitativo del artículo 4.

Parte 3: Información adicional

• Criterios de éxito habilitadores, no de resultado. No prometas la retención neta de ingresos sube un 3%. Promete en seis meses tendremos cohortes a 90 días instrumentadas para tres iniciativas concretas. Las métricas de resultado son del caso de cada iniciativa, no de este.
• Plan de adopción explícito. Esta sección no estaba en el artículo 19 y aquí es obligatoria, porque el riesgo principal de una herramienta no es técnico, es que nadie la use. Cuenta calidad de uso, no solo cantidad: 10 usuarios activos a la semana no dice nada si son 10 mirando el mismo cuadro de mando.
• Alternativas evaluadas con su coste real. Las dos que te van a proponer si no las cierras tú antes: seguir con SQL artesanal (la latencia mata la cultura analítica, artículo 20) y no hacer nada durante 12 meses.

Un ejercicio para empezar: la hoja de resultados de negocio

Antes de escribir el caso, rellena una hoja con una fila por cada resultado que esperas de la herramienta. Cinco columnas y una etiqueta:

1. Resultado de negocio que buscas.
2. Dolor actual relacionado con ese resultado.
3. Impacto cuantificado de ese dolor (horas, euros, decisiones aplazadas).
4. Referencias del sector, si las hay. Si no tienes ninguna fiable, déjala en blanco y no la inventes.
5. Impacto potencial de resolverlo.
6. Etiqueta: ingresos, coste o riesgo.

Úsala como punto de partida de la conversación con tu equipo y como esqueleto del caso. Una fila bien rellenada pesa más que diez frases generales.

Dos filas de ejemplo con Algora:

• Dejar de depender de la cola del equipo de datos (coste). Dolor: cada cohorte a 90 días cuesta días de SQL. Impacto cuantificado: 32 horas al mes, unos 22.000€ al año (cifras ilustrativas). Impacto potencial: recuperar la mayor parte de esas horas.
• Decidir las tres iniciativas con base previa (riesgo). Dolor: se ejecutan sin referencia o se aplazan. Impacto cuantificado: tres iniciativas sin referencia inicial. Impacto potencial: poder demostrar su impacto con datos comparables.

Cómo conseguir cifras que aguanten una repregunta

La primera pregunta de cualquier comité con experiencia es: esas 32 horas mensuales, ¿están medidas o estimadas? Si la respuesta es las he calculado esta semana preguntando al responsable de datos, el caso se hunde en treinta segundos.

Tres reglas para que las cifras se sostengan:

1. Periodo de muestreo formal. En lugar de estimar de memoria, abre un periodo de medición de cuatro a seis semanas antes del comité. Pide al equipo de datos que etiquete cada petición entrante como puntual de producto u otro. Las horas que salgan de ahí son auditables.
2. Categorización trazable. Cada cifra tiene que poder rastrearse hasta la solicitud, el hilo o la entrada de calendario que la genera. 47 peticiones en 90 días solo vale si puedes filtrar el tablero y enseñar las 47.
3. Tarifa interna conservadora. Si conviertes horas en euros, usa una tarifa interna validada por finanzas (coste cargado por hora), no la de un consultor externo. La interna casi no se discute. La de mercado abre un debate que no necesitas.

Las cuatro objeciones y cómo prepararlas

Objeción 1: El equipo de datos casi podría hacer esto con SQL

Es la versión técnica del no lo necesitamos y la que cierra el artículo 21. Y tiene parte de razón: casi todo se puede hacer con SQL.

Antídoto: lleva las horas concretas que el equipo de datos dedicó el último trimestre a consultas puntuales de producto y proyecta cuántas serán cuando producto crezca. El argumento no es SQL no puede. Es SQL puede, pero cada pregunta nueva cuesta una cola, y la cola mata la exploración.

Hay una variante más sofisticada, la del director financiero que pregunta: ¿habéis intentado optimizar el proceso antes de gastar 24.000€? Es legítima. Respuesta: las preguntas de producto son secuenciales, la siguiente depende de la respuesta anterior, y una cola semanal mata justo la parte donde se descubren las preguntas que no sabías que querías hacer. Si lo habéis probado, lleva las cifras. Si no, dilo y propón un periodo de medición previo.

Objeción 2: El ROI no está claro

El director financiero tiene razón: el ROI directo no está claro y no lo va a estar. Respuesta preparada: Correcto, es un caso habilitador. El retorno está en los casos de negocio que esta herramienta nos permite defender, no en la herramienta. La pregunta para el comité no es cuánto va a generar, sino qué ciclo de planificación queremos: uno donde defendemos cada iniciativa con base previa o uno donde las defendemos con anécdotas.

Objeción 3: Mejor esperamos al año que viene

Es la más peligrosa porque no suena a no, suena a todavía no.

Antídoto: esperar doce meses no es gratis, es un año de histórico que no se recupera. Si el comité insiste, propón un piloto de tres a seis meses acotado al plan gratuito o al tramo mínimo de la herramienta ya elegida, con dos cuidados:

1. Define el éxito con métricas que se trasladen al plan completo (responsables de producto que crean consultas propias, decisiones documentadas con datos), no con las que dependan del volumen del plan gratuito, como eventos procesados.
2. Acepta el límite. Si el plan gratuito está capado en asientos, eventos o retención, el piloto demuestra adopción y uso, no escalabilidad.

Es un entorno controlado, reduce el riesgo financiero inicial y empieza a capturar histórico.

Objeción 4: La compramos y luego nadie la usa

Es la más legítima, y suele venir con cicatrices reales: el sistema de gestión de clientes abandonado, la herramienta de inteligencia de negocio llena de polvo.

Antídoto: no aprobamos una herramienta, aprobamos una herramienta más un plan de adopción. Y enseñas la sección de adopción de la plantilla: usuarios esperados por rol y una métrica habilitadora del tipo 10 personas usando la herramienta cada semana en el mes 3. Esta objeción también te recuerda por qué el criterio 2 del artículo 21 (curva de aprendizaje para no técnicos) pesaba tanto: si la herramienta es difícil, esta objeción no tiene buena respuesta.

El caso de Algora: cómo defiende Marta la inversión

Volvemos al ejemplo ficticio del curso. Marta, responsable de producto del segmento Enterprise, ya hizo el ejercicio del artículo 21 y la herramienta elegida es PostHog Cloud EU. Ahora tiene que convencer al comité del cuarto trimestre, el mismo que decide el caso de plantillas de contrato del artículo 19.

Algora no parte de cero. Tiene Segment, BigQuery con dbt y un equipo de datos que contesta preguntas de producto con SQL. Funciona, pero cada cohorte a 90 días cuesta días de trabajo y éxito del cliente y marketing no pueden consultar nada por su cuenta. Por eso Marta no pide empezar a medir. Pide dejar de depender de una cola.

Las cifras de este caso son ilustrativas, inventadas para el ejemplo. Los importes de licencia son una simulación para un volumen Enterprise: valídalos con el proveedor antes de llevar nada a tu comité.

Coste del año 1

• Licencia (PostHog Cloud EU, simulada): 24.000€
• Dedicación de Marta (un día por semana durante el tercer trimestre, a tarifa interna): 3.000€
• Apoyo del equipo de datos (unas 15 horas para conectar BigQuery y configurar el modelado): 1.000€
• Formación inicial e instrumentación: 1.000€
• Total: 29.000€

Coste de seguir como ahora

Durante seis semanas, el responsable de datos etiqueta cada petición entrante como puntual de producto. Resultado: 32 horas al mes. A una tarifa interna de 57€/hora, validada por finanzas, son unos 22.000€ al año (32 × 12 × 57 ≈ 21.900).

Fíjate en lo que no dice este número: 22.000€ no cubren los 29.000€ de inversión. Si Marta vendiera el caso solo por las horas ahorradas, el director financiero haría la resta y diría que no sale. Las horas son la mitad de la defensa, la parte auditable. La otra mitad es operativa y no se monetiza.

La formulación que lleva Marta al comité

Podemos seguir midiendo como hasta ahora, pero no con el rigor que van a exigir las próximas tres iniciativas del plan de producto del segmento Enterprise: plantillas de contrato, rediseño de la incorporación de nuevos usuarios y la integración con el sistema de gestión de clientes. Las tres se ejecutarán sin base previa y bloqueando al equipo de datos, o se aplazarán. En el plano auditable, 22.000€ al año en consultas puntuales, medidas en seis semanas de etiquetado. En el plano operativo, tres iniciativas que no podrán demostrar su impacto con datos comparables y un histórico que no se recupera.

Es menos espectacular que prometer un retorno en ingresos recurrentes anuales, pero es coherente con la tesis del artículo: la herramienta no genera el resultado, habilita las condiciones para medirlo, defenderlo y demostrarlo. Es la única promesa que aguanta la primera repregunta del director financiero.

Y un matiz de secuencia: sin el caso de plantillas del artículo 19 ya construido, el caso de la herramienta sería mucho más débil. Una herramienta sin iniciativas detrás parece un gasto. Conectada a decisiones que ya están en el plan de producto, parece infraestructura. Primero ten al menos un caso de producto que la herramienta habilita, después defiende la herramienta como requisito.

Tres trampas comunes

1. Prometer ROI directo en ingresos. El más común y el más caro. En cuanto el comité lee esta herramienta aumentará los ingresos recurrentes anuales en X€, te piden la cadena causal y no la tienes. Si los ingresos recurrentes anuales no llegan, el culpable eres tú, no el modelo.
2. Justificar con métricas técnicas. 200 integraciones, 50 millones de eventos al mes, SOC 2. Al comité no le interesa. Le interesa qué decisiones vas a tomar mejor. El detalle técnico va al anexo o a la conversación con el director de tecnología.
3. Ir sin apoyos cruzados. Si el caso solo lo defiende producto, parece un capricho de producto. Si éxito del cliente, marketing y datos explican qué van a hacer con la herramienta, parece una decisión de empresa.

Resumen rápido

• Tesis: el caso de una herramienta de analítica es habilitador. No prometes resultado, prometes mejores decisiones y medición.
• La plantilla del 19 sigue valiendo, con beneficiarios internos, el dolor de las preguntas sin contestar, coste + riesgo como familia y criterios de éxito habilitadores.
• Plan de adopción obligatorio: el riesgo real es que nadie la use.
• Cifras defendibles: muestreo de cuatro a seis semanas, categorización trazable y tarifa interna conservadora.
• Cuatro objeciones: SQL, ROI, esperar y nadie la usará. Prepara las cuatro antes de entrar.
• Algora: 29.000€ de inversión frente a 22.000€ de coste auditable de seguir igual. Las horas no bastan, y por eso el caso se apoya en las tres iniciativas del plan de producto.
• Tres trampas: ROI directo, métricas técnicas y falta de apoyos cruzados.

Siguiente paso

Si el comité dice que sí, empieza la parte que más equipos hacen mal: arrancar. Quién se encarga, con qué proceso y sobre qué base técnica para que, tres meses después, la herramienta no esté llena de eventos huérfanos. Lo cuento en el último artículo del curso.

Cómo arrancar con analítica en tu equipo: personas, procesos y tecnología →