Hipótesis VS requisitos: ¿qué es más importante en proyectos de innovación?

No hay duda de que en el mundo digital en el que nos encontramos, vivimos con un alto grado de incertidumbre.

Sabemos que todo puede cambiar en cualquier momento, tecnologías que revolucionan el mercado, agentes externos que no solo se sitúan líderes, sino que cambian las reglas de juego de cualquier sector…

Y si sabemos que todo puede cambiar, ¿por qué nos empeñamos en fijar los requisitos por encima de todo?

Me he dado cuenta de que muchas empresas por fin han desterrado los métodos tradicionales en favor de métodos ágiles, pero sin embargo, aún escriben sus product backlog en piedra y priman el software funcionando, como dicen los principios ágiles, por encima de todo.

Es decir, su principal medida de progreso es cuánta funcionalidad incorporan al producto en lugar de medir cuánto están aprendiendo para mejorar realmente su producto.

Si bien con software funcionando y ya en producción se puede, y se debe, recoger el feedback de nuestros usuarios y clientes con distintos métodos (analítica, encuestas, feedback en redes sociales, etc), en otras muchas ocasiones puedes obtener ese aprendizaje validado por clientes reales sin haber desarrollado nada.

En esto es en lo que se basa el desarrollo orientado a hipótesis. Al trabajar con hipótesis, el paradigma de trabajo cambia. Ya habíamos cambiado los antiguos pliegos de requisitos en historias de usuario, ahora el product backlog hay que formarlo en base a los experimentos que permitan validar las hipótesis planteadas.

¿Cómo lo hacemos?

1. A partir de nuestra idea, diseñamos un modelo de negocio.
2. Seleccionamos cuáles son las hipótesis que sustentan ese modelo de negocio.
3. Crear un backlog de experimentos que permitan validar las hipótesis planteadas. Es importante identificar qué indicadores de negocio debemos observar en cada experimento para asegurarnos si la hipótesis se ha cumplido o no, olvidándonos así de tomar decisiones en base a la intuición.

Y como escribía más arriba, un experimento no tiene por qué necesitar software. Hay hipótesis que pueden probarse con un prototipo navegable con usuarios (por ejemplo con nuestro RPM) o incluso con un simple vídeo.

Por ejemplo, Drew Houston, el fundador de Dropbox vendió con un vídeo su idea de negocio: “Millones de usuarios tienen la necesidad de poder tener una plataforma en la nube para acceder a ficheros".

Consiguió, a muy bajo coste, que Sequoia Capital invirtiese 1,2M de euros en su idea. ¿Cuánto tiempo, y dinero, hubiese tenido que invertir para llevar software funcionando a esa reunión?

Esta forma de trabajo es ideal cuando trabajamos en etapas de innovación. Pero no solo en innovación, también puede es muy útil para el desarrollo de un producto ya que construir en base a hipótesis ayuda a que no sólo el Product Owner y los stakeholders hablen de negocio, si no que todo el equipo esté orientado a KPIs y sean conscientes del impacto directo de su trabajo en el negocio.

El resultado: mejor cumplimiento de objetivos y mucho menos presupuesto gastado en iniciativas que no aportan valor.