Pricing Logic
Construir la primera lógica de precio.
Precio inicial
Habilidad: Proponer un precio preliminar coherente para comenzar conversaciones comerciales reales.
¿Por qué importa esta habilidad?
Muchos founders evitan el precio porque temen equivocarse. Pero sin un precio, no hay conversación comercial real. El precio inicial no tiene que ser perfecto: tiene que ser un punto de partida que permita aprender.
Qué se ve como un buen resultado
El equipo tiene un precio inicial propuesto con al menos una justificación básica. Puede ser rango o punto, pero existe y se usa en conversaciones con clientes.
Errores comunes
- Esperar a tener el modelo financiero completo para proponer un precio.
- Poner un precio solo basado en el costo sin considerar el valor.
- No probar el precio con clientes reales por miedo al rechazo.
- Cambiar el precio con cada conversación sin aprender de los patrones.
Preguntas que el startup debe responder
- ¿Cuánto cuesta producir o entregar la oferta?
- ¿Qué precio comparable existe en el mercado?
- ¿Cuánto vale el resultado para el cliente?
- ¿Cuál sería el precio que haría que el cliente dijera "eso es razonable"?
Artifact requerido
📄 Hoja de precio inicial
Propósito: Documentar el precio propuesto con su justificación y las reacciones del mercado.
Card vinculada: Precio inicial
Instrucciones de desarrollo
- Define el precio o rango de precio inicial con base en costo, mercado y valor percibido.
- Escribe en una frase por qué ese precio tiene sentido.
- Prueba el precio en al menos tres conversaciones de discovery.
- Documenta las reacciones: ¿caro, barato, razonable? ¿Por qué?
Estado esperado: Hoja con precio propuesto, justificación y primeras reacciones del mercado documentadas.
Criterios de revisión del Artifact
- El precio está definido de forma específica (no solo "asequible").
- La justificación cubre al menos uno de los tres criterios: costo, mercado, valor.
- Se probó con al menos tres clientes potenciales.
- Las reacciones están documentadas con citas o notas.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El precio inicial existe y está justificado.
- Ha sido probado con potenciales clientes.
- Las reacciones están documentadas y se usan para iterar.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ningún precio definido. |
| En progreso | Hay un precio intuitivo no documentado. |
| Completo | El precio está definido con justificación básica. |
| Revisado | El precio fue probado con clientes y las reacciones están documentadas. |
| Cumple estándar | El precio refleja aprendizaje de mercado y es coherente con el valor creado. |
| Fuerte/Sobresaliente | El modelo de precio guía las conversaciones comerciales y se actualiza con cada ciclo. |
Cards relacionadas / siguiente paso
- Precio basado en valor
- Recurrente o transaccional
- Cuantificación del valor
Precio basado en valor
Habilidad: Justificar el precio de la oferta desde el valor percibido o creado para el cliente, no solo desde el costo.
¿Por qué importa esta habilidad?
Las startups que solo calculan el precio desde el costo suelen dejar dinero sobre la mesa o subcobrar. El precio basado en valor conecta lo que el cliente gana con lo que paga, haciendo la conversación comercial más sólida.
Qué se ve como un buen resultado
El equipo puede articular la lógica de valor que justifica el precio: "el cliente paga X porque obtiene Y, y Y vale Z para él". Esta lógica sobrevive una conversación comercial real.
Errores comunes
- Justificar el precio solo con "el mercado cobra eso".
- No cuantificar el valor que se crea para el cliente.
- Usar lógica de valor sin evidencia de que el cliente lo percibe así.
- Dejar el pricing a "lo que el cliente esté dispuesto a pagar" sin un ancla racional.
Preguntas que el startup debe responder
- ¿Cuánto dinero ahorra o gana el cliente con esta solución?
- ¿Qué porcentaje del valor creado sería un precio justo?
- ¿Qué alternativa tiene el cliente y cuánto le cuesta?
- ¿Cómo presenta el equipo la lógica de precio en una conversación de venta?
Artifact requerido
📄 Modelo simple de pricing basado en valor
Propósito: Construir la lógica de valor que justifica el precio propuesto con números del cliente.
Card vinculada: Precio basado en valor
Instrucciones de desarrollo
- Cuantifica el valor que crea la solución para un cliente típico (ahorro, ingresos nuevos, riesgo evitado).
- Calcula el precio como porcentaje del valor creado (típicamente 10-30%).
- Compara el precio resultante con alternativas del mercado.
- Valida la lógica en conversaciones con al menos dos clientes.
Estado esperado: Modelo con valor cuantificado, precio derivado y comparación de mercado.
Criterios de revisión del Artifact
- El valor se expresa en términos numéricos del cliente (no de features).
- El precio tiene una lógica de captura de valor explícita.
- Se compara con alternativas reales del mercado.
- Ha sido probado en conversaciones comerciales.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El modelo de pricing basado en valor está documentado.
- El valor creado tiene cuantificación con base en datos del cliente.
- La lógica ha sido probada en conversaciones reales.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ninguna lógica de pricing basada en valor. |
| En progreso | Hay una intuición de valor pero no está cuantificada. |
| Completo | El modelo tiene valor estimado y precio derivado. |
| Revisado | El modelo fue validado con clientes reales. |
| Cumple estándar | La lógica de valor es el argumento central en las conversaciones de venta. |
| Fuerte/Sobresaliente | El modelo se actualiza con cada cierre o pérdida de venta. |
Cards relacionadas / siguiente paso
- Precio inicial
- Cuantificación del valor
- Recurrente o transaccional
Recurrente o transaccional
Habilidad: Definir si el ingreso del startup es único, recurrente o mixto, y diseñar la estructura de ingresos inicial.
¿Por qué importa esta habilidad?
La diferencia entre ingreso transaccional y recurrente define el valor de largo plazo de la empresa, la predictibilidad del flujo de caja y el atractivo para inversores. Esta decisión hay que tomarla conscientemente, no por defecto.
Qué se ve como un buen resultado
El equipo ha definido el modelo de ingresos (pago único, suscripción, consumo, licencia, etc.) con justificación y ha estimado cómo ese modelo impacta en la predictibilidad del negocio.
Errores comunes
- Elegir suscripción porque "las startups hacen eso" sin validar si el cliente acepta ese modelo.
- No considerar el impacto del churn en modelos recurrentes.
- Mezclar modelos de ingreso sin una lógica clara.
- No calcular el impacto del modelo de ingresos en el flujo de caja.
Preguntas que el startup debe responder
- ¿El cliente paga una vez o de forma periódica?
- ¿Qué modelo prefiere el cliente según lo que dijo en discovery?
- ¿Cómo afecta el modelo de ingreso al flujo de caja en los primeros 12 meses?
- ¿El equipo puede asumir el costo de adquisición dado el modelo de ingreso?
Artifact requerido
📄 Estructura de ingresos inicial
Propósito: Documentar el modelo de ingresos elegido, su justificación y el impacto estimado en el flujo de caja.
Card vinculada: Recurrente o transaccional
Instrucciones de desarrollo
- Define el modelo de ingresos: pago único, recurrente mensual/anual, consumo, licencia u otro.
- Escribe dos frases justificando por qué ese modelo es el correcto para tu cliente.
- Estima el ingreso por cliente en los primeros 12 meses bajo ese modelo.
- Identifica el riesgo principal del modelo (ej. churn en recurrente, cierre largo en transaccional).
Estado esperado: Estructura documentada con modelo de ingreso, justificación e impacto estimado.
Criterios de revisión del Artifact
- El modelo de ingresos está definido de forma específica.
- Tiene justificación vinculada al comportamiento del cliente.
- El ingreso por cliente tiene una estimación para 12 meses.
- El riesgo principal del modelo está identificado.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- La estructura de ingresos está documentada y justificada.
- Existe una estimación del ingreso por cliente.
- El equipo entiende el impacto del modelo en el flujo de caja.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ninguna estructura de ingresos definida. |
| En progreso | El modelo de ingreso es intuitivo pero no está documentado. |
| Completo | La estructura está definida con justificación básica. |
| Revisado | Tiene estimación por cliente y análisis de flujo de caja. |
| Cumple estándar | La estructura está validada con feedback de clientes y modelos financieros. |
| Fuerte/Sobresaliente | El modelo de ingresos evoluciona con el aprendizaje de ventas y se refleja en el árbol financiero. |
Cards relacionadas / siguiente paso
- Precio basado en valor
- Árbol financiero
- Vida del cliente