Cultura de experimentación en producto: cómo probar sin pedir permiso para todo
Una cultura de experimentación hace que el equipo pruebe ideas con datos y aprenda de los fallos. Qué liderazgo y reglas la hacen posible y qué la hunde.
¿Qué significa tener cultura de experimentación?
No es hacer muchas pruebas. Es que probar sea la forma normal de decidir. Una empresa con mil experimentos al año puede tener mala cultura si cada uno requiere tres aprobaciones y nadie documenta los resultados. Y un equipo pequeño puede tenerla si decide siempre con una hipótesis y una métrica.
Mixpanel propone un proceso documentado para enviar, ordenar por prioridad y registrar los experimentos, con hipótesis, métricas de éxito y un objetivo claro para cada uno, y recomienda revisar de forma periódica qué funciona en ese proceso (Mixpanel, “Culture of experimentation”).
¿Por qué le importa a un diseñador?
Porque las decisiones de diseño suelen tomarse por jerarquía: gana la propuesta de quien habla más alto. Una cultura de experimentación cambia la conversación. En lugar de defender una pantalla, defiendes una hipótesis, y la prueba decide.
También te da permiso para equivocarte. Si cada propuesta de diseño se juega como un examen, la gente deja de proponer cosas arriesgadas. Si los experimentos son pruebas con resultados esperados, el equipo se atreve más.
Esta cultura encaja con la forma en que el diseño se discute en general. Si tu organización ya tiene una cultura de diseño donde las decisiones se defienden con argumentos, el paso a experimentar es corto. Si no la tiene, la experimentación puede convertirse en una nueva forma de imponer opiniones, ahora con gráficos.
¿Qué piezas la sostienen?
Las guías de Mixpanel, Airship y Pony coinciden en tres piezas:
- Liderazgo visible. Mixpanel dice que quizá el elemento más importante es el respaldo de la dirección. Airship pide un “champion” en la cúpula y que la dirección apruebe roles, herramientas y KPIs.
- Acceso y reglas. Airship quiere que todos puedan probar sin depender de desarrolladores, pero propone un mecanismo para alinear a quienes prueban antes de cada experimento, para que las pruebas no interfieran entre sí, y un panel con todos los experimentos activos. Pony aconseja dar libertad pero marcar límites claros.
- Un registro de aprendizajes. Pony recomienda una base de conocimiento de resultados accesible para todos, con formato estandarizado, un cambio a la vez y un plazo estricto para cada prueba. Un experimento que se documenta sirve a la próxima persona que proponga algo parecido.
Pony cita además el caso de Booking.com, donde las revisiones entre pares de los experimentos suelen emparejar a personas con experiencia con recién llegados. Es una forma barata de mejorar las hipótesis sin añadir burocracia.
¿Cómo se fomenta sin burocracia?
- Define una plantilla corta. Hipótesis, cambio concreto, métrica principal, tamaño de muestra y fecha de revisión. Con cinco campos basta.
- Limita el alcance. Un cambio por experimento. Si cambias tres cosas, no sabrás cuál funcionó.
- Pon fechas de cierre. Un experimento sin fecha se queda corriendo o se abandona sin conclusión.
- Comparte los resultados también cuando salen mal. Un fracaso bien escrito evita que otro equipo lo repita.
- Empieza con un piloto. Un solo experimento bien hecho en un flujo con tráfico sirve de ejemplo para que el resto vea cómo se hace.
Ejemplo
Ejemplo ilustrativo: una plataforma de cursos quiere que más estudiantes terminen la primera lección. El diseñador propone cambiar el orden de los pasos en el onboarding. El equipo no discute si le gusta, sino que escribe la hipótesis: «si mostramos la lección corta antes de pedir el perfil, esperamos que más personas completen la primera lección, porque en las entrevistas pidieron ver contenido antes de dar datos». El experimento corre dos semanas. No mejora la finalización, pero sí muestra que quienes abandonan lo hacen en el paso del perfil, no en la lección. El equipo lo registra en la base de conocimiento y el siguiente experimento prueba el texto de ese paso.
¿Cuándo NO conviene experimentar?
- Cuando el cambio es una obligación legal o de seguridad. No se prueba: se cumple.
- Cuando no hay tráfico suficiente. Con pocos usuarios, las pruebas no llegan a una conclusión. Usa investigación cualitativa.
- Cuando el experimento tiene un efecto negativo claro. Probar algo que puede perjudicar a la persona no es experimentar, es arriesgarla.
- Cuando la cultura es solo un eslogan. Si la dirección no revisa los resultados ni cambia decisiones por ellos, la experimentación es decorativa.
Errores comunes
- Medir actividad en lugar de resultados: contar pruebas, no decisiones.
- Lanzar tests que se pisan entre sí en la misma pantalla.
- No documentar los fracasos.
- Decidir antes de que termine el test porque el resultado parece bueno.
- Dejar que solo un equipo pueda proponer experimentos.
Cómo empezar mañana
Escribe una plantilla de cinco campos y úsala para la próxima propuesta de diseño de tu equipo. Crea un registro compartido, aunque sea una hoja de cálculo, con cada experimento, su resultado y lo que se aprendió. Pide a alguien de dirección que revise el registro una vez al mes. Si el experimento es sobre conversión, empieza por la optimización de conversión y mira cómo se decide el tamaño de muestra. Y si el equipo aún no entiende qué es una buena prueba, el texto sobre pruebas A/B es un punto de partida.