Información para tablero de progreso

VALIDATION BOARD, UNA HERRAMIENTA

PARA GESTIONAR TUS HIPÓTESIS
46

Una de las fases más complicadas para una startup es

cuando llega el momento de confrontar el modelo de negocio con el mundo real y descubrir que
no todo lo que pensabamos era cierto. Es un momento donde resulta complicado llevar el control
de qué debemos probar, cómo vamos pivotando, si hemos validado una hipótesis o no …etc. Todo
un reto
Para resolver este problema en Lean Startup Machine han creado una interesante herramienta:
el Validation Board. El objetivo de esta herramienta es ofrecernos un marco sobre el que tomar
decisiones coherentes y gestionar el ciclo de vida de las hipótesis de nuestra startup y
sus pivots. Lo más interesante posiblemente en el práctica es que nos proporciona
una herramienta para controlar la validación de nuestras hipótesis. Recordemos la definición
de hipótesis:
Son aquellos hechos que consideramos como ciertos en nuestro modelo de negocio
pero que realmente no estamos seguros al 100%
El validation board o tablero de validación lean startup integra conceptos de las
metodologías Lean Startup y Customer Development (… y además nos permite seguir con la moda
de decorar nuestras startups con diagramas y post-it) :-)
 (puedes descargar la plantilla en PDF o usar un Google Docs Online. Descarga original aqui)
¿QUÉ PARTES TIENE EL VALIDATION BOARD O TABLERO
DE VALIDACIÓN DE HIPÓTESIS?
La primera vez que uno se enfrenta al Validation Board la sensaciones son encontradas: por un lado
parece muy interesante pero por otro lado no tenemos muy claro cómo usarl0… así que
empecemos por lo primero: ¿Qué partes tiene el tablero de validación?
ZONA SUPERIOR
La zona superior recoge las hipótesis más importantes de cualquier modelo de negocio, lo que
yo llamo las “hipótesis básicas” y que tendremos que contrastar antes de poder validar nuestro
modelo de negocio (es decir, transformar opiniones en hechos).

 Definir las hipótesis de CLIENTE (customer hypothesis): Es decir, sobre quién es nuestro cliente.
Recordemos que la hipótesis sobre quien es el cliente debe estar enfocada al segmento de los eartly
adopters (nunca al mercado de masas)… ya que son ellos los más indicados para empezar a probar
nuestro modelo de negocio.
 Definir las hipótesis del PROBLEMA (problem hypothesis): Debemos establecer el problema que
queremos resolver forma clara y sencilla, debe estar relacionada con la hipótesis de cliente (ya que
los problemas no existen “en vacío”, sino que son los clientes quienes tienen los problemas)
 Definir las hipótesis de la SOLUCIÓN (solution hypothesis): Es decir, qué tipo de producto
 o servicio creemos que es el mejor para resolver el problema de esos clientes. Aunque lo tengamos
claro, es buena idea no incluirlo en la primera iteración, ya que nos puede limitar a la hora de salir
al mercado y hablar con clientes.
 Conocer la evolución (pivots): Es una herramienta interesante ya que nos va a permitir visualizar
cómo ha cambiado el producto y las veces que se ha pivotado desde la idea original.
Las hipótesis deben ser definidas de forma clara, en una frase que se indique claramente el
hecho que se considera cierto. Habitualmente se crea uniendo el actor clave (cliente), una serie
de palabras descriptivas y una acción a realizar, por ejemplo:
Los proveedores están dispuestos a pagar una cuota de 50€ al mes por el servicio
ZONA DE DEFINICIÓN DE EXPERIMENTOS
Una de las zonas más interesantes, en ella debemos registrar las hipótesis o saltos de fe que
más riesgo entrañan para el modelo de negocio… y definir experimentos de una forma clara
y concisa para validar si son ciertas o no.

 HIPÓTESIS CLAVE (core assumptions): La idea es incluir lo que se conoce como hipótesis clave, es
decir, aquellas hipótesis que de mostrarse incorrectas podrían poner en peligro nuestro modelo de
negocio y obligarnos a pivotar
 HIPÓTESIS DE MAYOR RIESGO (riskiest assumption): Para decidirlo tendremos que utilizar
nuestro criterio. Habitualmente son aquellas que más riesgo implican para el modelo de negocio, ya
sea porque existe un alto grado de incertidumbre sobre ellas o porque implican un coste/riesgo que
debemos controlar con cuidado.
 MÉTODO (method): Aunque existen más métodos para validar o descartar nuestras hipótesis, en
Lean Startup Machine nos proponen los 3 más clásicos – Exploración, Conserje y Pitch (hablaremos
de ellos en el futuro, pero la idea es empezar por “exploración” y progresar o no en función de riesgo y
coste)
 CRITERIO MÍNIMO DE ÉXITO (minimum success criterion): Dado que los emprendedores
