Cómo construir un caso de negocio de producto con datos

En el artículo anterior vimos cómo conectar producto y negocio con una cadena de tres pasos: funcionalidad → comportamiento → resultado de negocio.

Sabes que cualquier impacto razonable cae en una de tres familias (revenue, cost, risk) y sabes que el negocio no exige certeza, exige rigor.

Ahora llega el documento operativo que va a soportar todo eso cuando entres en una sala de decisión: el caso de negocio de producto (lo que en jerga PM en inglés probablemente llamas product business case).

Quédate con:

Un buen caso de negocio no convence con elocuencia, convence con cadena. Si la cadena producto-comportamiento-negocio no aparece, ningún PowerPoint te salva.

Vamos a ver qué es y qué no es un caso de negocio, las tres preguntas que estructuran cualquiera bien hecho (para quién, qué dolor, qué resultado), una plantilla en una página con sus tres partes y el ejemplo aplicado en el producto ficticio que venimos desarrollando Algora.

Qué es un caso de negocio (y por qué corto le gana a largo)

Un caso de negocio de producto es el documento que describe el «por qué» detrás de una decisión de inversión. No es un PRD, no es un roadmap y no es una presentación de proyecto, es la herramienta de decisión que justifica por qué vale la pena meter recursos en una idea concreta en lugar de en otra.

Hay una regla que conviene entender de entrada y que casi nadie respeta:

Un caso de negocio bueno cabe en una página, si no cabe, probablemente no está claro en tu cabeza. El objetivo no es documentar todo lo que sabes, es documentar todo lo que alguien necesita para decidir.

Un caso largo no es mejor, es más fácil de ignorar, las decisiones de inversión las toma gente con poco tiempo, y cuando se enfrentan a un documento de 30 páginas con apéndices y proyecciones financieras detalladas, lo posponen. Cuando se enfrentan a una página con claridad, deciden.

Forzar a una página obliga a tu propio pensamiento a aclararse, lo que sobra en el papel también sobraba en tu cabeza.

Tres beneficios concretos de un caso de negocio bien hecho:

• Ordena tu propio pensamiento: Escribirlo te obliga a ver qué eslabones de la cadena estás dando por sentados sin tener pruebas.
• Da material defendible a tus stakeholders: Cuando un director de finanzas pregunta «¿y por qué esto y no otra cosa?», tienes una página que responder, no una opinión.
• Documenta la decisión para reviews futuras: En seis meses, cuando alguien pregunte «¿por qué se invirtió aquí?», hay un documento que lo explica con los datos que existían entonces, eso evita reescribir la historia o contarla de nuevo.

Las tres preguntas que estructuran cualquier caso de negocio

Cualquier caso de negocio bien hecho responde a tres preguntas, en este orden. Si te falta una, no es un caso de negocio, es una opinión disfrazada.

1. ¿Para quién construyes?

La pregunta más obvia y la que más equipos fallamos. En B2B necesitas distinguir al menos dos perfiles:

• Quién va a usar la funcionalidad: El agente de reservas, el contable, el analista de marketing, es el que abre el producto cada día.
• Quién va a tomar la decisión de comprar o renovar: El director de operaciones, el CFO, el responsable de área, es el que firma la renovación anual.

A menudo son personas distintas, con prioridades distintas, si construyes solo para el usuario sin pensar en quien firma, tienes una funcionalidad querida y un contrato no renovado. Si construyes solo para quien firma sin pensar en el usuario, tienes una venta cerrada y una adopción del 4%.

En B2C la pregunta cambia de forma pero no de fondo ¿Qué jobs to be done estás resolviendo y a quién? Sin esa claridad, no hay forma de defender prioridades ante nadie.

2. ¿Qué dolor abordas?

Aquí entra la pregunta clásica que separa proyectos serios de caprichos ¿Es aspirina o vitamina?

• Aspirina (Debe tener): Algo que el cliente necesita para hacer su trabajo, cuando no lo tiene, sufre., cuando lo encuentra en otro producto, se cambia.
• Vitamina (Estaría bien tener): Algo que está bien tener, cuando no lo tiene, se las apaña. Cuando lo encuentra en otro producto, lo prueba y vuelve.

Aspirina mueve renovaciones, vitamina mueve impresiones positivas, la mayoría de proyectos defendidos como «imprescindibles» son en realidad vitaminas, y eso explica por qué tantas funcionalidades lanzadas con bombo no mueven retención.

Para distinguirlas, dos métricas: magnitud (cuánto duele) y frecuencia (cada cuánto duele). Una aspirina típica suele ser un dolor frecuente y de magnitud media, una vitamina típica es un dolor esporádico aunque a veces intenso. Cuidado aquí con productos estacionales, como puede ser TaxDown.

