Ejercicio: Simular una sesión de discovery con un cliente ficticio

Tipo de lección: Video

Concepto clave

La sesión de discovery técnico es el proceso estructurado donde un Sales Engineer investiga las necesidades, arquitectura y desafíos específicos del cliente para determinar si su solución SaaS es adecuada. No es una demostración de producto, sino una conversación diagnóstica.

Imagina que eres un médico especialista: antes de recetar un tratamiento, necesitas hacer preguntas específicas, revisar historial médico y entender síntomas. En ventas SaaS, el discovery es ese diagnóstico donde identificas "dolores" técnicos reales, no solo los superficiales que el cliente menciona inicialmente.

Cómo funciona en la práctica

Una sesión efectiva sigue esta estructura:

1. Preparación: Investiga el cliente, su industria y posibles puntos de dolor antes de la reunión.
2. Apertura: Establece agenda y objetivos claros en los primeros 5 minutos.
3. Preguntas de contexto: "¿Qué sistema usan actualmente para gestión de datos?"
4. Preguntas de profundidad: "¿Cómo manejan los picos de carga en su infraestructura actual?"
5. Validación: Parafrasea lo entendido para confirmar.
6. Siguientes pasos: Define acciones concretas basadas en lo descubierto.

Ejemplo con datos reales:

Fase	Pregunta tipo	Objetivo
Contexto	"¿Cuántos usuarios activos tienen en su plataforma?"	Entender escala
Profundidad	"¿Qué porcentaje de esos usuarios accede simultáneamente en horas pico?"	Identificar necesidades de rendimiento
Validación	"Entonces, si entendí bien, necesitan soportar 500 usuarios concurrentes con latencia menor a 2 segundos"	Confirmar entendimiento

Caso de estudio

Cliente ficticio: TechFlow Inc., empresa de logística con 200 empleados que usa un sistema legacy de seguimiento de paquetes.

Situación inicial: El cliente dice "necesitamos un sistema más rápido".

Discovery realizado:

"Durante nuestra conversación, descubrimos que el verdadero problema no era velocidad general, sino que su sistema actual no escala durante temporada alta (noviembre-diciembre), causando caídas del 40% en procesamiento de pedidos. Además, su equipo técnico dedica 20 horas semanales a mantenimiento manual que podría automatizarse."

Resultado: En lugar de vender "velocidad", el Sales Engineer propuso una solución con escalado automático y automatización de procesos, alineada con necesidades reales.

Errores comunes

• Hablar más que escuchar: El Sales Engineer domina la conversación con características del producto en lugar de hacer preguntas. Solución: Sigue la regla 70/30 - el cliente debe hablar 70% del tiempo.
• Preguntas superficiales: Hacer solo preguntas generales como "¿Tienen problemas?". Solución: Profundiza con "¿Puede darme un ejemplo específico del último incidente?".
• Asumir necesidades técnicas: Suponer que porque el cliente es una startup necesita soluciones "ligeras". Solución: Preguntar sobre arquitectura actual y planes de crecimiento.
• No validar entendimiento: Seguir sin confirmar si interpretaste correctamente. Solución: Usar frases como "Déjeme ver si entendí..." después de puntos clave.
• Ignorar restricciones presupuestarias: Descubrir necesidades técnicas sin considerar realidad financiera. Solución: Preguntar "¿Cómo manejan actualmente las aprobaciones de gastos en infraestructura?".

Checklist de dominio

1. Preparé 5-7 preguntas específicas basadas en investigación previa del cliente
2. Establecí agenda y objetivos claros en los primeros 5 minutos de la reunión
3. Hice preguntas que comienzan con "cómo", "qué" y "por qué" en lugar de preguntas cerradas
4. Identifiqué al menos un "dolor" técnico que el cliente no había mencionado inicialmente
5. Validé mi entendimiento parafraseando en 3 puntos clave durante la conversación
6. Documenté hallazgos técnicos específicos (integración, escalabilidad, seguridad)
7. Definí siguientes pasos concretos basados en lo descubierto, no en características genéricas del producto

Simulación de sesión de discovery con cliente ficticio: DataSecure Corp

Preparación

Investiga el perfil ficticio:

• Empresa: DataSecure Corp
• Industria: Fintech
• Tamaño: 150 empleados
• Situación conocida: Usan múltiples herramientas de seguridad desconectadas

Ejecución del role-play

1. Prepara tu apertura: Escribe exactamente qué dirás en los primeros 3 minutos para establecer confianza y agenda.
2. Desarrolla preguntas clave: Crea 8 preguntas para descubrir:
   • Arquitectura técnica actual
   • Procesos de seguridad específicos
   • Dolores no mencionados inicialmente
   • Restricciones de integración
3. Simula la conversación: Graba un audio de 10 minutos donde:
   • Haces las preguntas preparadas
   • Escuchas activamente (incluye pausas)
   • Parafraseas para validar
   • Identificas al menos 2 necesidades técnicas no obvias
4. Documenta hallazgos: Crea un brief técnico con:

   Necesidad descubierta	Impacto técnico	Relevancia para solución
   Ejemplo: Necesitan API para automatizar reportes	Reduce trabajo manual en 15h/semana	Nuestra solución tiene API REST documentada

Evaluación

Revisa tu grabación y verifica:

• ¿Hablaste menos del 30% del tiempo?
• ¿Hiciste preguntas que revelaron información nueva?
• ¿Validaste al menos 3 veces tu entendimiento?

Pistas

• En lugar de preguntar "¿Tienen problemas de seguridad?", pregunta "¿Cómo manejan actualmente la detección de amenazas en tiempo real?"
• Cuando el cliente da una respuesta general como "es lento", profundiza con "¿Puede darme un ejemplo específico de cuándo notó esa lentitud y qué impacto tuvo?"
• Prepara 2-3 preguntas sobre integraciones técnicas ANTES de mencionar las capacidades de tu producto

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.