PILOTS · EVIDENCE · ROADMAP
Publicado: 2026-10-02 · Lectura editorial
¿Qué debería demostrar un piloto antes de convertirse en roadmap?
Un piloto no debería convertirse automáticamente en una lista de features. Antes debe producir evidencia suficiente para decidir qué repetir, cambiar, escalar o detener.
Un piloto suele empezar como una forma acotada de aprender. El problema aparece cuando el cierre se convierte en una colección de solicitudes: cada comentario se transforma en una feature y el roadmap hereda la agenda del piloto sin entender qué demostró.
El trabajo no es transcribir feedback. Es transformar señales en evidencia, evidencia en decisión y decisión en una inversión concreta.
01 · SIGNAL TRANSFORMATION
Una señal no entra al roadmap en el mismo estado en que aparece
SEÑAL A
“Necesitamos exportar PDF.”
Puede significar:
La persona necesita compartir, archivar o presentar el resultado fuera del producto.
Distinguirla con:
¿Quién lo pide? ¿Qué intenta conseguir? ¿Aparece en otros casos? ¿Bloquea valor?
ENTRA AL ROADMAP
SEÑAL B
“El setup nos tomó demasiado.”
Puede significar:
Puede existir fricción, dependencia de soporte o una expectativa incorrecta sobre el inicio.
Distinguirla con:
Observar dónde se detienen distintos usuarios y qué paso requiere ayuda.
INVESTIGAR
SEÑAL C
“Queremos el logo en el reporte.”
Puede significar:
Puede ser una necesidad comercial de un cliente concreto, no una necesidad del producto base.
Distinguirla con:
Separar requisito contractual, preferencia y comportamiento repetible.
SE MANTIENE CONTEXTUAL
SEÑAL D
Usan el piloto una vez y abandonan.
Puede significar:
Contradice la hipótesis de que el problema reaparece con suficiente frecuencia.
Distinguirla con:
Revisar contexto de uso y volver a la hipótesis de recurrencia antes de añadir features.
CONTRADICE LA HIPÓTESIS
02 · EL CASO DEL PDF
Feedback → feature es una cadena incompleta
ESCENARIO ILUSTRATIVO
“Necesitamos exportar PDF”
Tres participantes del piloto lo mencionan. El equipo lo interpreta como una prioridad evidente y lo coloca en el siguiente sprint.
QUIÉN
Dos son consultores que envían resultados a clientes; uno sólo quería guardar una copia.
QUÉ
El trabajo no es “tener PDF”: es compartir un resultado con otra persona sin perder confianza.
QUÉ PASÓ
Los dos consultores repiten el uso; el tercero no vuelve al producto.
HECHO
La solicitud aparece en tres conversaciones.
INTERPRETACIÓN
Existe una necesidad de compartir resultados en al menos un segmento.
INCERTIDUMBRE
Si exportar PDF es la solución común o sólo una implementación posible.
Decisión habilitada: Investigar el workflow de compartir antes de construir: el roadmap puede terminar en exportación, enlace compartible o integración distinta.
03 · DECISION RULE
Qué debe demostrar un piloto antes de escalar
01
HIPÓTESIS
Qué problema y qué comportamiento esperaba probar el piloto.
02
REPETICIÓN
Qué ocurrió en más de un caso comparable y qué sólo ocurrió una vez.
03
VALOR
Qué resultado cambió para el usuario, no sólo qué pidió durante la sesión.
04
ESCALA
Qué soporte manual, excepción o dependencia tendría que desaparecer antes de ampliar.
EVIDENCIA ANTES DE ROADMAP
Una solicitud entra al roadmap cuando representa una decisión respaldada, no sólo porque alguien la pidió.
El alcance de la inversión debe coincidir con el alcance de la evidencia: un caso repetido puede justificar otra prueba; no necesariamente un producto completo.
04 · NEXT MOVE
El cierre del piloto debería dejar menos incertidumbre
Un buen cierre no intenta hacer que todas las señales parezcan positivas. Clasifica qué se repite, qué requiere investigación, qué queda contextual y qué contradice la hipótesis inicial.
El roadmap es una consecuencia de esa clasificación. Si todavía no puedes explicar por qué una señal importa, todavía no tienes una decisión lista para convertir en construcción.
PRODUCT & UX DIAGNOSTIC
Convierte el resultado de tu piloto en una decisión.
Identifica qué se observó, qué sigue siendo excepcional y qué merece entrar al siguiente ciclo.
Analiza tu situación de productoFUENTES
Fuentes
- Silicon Valley Product Group · Confianza y evidencia antes de comprometer la construcción de una solución.
- Google Research · Objetivos, señales y métricas para evaluar experiencia de producto.
FOUNDERS UX
Construir rápido no es suficiente.
Construir lo correcto es la diferencia.
Cuéntanos qué está frenando tu producto y lo revisamos contigo.