Y un aviso que puede evitar muchas decisiones malas: no construyas algo solo porque un cliente importante lo pidió, ni solo porque la competencia lo tiene. La petición no es evidencia de aspirina, la imitación tampoco. Aplicar las dos tácticas del artículo de priorización (presión explícita × evidencia de comportamiento) antes de meterlo en el caso de negocio.

Y una última pregunta, la que que suele hacer cualquier comité: ¿Qué pasa si no hacemos nada durante los próximos 12 meses?

Si la respuesta es «nada importante», probablemente el problema no es prioritario. Si la respuesta es pérdida de ingresos, aumento de costes, más riesgo o una oportunidad relevante desaprovechada, ya tienes un argumento de negocio defendible.

Porque toda inversión compite contra la alternativa de no hacer nada.Si la respuesta es pérdida de clientes, aumento de costes o acumulación de riesgo, estás delante de una aspirina y el caso ya tiene argumento de negocio aunque no muevas un dedo del producto. Esta pregunta es además la que convierte el dolor del usuario en un coste para la empresa, que es justo el puente que el comité necesita oír.

3. ¿Qué resultado esperas?

Aquí conectas la fórmula del artículo anterior: identificar la familia de resultado (revenue, cost, risk) y trazar la linea de funcionalidad → comportamiento → resultado de negocio. Sin esta pregunta cerrada, el caso de negocio es un deseo, no una propuesta de inversión.

Recuerda lo del artículo anterior, un mismo proyecto puede impactar varias familias a la vez. Lo que decides aquí es cuál es la familia principal con la que defiendes la inversión, no la única que toca.

Y un aviso que vale por todo el bloque, los objetivos no son actividades. «Mejorar onboarding» no es un resultado, es un trabajo. Si la pregunta 3 te sale en forma de verbo de acción («mejorar», «facilitar», «rediseñar»), no has contestado todavía. La pregunta solo está cerrada cuando puedes nombrar una métrica, un punto de partida y un punto de llegada.

La columna de la izquierda describe actividades, la de la derecha describe resultados.

Y los comités no aprueban actividades, aprueban resultados esperados, si tu respuesta a la pregunta 3 todavía suena como la columna de la izquierda, no has terminado de cerrar el caso de negocio. Vuelve atrás y concreta qué métrica quieres mover, desde qué punto y hasta dónde.

La plantilla en una página

Una vez tienes las tres preguntas resueltas, las pones en un formato concreto. Esta es la plantilla que uso y que cabe en una página A4 cómodamente.

Tres partes:

Parte 1 · Overview: El qué y el porqué en cuatro líneas:

• Problema en una frase, sin jerga ni adjetivos.
• Resultado de negocio buscado, con la familia explícita (revenue, cost, risk).
• Resultado de producto que esperas mover (la métrica de comportamiento).
• Cadena entre uno y otro, en lenguaje natural.

Parte 2 · Datos de soporte: El «y por qué creo que va a funcionar»:

• Cuantitativos: Lo que dice tu herramienta de analítica, adopción, retención, segmentación, abandonos en el funnel.
• Cualitativos: Lo que dicen tus clientes, entrevistas, encuestas in-app, tickets de soporte.

Las dos columnas son innegociables, un caso de negocio con solo datos cuantitativos suena seco y le falta el «por qué» del comportamiento. Uno con solo cualitativos suena anecdótico y le falta el rigor del comportamiento agregado, recuerda que los datos te dicen qué hacen, las conversaciones te dicen por qué lo hacen.

Parte 3 · Información adicional: El «cómo»:

• Alcance del trabajo: Quién, cuánto tiempo, qué dependencias técnicas.
• Criterios de éxito con plazo concreto: «Adopción de plantillas sube del 28% al 40% en 90 días», no «mejorar la adopción».
• Hitos de entrega (milestones) para revisar la dirección a medio camino.
• Riesgos y dependencias que pueden tumbar el proyecto.

Esa última sección es la que distingue un caso de negocio honesto de uno construido para venderse a sí mismo: el caso bueno menciona sus propios riesgos, no los esconde.

El caso de Algora aplicado: plantillas de contrato

Vuelvo al hilo y construyo el caso de negocio completo para la iniciativa que Algora viene cocinando desde el bloque IV: invertir en el flujo de plantillas de contrato.

Las tres preguntas resueltas:

¿Para quién construyes? Cuentas Enterprise (segmento prioritario del año). Dos perfiles relevantes: agentes de contratos (uso diario, 4-5 por cuenta) y director jurídico o responsable de operaciones (firma la renovación anual).

¿Qué dolor abordas? Redactar contratos desde cero cada vez consume 2-3 horas por contrato según las entrevistas a power users, y los re-trabajos por inconsistencias entre versiones generan 1 hora adicional por iteración. En cuentas que cierran 30 contratos al mes, son 90-100 horas mensuales de trabajo de bajo valor. Aspirina clara: cada Enterprise lo sufre cada semana.

