Lanzamiento de un producto de IA en tres fases: primero, verifica el soporte

Puedes demostrar un producto de IA de forma convincente y aun así fracasar cuando un usuario real se topa con un error real. Un lanzamiento confiable es una prueba de soporte: la secuencia avanza solo cuando el soporte, la respuesta ante incidentes y los bucles de retroalimentación pueden absorber al siguiente grupo de usuarios.

El fallo más común es el lanzamiento todo a la vez: producto, anuncio, página de precios y mesa de ayuda llegan juntos. El equipo aprende lo que los usuarios necesitan mientras estos ya están juzgando el producto. Una secuencia por fases le da al equipo la oportunidad de corregir el producto antes de que los usuarios públicos lo vean.

La confianza se construye en la cola de soporte

Los lanzamientos por fases funcionan porque separan el aprendizaje de la exposición. La primera fase es un lanzamiento interno, donde el equipo recopila retroalimentación temprana y corrige problemas graves antes de la exposición pública. La tercera fase es un lanzamiento beta, que amplía el acceso anticipado y genera atención externa. Se recomienda un lanzamiento suave a la lista de espera antes del lanzamiento público, porque detecta primero los errores vergonzosos. Una línea de tiempo de lanzamiento viable puede reservar de 7 a 14 días antes del lanzamiento, de 24 a 48 horas para el día del lanzamiento y de 3 a 10 días después.

La demanda solo por invitación puede dar forma al producto, no solo al embudo. Superhuman generó anticipación restringiendo el acceso a una lista de espera solo por invitación y acompañando a los nuevos usuarios con una incorporación personalizada, incluida una demostración en vivo de 30 minutos. Ese tipo de incorporación funciona cuando el producto es difícil de explicar y el costo de soporte por usuario es alto. Para un equipo más pequeño, la misma lógica aplica: una lista de espera es una prueba de tus explicaciones antes de que la página de aterrizaje haga la venta.

La secuencia es una prueba, no un calendario

La etapa de lista de espera es donde el producto se encuentra con intención real sin escala real. Los usuarios esperan que el producto funcione, pero también son más comprensivos cuando el equipo es transparente. Esta es la etapa donde las herramientas de soporte y de errores se convierten en la interfaz principal del producto. Si el equipo no puede responder una pregunta sencilla, la siguiente versión solo creará más preguntas.

El plan gratuito de correo de Kit soporta 10,000 suscriptores. Esa capacidad es suficiente para una lista de espera pequeña, pero la restricción real no es la herramienta de correo. Es si el equipo puede convertir los registros en retroalimentación útil antes de que salga la siguiente invitación.

El rediseño es simple. Trata cada etapa como un pequeño lanzamiento de producto con sus propios criterios de salida. Los usuarios tempranos prueban el bucle principal. Los usuarios invitados reciben incorporación. Los criterios de salida deben ser visibles para todo el equipo, no enterrados en notas. Si una etapa no puede responder esas preguntas, la siguiente etapa debe esperar.

La lista de verificación decide cuándo puede llegar el siguiente grupo

La lista de verificación a continuación es el control de liberación. Es lo suficientemente corta para ejecutarse antes de una liberación y lo suficientemente estricta para detener una liberación. Cada elemento existe porque un fallo de lanzamiento suele ser un fallo de soporte: un usuario se topa con un error, no puede saber si es conocido, no puede reportarlo y no puede saber qué pasará a continuación.

• Una página de estado está en la lista de verificación de lanzamiento no comercial; le dice a un desconocido si el producto está caído, degradado o en recuperación.
• El seguimiento de errores forma parte de esa lista.
• La bandeja de soporte forma parte de esa lista.
• Una persona designada puede declarar un incidente sin pedir permiso a todo el equipo.
• Un usuario puede reportar un problema sin abrir un ticket, un correo o una ventana de chat.
• El equipo puede ver los principales modos de fallo antes de que se invite al siguiente grupo.
• La retroalimentación del grupo actual se revisa en una reunión con una decisión: corregir, posponer o bloquear el lanzamiento.
• El siguiente grupo se libera solo después de que los bloqueos del grupo anterior se cierren o se acepten explícitamente.

Usa la misma lista de verificación entre las fases interna, de lista de espera y pública. Una bandeja llena de preguntas sin responder es una señal de detención. Un registro de errores que no puede mostrar qué se rompió solo creará más tickets. La retroalimentación recopilada que nunca se convierte en una decisión debe retener al siguiente grupo.