Intereses vs Posición en Negociaciones — Caso: Producto vs Ventas
Un ejemplo práctico para distinguir la demanda concreta (posición) del motivo subyacente (interés) y así encontrar soluciones que satisfagan a ambas partes.
Cuando las áreas hablan «idiomas» distintos (técnico vs comercial) las discusiones se enquistan. Separar posición e interés permite diseñar concesiones inteligentes—pocas veces la mejor respuesta es simplemente ceder o imponer.
Abajo encontrarás un escenario concreto, la extracción de posiciones e intereses y una breve explicación de por qué esa separación abre alternativas prácticas (arreglo temporal, criterios de aceptación, métricas compartidas).
Escenario 1 — Prioridad de features entre Producto y Ventas
Conflicto habitual: priorizar una feature que cierra un cliente ahora vs mantener la hoja de ruta técnica y la calidad a largo plazo.
Contexto
Producto tiene una hoja de ruta con funcionalidades técnicas; Ventas presiona para priorizar features que permitan cerrar un gran cliente esta semana.
Objetivos
Producto: mantener arquitectura limpia y no comprometer deuda técnica. Ventas: entregar resultados comerciales y asegurar la renovación del cliente.
Blocker
Falta de una métrica común para valorar impacto comercial vs costo técnico — cada parte habla en su idioma y no hay datos claros que decidan quién cede.
Detalle del escenario y recuerdo práctico
Nota práctica: Esto me recuerda a un sprint donde pedimos “solo un tweak” y acabó siendo 3 semanas de hotfixs. Los compromisos sin límite claro terminan costando más.
- Contexto resumido: Un gran cliente solicita una pequeña funcionalidad que para Ventas es crítica y urgente.
- Riesgo para Producto: introducir deuda técnica, romper consistencia de la arquitectura, generar rework.
- Riesgo para Ventas: perder la venta o la renovación si no se entrega una solución en el plazo pedido.
Intereses y posiciones
Producto
Posición: No introducir la nueva feature ahora; seguir con la hoja de ruta técnica.
Intereses: Mantener la calidad y la salud a largo plazo del producto; minimizar deuda técnica y riesgos operativos.
Ventas
Posición: Priorizar y lanzar la feature inmediatamente para cerrar al cliente esta semana.
Intereses: Cumplir objetivos comerciales, retener/renovar al cliente y generar ingresos a corto plazo.
Diferencia entre posición e interés en este caso
La posición es la demanda concreta (hacer o no hacer la feature ahora). El interés es la razón subyacente (salud técnica vs ingresos/retención).
Comprender los intereses abre opciones creativas que satisfacen a ambas partes—no se trata solo de ceder, sino de encontrar ajustes con límites, métricas y garantías.
- Ejemplos de soluciones basadas en intereses (no solo en posiciones):
- Arreglo temporal limitado: implementar una versión «sólo para ese cliente» con alcance muy controlado y fecha de revisión obligatoria.
- Criterios de aceptación técnicos: definir precondiciones (tests automatizados, límites de uso, guardrails) antes de lanzar.
- Métrica compartida de valor: acordar KPIs (impacto comercial esperado en 30/60/90 días) y comparar contra el costo técnico estimado.
- Compensación por deuda técnica: Ventas acepta un plan de priorización futuro para limpiar la deuda técnica introducida.
- Feature flagging y rollout controlado: desplegar detrás de flag para minimizar impacto y permitir rollback rápido.
- Acción práctica inmediata: Reunir en 24–48h un breve RFC con:
- Descripción del cambio propuesto y alcance mínimo.
- Impacto comercial esperado (valor estimado, cliente y riesgo de perderlo).
- Coste técnico estimado y mitigaciones (flag, tests, fecha de revisión).
- Métrica conjunta para decidir si mantener o revertir la solución (ej.: MRR/retención atribuible en 60 días).
Recomendaciones rápidas
- Separar siempre posición e interés al inicio de la conversación. Pida a cada parte resumir su interés en una línea.
- Evitar compromisos «solo un tweak» sin límites: documente alcance, criterios y fecha de revisión.
- Establecer métricas compartidas (comerciales y técnicas) para evaluar el éxito de la entrega rápida.
- Si se entrega una solución rápida, planificar y comprometer recursos para la reducción de deuda técnica en el roadmap posterior.
Si quieres, convierto lo anterior en un template de RFC o en una minuta con los puntos a firmar por Producto y Ventas antes del lanzamiento rápido.