¿Qué resultado esperas? Familia principal: revenue. Cadena: adopción de plantillas → retención Enterprise → NRR. Familias secundarias que también tocan: cost (menos horas de soporte sobre versiones de contratos) y risk (menos versiones inconsistentes circulando con clientes finales).

Datos cuantitativos del caso (los que ya teníamos del bloque IV):

• Adopción actual de plantillas: 28% en Enterprise, 88% retención semanal entre los que las usan.
• Churn anual Enterprise actual: 12%, objetivo del año 8%.
• Stickiness de cuentas que usan plantillas: 0,48 vs 0,32 en cuentas que no.

Datos cualitativos:

• 8 entrevistas a power users de cuentas Enterprise que ya usan plantillas: todos describen ahorro de 2-3 horas por contrato.
• 5 entrevistas a usuarios que abandonaron el flujo de plantillas: tres por confusión con la nomenclatura, dos por no encontrar la opción tras crear su primer contrato manual.
• 47 tickets de soporte en los últimos 60 días sobre cómo crear plantillas o cómo modificarlas.

Información adicional:

• Alcance: 2 sprints, 1 designer + 2 devs. Sin nuevas dependencias técnicas.
• Criterios de éxito a 90 días: Adopción Enterprise del 28% al 45%, retención semanal del 62% al 72%, tickets sobre plantillas −40%.
• Hitos: sprint 1 cambia descubrimiento y onboarding, sprint 2 mejora editor y previsualización, review intermedia a las 6 semanas.
• Riesgo principal: Que las plantillas estándar no encajen con el 15% de cuentas SMB que ya las usaban de forma muy específica. Mitigación: mantener la versión actual como fallback durante 90 días.

Una página, las tres preguntas resueltas, datos cuantitativos y cualitativos, alcance y riesgos. Lo que el comité de dirección puede leer en cinco minutos y decidir en poco tiempo.

Tres trampas habituales del caso de negocio

Antes de cerrar, tres errores que veo todo el rato y que descartan un caso de negocio en cuanto los detectas:

Trampa 1: El caso construido para justificar la decisión ya tomada

Llevas semanas vendiendo la idea internamente y el caso de negocio aparece después, con los datos elegidos para confirmar lo que ya querías. Eso no es un caso de negocio, es propaganda interna.

Filtro de honestidad: ¿qué datos te harían cambiar de opinión? Si la respuesta es «ninguno», tienes un problema.

Trampa 2: El caso sin contraargumento ni alternativa

Un caso bueno presenta lo que se va a hacer y al menos una alternativa descartada, con su razón. Si no hay alternativa en el documento, parece que no la consideraste, y eso resta credibilidad.

Trampa 3: El ROI inflado

Proyecciones del estilo «esto va a aumentar nuestro ARR en un 40%» sin cadena que las sostenga.

La regla del artículo sobre conectar producto y negocio funciona aquí: rigor, no certeza. Mejor «esperamos mover NRR en torno a 3 puntos en 12 meses con esta cadena» que «vamos a transformar el negocio».

Resumen rápido

• Un buen caso de negocio no convence con elocuencia, convence con cadena: Si la cadena producto-comportamiento-negocio no está, ningún PowerPoint te salva.
• Cabe en una página: Forzar a una página obliga a tu pensamiento a aclararse.
• Tres preguntas obligatorias: Para quién construyes, qué dolor abordas (aspirina vs vitamina), qué resultado esperas (revenue, cost o risk). Los objetivos no son actividades: si la respuesta a la tercera empieza por «mejorar» o «facilitar», aún no la has cerrado.
• Un test que separa aspirina de vitamina: ¿Qué pasa si no hacemos nada en 12 meses? Si la respuesta no es pérdida de clientes, coste o riesgo, probablemente es vitamina.
• Plantilla en tres partes: Overview con la cadena, datos de soporte (cuantitativos + cualitativos), información adicional con alcance, criterios de éxito, hitos y riesgos.
• Tres trampas a evitar: Caso construido para justificar lo decidido, caso sin alternativas, ROI inflado sin cadena.

Siguiente paso

Con esto cerramos el bloque V del curso. Has visto cómo conectar producto con negocio y cómo soportar esa conexión con un caso de negocio defendible.

Y ahora abrimos el último bloque, el VI, con una pregunta práctica que probablemente te estés haciendo desde hace bastante: ¿Cuándo invierto en una herramienta de analítica de producto, cómo la elijo entre las opciones del mercado y cómo justifico la inversión internamente?.

Cuatro artículos finales sobre cómo arrancar bien o cómo cambiar lo que ya tienes, si te hace falta claro…

¿Cuándo invertir en una herramienta de analítica de producto? →