Planteamiento y contexto
Una empresa SaaS B2B tiene 1.200 clientes y 85.000 usuarios activos semanales. Los equipos de Customer Success, operaciones de soporte y account managers afirman que necesitan «una herramienta interna para mejorar la eficiencia», pero no describen ningún problema común. Tienes 2 semanas para la etapa de discovery y un squad de ingeniería durante 6 semanas para la implementación. La herramienta debe reutilizar el CRM y el sistema de tickets existentes; no es posible aumentar el headcount ni reconstruir una plataforma.
Explica qué preguntarías, cómo identificarías el verdadero problema del flujo de trabajo, a qué usuarios atenderías primero, cómo definirías un MVP y las métricas de éxito, y cuándo continuarías, cambiarías de rumbo o te detendrías.
Qué evalúa el entrevistador
- Si puedes descomponer una solicitud vaga en usuarios, tareas, frecuencia, puntos de dolor y resultados de negocio.
- Si utilizas evidencia para validar el problema en lugar de aceptar «construir una herramienta» como solución.
- Si puedes delimitar el alcance de un MVP entregable en 2 semanas de discovery y 6 semanas de ingeniería.
- Si puedes gestionar objetivos de equipo en conflicto y límites de integración.
- Si utilizas métricas segmentadas y reglas de parada (stop rules) en lugar de limitarte a reportar el lanzamiento o la satisfacción.
Preguntas para aclarar primero
- ¿Qué significa «eficiencia» en este caso: tiempo de gestión, duplicación de entradas, tasa de errores, espera de respuesta o alternancia entre sistemas?
- ¿Qué rol se encuentra con el problema más a menudo y cuáles son su frecuencia y sus consecuencias?
- ¿Cómo se ejecuta el flujo de trabajo actual y qué pasos se mueven entre el CRM, el sistema de tickets y las hojas de cálculo?
- ¿Afecta el problema a los ingresos, la retención, el cumplimiento normativo o solo a la comodidad de los empleados?
- ¿A cuántos usuarios y registros reales de actividad se puede acceder en 2 semanas, y qué datos se pueden inspeccionar?
- ¿El resultado de 6 semanas debe ser un flujo de trabajo utilizable o puede ser un prototipo interactivo complementado con servicio humano?
Estructura de respuesta de 30 segundos
Traduciría la «eficiencia» en una tarea observable y luego priorizaría por rol, frecuencia e impacto. Durante dos semanas de discovery, combinaría entrevistas, observación del flujo de trabajo, datos de tickets y datos del CRM para verificar quién pierde qué y en qué contexto. El MVP resolvería un flujo de trabajo medible y de alta frecuencia, reutilizaría las interfaces de los sistemas existentes y mantendría un respaldo humano. Las métricas cubrirían el tiempo de finalización de tareas, la duplicación de entradas, la tasa de errores, la adopción y los resultados de los usuarios, con reglas definidas de antemano para continuar, cambiar o detener la inversión.
Análisis detallado paso a paso
Paso 1: Reescribir la solicitud como hipótesis de problemas
Reescribe «necesitamos una herramienta interna» como «un rol experimenta una fricción en una tarea que empeora un resultado». Un account manager podría estar copiando información entre el CRM y el sistema de tickets; a operaciones de soporte podría preocuparle más el retraso en la asignación. Redacta varias hipótesis y no trates una forma de implementación como si fuera el problema.
Paso 2: Planificar el discovery según la solidez de la evidencia
Observa primero los flujos de trabajo reales y los casos recientes, utiliza entrevistas semiestructuradas para explicar las causas y luego recurre a logs, tickets y datos del CRM para estimar la escala. Una preferencia declarada es un indicio, no una prueba de demanda. Para cada hipótesis, registra la evidencia a favor, los contraejemplos, las preguntas abiertas y el siguiente paso de validación.
Paso 3: Elegir a los usuarios objetivo y la prioridad
Clasifica los flujos de trabajo por frecuencia, impacto, alcance y viabilidad de mejora. Prioriza un flujo de trabajo frecuente con un impacto claro que pueda mejorarse dentro de los límites de los sistemas actuales. Un flujo de trabajo infrecuente pero de alto riesgo requiere una evaluación independiente de seguridad o cumplimiento normativo; no lo descartes solo porque el número de usuarios sea reducido.
Paso 4: Delimitar el alcance de un MVP de seis semanas
El MVP debe cubrir una tarea de extremo a extremo, como leer el contexto del cliente a partir de un ticket, generar un borrador de gestión estructurado y reescribirlo en el CRM tras la confirmación del empleado. No agregues aún un nuevo centro de permisos, un panel completo de reportes ni una plataforma para varios equipos. Si una integración falla, preserva la ruta original y permite que los empleados vean, editen y deshagan el resultado.
Paso 5: Gestionar conflictos de equipo y límites de integración
Haz que los equipos debatan sobre el mismo mapa de flujo de trabajo y árbol de métricas en lugar de comparar listas de funcionalidades. Confirma permisos, reglas de escritura, límites de peticiones (rate limits) y fronteras de retención para el CRM y el sistema de tickets. Todo lo que no se pueda integrar de forma segura en seis semanas pasará a ser una exportación, una confirmación humana o parte de un alcance posterior.
Paso 6: Definir métricas y reglas de parada
Los indicadores adelantados (leading indicators) incluyen la adopción del flujo de trabajo objetivo, el tiempo de finalización y la duplicación de entradas. Los indicadores de resultado incluyen la tasa de errores, el tiempo de respuesta al cliente y el retrabajo. Las métricas de control (guardrails) incluyen errores de permisos, incidentes de fuga de datos, quejas de empleados y tasa de fallos del sistema. Si la adopción aumenta mientras los errores o el retrabajo superan un umbral, pausa la expansión y vuelve a la validación del problema.
Paso 7: Planificar la validación y el lanzamiento
Valida el flujo con un prototipo y simulación humana; luego realiza una prueba piloto con un equipo y un tipo de tarea. Establece una línea base, un grupo de control o una comparación de antes y después, y segmenta los resultados por rol y tarea. Revisa la evidencia semanalmente para decidir si expandir, revisar la hipótesis, continuar con el servicio humano o detener el proyecto.
Respuesta de ejemplo de alta calidad
No aceptaría «construir una herramienta» como la declaración del problema. Desglosaría la eficiencia en tareas concretas, identificaría qué rol está duplicando entradas, esperando o cometiendo errores, y utilizaría dos semanas de observación, entrevistas, datos del CRM y datos de tickets para verificar la escala. Clasificaría las opciones por frecuencia, impacto, alcance y viabilidad a seis semanas; luego elegiría un flujo de trabajo de alta frecuencia con un resultado medible. El MVP leería el contexto de los sistemas existentes, generaría un borrador editable y escribiría en el sistema de destino solo tras la confirmación del empleado; el flujo de trabajo original seguiría estando disponible si fallan los permisos o la escritura. Las métricas incluirían adopción, tiempo de finalización, duplicación de entradas, tasa de errores, retrabajo y tiempo de respuesta al cliente, con errores de permisos, fugas de datos y fallos del sistema como guardrails. Haría un piloto con un solo equipo, predefiniría umbrales de expansión, cambio y parada, y pausaría la expansión si la eficiencia mejora a la par que aumentan los errores o el retrabajo.
Errores comunes
- Tratar la «herramienta interna» como el requisito y saltar directamente a pantallas o funcionalidades.
- Entrevistar solo a gerentes en lugar de observar el trabajo de primera línea.
- Sustituir la evidencia de comportamiento y las métricas de resultados por una única encuesta de satisfacción.
- Atender a tres equipos a la vez y no completar ningún flujo de extremo a extremo en seis semanas.
- Ignorar los límites de permisos, escritura y retención del CRM y del sistema de tickets.
- Medir la adopción sin métricas de control para errores, retrabajo y privacidad.
- No tener una regla de parada y usar la inversión previa como motivo para continuar.
Preguntas de seguimiento y respuestas
¿Qué pasa si los tres equipos dicen que su problema es el más importante?
Pide a cada equipo casos prácticos utilizando los mismos criterios de frecuencia, impacto, evidencia y viabilidad. Prioriza los resultados verificables y la capacidad de completar un ciclo de seis semanas; registra el resto como hipótesis posteriores en lugar de reemplazar la priorización por influencias políticas.
¿Qué pasa si el negocio insiste en entregar toda la plataforma de una vez?
Separa las restricciones compartidas del primer flujo de trabajo. Entrega un corte vertical (vertical slice) observable y reversible, demuestra el valor con métricas reales y luego decide qué interfaces y permisos justifican invertir en la plataforma. No comprometas un alcance que no pueda validarse de forma segura en seis semanas.
¿Qué pasa si la adopción del MVP es baja aunque las entrevistas fueron positivas?
Revisa las rutas reales de las tareas, los momentos de activación, los permisos de escritura y los logs de fallos, distinguiendo el conocimiento de la herramienta frente a su uso real en el trabajo. Comprueba si el costo de confirmación o la disrupción del flujo de trabajo son el obstáculo; realiza un pequeño experimento tras reducir la fricción en lugar de maquillar la brecha de comportamiento con más promoción.
¿Qué pasa si la eficiencia mejora pero la tasa de errores también aumenta?
Segmenta por rol, tarea y gravedad de los errores, y pausa la expansión en contextos de alto riesgo. Si los errores superan el umbral de control, restablece la confirmación humana, acota el alcance o modifica el flujo. Continúa invirtiendo solo cuando los errores sean tolerables y las métricas de resultados sigan mejorando.