Highlights §
- Cuando hacemos producto, lo que buscamos es que los productos y funcionalidades que lancemos aporten el suficiente valor a nuestros clientes y usuarios para que empiecen a usarlos, y paguen por ellos. Por tanto, dependiendo del contexto, la línea que debemos marcar en nuestro MVP o primera versión es distinta.
Os doy varios ejemplos:
• Si estamos lanzando un nuevo producto en una industria profesional en la que los usuarios están acostumbrados a usar Excel, necesitamos crear un producto que mejore la experiencia que actualmente tienen. Por tanto, la barrera entrada será menor. Posiblemente con permitirles hacer una tarea mejor es suficiente para el MVP.
• El ya famoso MVP de Ontruck usando un grupo de Telegram fue posible porque nuestros clientes usaban solo email y teléfono. Lo que realmente vendíamos era un servicio, no un producto. Por tanto, la herramienta era el medio, no era el fin.
• Si ya tenemos un producto y estamos definiendo una nueva funcionalidad, el MVP de esa funcionalidad puede ser más sencillo que si es un producto nuevo. Los usuarios ya están usando nuestro producto, por tanto, hay menor coste de adopción. Si la mínima funcionalidad que lanzamos aporta valor a un porcentaje relevante de ellos, podemos lanzarla, aprender, coger feedback e iterar.
• Una startup que está haciendo un software para restaurantes me contaba que han tenido que lanzar una primera versión con muchas funcionalidades porque los restaurantes ya usan un competidor. Por tanto, hay una barrera de entrada que deben superar. En este caso, la clave para no complicar el lanzamiento, es detectar bien qué funcionalidades realmente necesitan para poder cambiar, y cuales son las opcionales que pueden esperar. También es clave segmentar a sus clientes y potencialmente atacar primero a los que más puedes aportar con tu propuesta de valor.
• En cambio, si estamos construyendo un producto en un mercado muy competido, la barrera de entrada será más alta. O bien nuestro producto resuelve solo una parte de manera disruptiva a como lo hace el resto de competidores, y entonces con lanzar solo algunas funcionalidades nos puede valer. O debemos cubrir lo que los usuarios esperan por defecto y, además, añadir nuestra propuesta de valor. (View Highlight)
- Hey Calendar es un ejemplo del último caso. Es un producto que compite con muchas alternativas y con buenas opciones por defecto como Google Calendar, Apple Calendar y Outlook. Para empezar, tenemos unas expectativas altas de lo mínimo que debe hacer un calendario. Por otro lado, los usuarios ya estamos acostumbrados y hacer el cambio de calendario tiene un coste de cambio de hábito.
Por tanto, si quieren que los usuarios cambien a Hey Calendar deben dar unas cuantas razones para hacerlo. En concreto, han apostado por nueve razones. ¿Son demasiadas? ¿Son suficientes? ¿Son las adecuadas? Lo descubrirán estas próximas semanas y meses.
A Theory of User Delight: Why Usability Is the Foundation for Delightful Experiences
Repasando las funcionalidades diferenciales, podemos decir que han apostado claramente por ser pleasurable. El personalizar tu calendario, como lo hacemos con una agenda en papel, hace que ese producto digital sea nuestro. Ya no es el calendario de Google o de Apple. Es el nuestro con nuestras fotos, nuestros aniversarios, nuestros círculos resaltando eventos, etc. (View Highlight)
- ¿Deberían haber validado con clientes?
Como comentaba anteriormente, parece que esta primera versión solo la han probado ellos mismos. Es cierto que son más de 100 personas en 37signals que usan el calendario en su aspecto personal y profesional. Sin embargo, el calendario lo van a usar perfiles muy variados. Habrá profesionales empleados, freelancers, emprendedores, abogados, estudiantes, etc. Las necesidades de cada tipo de usuario pueden ser distintas.
Ya hablé la semana pasada de cuando merecía la pena validar con clientes. Hay dos principales motivos.
- Queremos validar el concepto.
- Queremos asegurar que es usable. (View Highlight)
- Validando el concepto
Las funcionalidades diferenciales que han planteado en Hey Calendar son apuestas, parten de su intuición como me decía Jason en su respuesta. Ahora tendrán que ver cuánto se usa cada una de ellas. Habrá funcionalidades de esas nueve que se usen mucho por una gran mayoría de usuarios, habrá otras que se usen menos pero son muy relevantes para que ciertas personas hagan el cambio y quizás haya otras que no se usen.
Estas funcionalidades que han añadido no resuelven problemas importantes, sino que añaden esos detalles pleasurable al calendario que hacen que la experiencia sea más personal. Se podrían incluso considerar como parte del envoltorio para hacer atractivo a Hey Calendar. Por tanto, tiene razón Jason en que son funcionalidades muy difíciles de validar a priori. Si hacemos una entrevista a usuarios, no es algo que ellos nos vayan a contar y si mostramos el concepto, la respuesta que nos den tampoco es de fiar. Hasta que no vean el uso real, no van a validar cómo se percibe cada una de esas funcionalidades. (View Highlight)
- Validando la usabilidad
La validación de la usabilidad es un tema con mucha profundidad. Aprovecho para recordar que si validas internamente con perfiles que no son el tipo de usuario que usará tu producto, no te van a dar toda la información que necesitas. Puede que te validen si un botón se ve o no se ve, pero no te van a validar si está toda la información que esperan y el flujo tiene sentido. Nosotros en Ontruck, invertimos mucho en validar la usabilidad con los conductores de camiones y con profesionales de logística. Su estado mental, el lenguaje y los detalles que necesitan no los teníamos internamente.
En este caso, 37signals puede validar la usabilidad internamente ya que tiene los usuarios que usarán el producto. La única funcionalidad que sí creo que sería relevante validar con personas externas es el time tracking ya que es principalmente usado por freelancers y profesionales que cobran por horas. (View Highlight)
- Lo que más me ha sorprendido es que no hayan tenido una beta con algunos cientos de clientes. Me extraña que hace dos o tres meses no abrieran el producto para que esos clientes empezaran a usar las funcionalidades que ya tenían construidas, coger su feedback y ver el uso real. Ellos dicen que no es su forma de trabajar. Solo lanzan la primera versión en producción cuando está completa. A su vez, dicen que una vez en producción van a recoger feedback e iterar. Así que como siempre, que algo esté completo es muy subjetivo.
¿Qué podrían haber ganado extra si hubiesen hecho esta beta privada?
- Tendrían feedback del uso real de las funcionalidades por parte de cientos de personas externas. Podrían haberlas refinado en base a ese feedback.
- Podrían haber priorizado alguna otra funcionalidad que no han hecho y aportara más que algunas que sí han hecho.
- Tendrían métricas de retención para lanzar con cierta confianza en que la gente migra y lo continúa usando. (View Highlight)
- Lanzar una beta hubiese requerido una buena coordinación del desarrollo de backend, frontend, iOS y Android para que estuviera lista una mínima versión hace tres meses. Quizás un área era más compleja, o tenían menos recursos o iban más retrasados.
Es cierto también que cuando abres una beta subes tu producto a producción, y al usarlo tus clientes en el día a día, adquieres una responsabilidad. El producto puede ser mínimo pero debe funcionar bien. Por tanto, no siempre te conviene hacerlo así. (View Highlight)
- Como siempre en producto, cada caso tiene su contexto, y debe seguir su propio camino. Tenemos que encontrar nuestro propio equilibrio entre quedarnos cortos de funcionalidades – y no conseguir que los usuarios cambien a usar nuestro producto o funcionalidad – o pasarnos de funcionalidades – con el consiguiente peligro de hacer funcionalidades no necesarias y el riesgo de alargar el proyecto al aumentar la complejidad.
Mi recomendación es siempre hablar con tus clientes y usuarios de manera frecuente. Tu debes fijar la visión. Pero tu probabilidad de éxito aumentará si haces apuestas informadas. (View Highlight)