tendemos a ser optimistas natos, y para evitar subjetividad, debemos definir a priori qué umbral es
 el correcto para considerar una hipótesis validada. Eso implica decidir de antemano cuántas
entrevistas vamos a hacer y que umbral consideraremos como “éxito”.
ZONA DE RESULTADOS
En esta zona se recogen los resultados de confrontar con el mundo real nuestros
experimentos. Esto implica que una vez definido todo lo anterior debemos salir al mundo real
(recuerda, la verdad está ahí fuera y no en tu business plan) y verificar con clientes de verdad su
validez (o no).

 HIPÓTESIS VALIDADAS (validated): Si la hipótesis ha sido validada, es decir, el experimento ha

superado el umbral que habíamos definido como CRITERIO MÍNIMO DE ÉXITO, la registraremos
como validada y seguiremos comprobando la siguiente hipótesis más arriesgada.
 HIPÓTESIS INVALIDADA (invalidated): Sin embargo, si el experimento no ha superado el umbral
debemos registrarla en la zona de “Invalidadas” y volver atrás, a la zona superior. Allí debemos
pivotar, es decir, cambiar o quién es el cliente, o qué problema tiene (o cuál es la solución) y entrar
en un nuevo ciclo de validación.
EJEMPLO: ¿CÓMO USAR EL VALIDATION BOARD PARA
VALIDAR LAS HIPÓTESIS DE NUESTRO MODELO DE
NEGOCIO?
Aunque las descripciones son buenas, nada mejor que recurrir a un ejemplo imaginario para
entenderlo:
Se nos ha ocurrido, a través de una vivencia personal, que para una startup es
muy complicado encontrar proveedores de servicios (desde abogados hasta
diseñadores o asesores) que entiendan los requisitos de una startup, tanto en
velocidad como en costes o tipo de servicios
> > > > > > > > > < -- Haz click para ver la evolución
1. Incluimos quién pensamos que son los clientes (concreto, los que creemos serán early
adopters) y el problema que tienen. De momento no incluimos la solución, ya que aún
no hemos hablado con nadie.

2. Apuntamos las hipótesis más arriesgadas, pensamos que la que más es que las startups
no son capaces de encontrar fácilmente este tipo de proveedores

3. Para validar si es cierto o no vamos a entrevistarnos con otras startups (al menos 10).
Para considerar que la hipótesis es cierta necesitamos que 6 nos mencionen que es un
problema real.

4. Salimos al mundo real, hacemos las entrevistas pertinentes y descubrimos que

efectivamente, 7 de las compañías entrevistadas confirman que es un problema.
Hipótesis validada.

5. Ahora ya podemos pensar cómo vamos a resolver el problema… y decidimos que la

mejor forma es a través de un marketplace donde poner en contacto oferta y demanda.

6. La siguiente hipótesis a validar es que las startups están dispuestas a pagar (10€ al
mes, p.ej). por el servicio, y vamos a enviar una oferta a una lista de correo que tenemos
con startups, esperando que el 60% se inscriba.

7. Desgraciadamente, y aunque mostraban interés por resolver el problema, no están

dispuestas a pagar por ello (sólo un 20% se han apuntado). Hipótesis invalidada.
 8. Tenemos que pivotar, y pensamos que aunque las startups no quieran pagar quizás si
los proveedores… así que cambiamos de cliente y problema), y nos ponemos a
experimentar

9. En este caso lo primero que queremos probar es si los proveedores están dispuestos a
pagar 50€ al mes por estar dados de alta. Probamos con una lista de correo diferente,
y esperamos que el 50% se inscriba en la plataforma.

10. Hemos validado que nuestro principal cliente está dispuesto a pagar! Aunque aún
estamos lejos de haber validado el modelo entero, las cosas tienen buen aspecto.

CONCLUSIONES
El Validation Board es una herramienta muy interesante para llevar el control del ciclo de vida
de nuestro producto, las hipótesis asociadas en cada nueva iteración y las veces que hemos
pivotado…. algo absolutamente necesario y que desafortunadamente a menudo hacemos
con criterios subjetivos.
No es la única herramienta que cubre esta necesidad, de hecho desde hace tiempo se han
utilizado versiones modificadas de Kanban (como el Validated Learning Board) para hacer este
seguimiento. No hay que olvidar nunca que la clave es utilizar las herramientas para lo que
mejor nos convenga y como mejor nos convenga, no nos volvamos locos. Sólo son eso,
herramientas:
Recuerda, no trabajamos para las herramientas, sino que ellas deben trabajar para
nosotros cuándo y cómo a nosotros nos haga falta. Lo importante no es el martillo sino
el carpintero.