El pleasurable MVP de Hey Calendar
Esta semana reflexiono sobre el concepto de MVPs tras evaluar la primera versión de Hey Calendar. ¿Qué buscamos con un MVP? ¿Qué han hecho en este caso?
Te animo a echar un vistazo a los cursos que acabo de abrir para Mayo:
Fundamentals of Software Engineering si quieres tener una base técnica para trabajar mejor con ingeniería; puedes hacerlo a tu propio ritmo. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Fundamentals of Product Analytics si quieres empezar a ser analítico, empezando a analizar datos y definir KPIs y funnels. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Advanced Course in Product Analytics si quieres aprender a hacer análisis avanzados y conectar métricas de negocio con producto. La octava edición comienza el 30 de abril.
Advanced Course in Product Engineering si desde ingeniería o datos quieres acercarte a negocio y producto. La cuarta edición comienza el 30 de abril.
En la newsletter de la semana pasada planteaba si era una ilusión validar antes de lanzar. Esa reflexión surgió a partir de un post de Jason Fried, fundador y CEO de 37signals. Hoy reflexiono sobre MVPs tras haber visto la primera versión que han lanzado de su nuevo producto Hey Calendar.
Antes de entrar al tema, os recomiendo ver su página sobre el producto y el video de cuatro minutos que tienen en la cabecera donde resumen las funcionalidades. Verlo os dará más contexto sobre mi reflexión, y porque ver otros productos, sobre todo si son innovadores, nos amplía nuestra perspectiva e intuición de producto. Fijaros tanto en las funcionalidades como en los detalles de UX y UI.
Hace 15 años probaba todos los productos que salían en Hacker News. Me registraba y los exploraba. Quería absorber cómo habían resuelto los funnels de conversión, cómo habían diseñado las navegaciones, cómo comunicaban los problemas a resolver, cómo los resolvían, cómo escribían los copys, etc. Actualmente sigo probando bastantes productos nuevos. Si trabajas en Producto debes estar constantemente probando otros productos para aprender de ellos.
¿Es un MVP o una Primera Versión Muy Vitaminada?
Cuando vi el primer video que compartieron hace unas semanas con una demo más larga, lo primero que pensé fue: ¿no se han pasado de funcionalidades con la primera versión? Me planteé que posiblemente han tenido a clientes usándolo en estos meses pasados. Pregunté a Jason y me confirmó que no ha sido así. Lo han diseñado en base a su intuición, sin validación de usuarios, y no han tenido una beta con clientes.
Aparte de lo esperado en un calendario, han lanzado las siguientes funcionalidades en esta primera versión que no existen o no son comunes en otros productos de calendario:
Poner un nombre a cada día (e.g. Nombrar como “Aniversario de Boda” el 5 de mayo")
Poner una foto de fondo a un día (e.g. Poner la foto de tu madre en el día de su cumpleaños)
Definir y hacer seguimiento de hábitos directamente desde el calendario
Tener a mano un listado de tareas que debes hacer esta semana en algún momento
Poder resaltar un evento con un círculo
Tener un calendario donde guardes los eventos pendientes de confirmar
Tener un vistazo de un día, hora por hora
Poder marcar una cuenta atrás hasta un evento (e.g. Quedan 8 días para el viaje a Marruecos)
Poder hacer seguimiento de tiempo en tareas que no son eventos (e.g. Si quieres saber cuánto tiempo inviertes por cada tarea de tus clientes)
Entro a este nivel de detalle porque me resulta interesante analizar su decisión de lanzar esta primera versión. Claramente, no es un MVP. Hay mucho trabajo y mucho detalle detrás. ¿Por qué lo han hecho así? ¿Hubiese sido mejor decisión lanzar con solo algunas de esas nueve funcionalidades? ¿O ha sido un acierto invertir más tiempo y lanzar con más funcionalidades novedosas?
¿Qué buscamos con un MVP?
Suelo ver mucha confusión sobre este tema. Se entran en debates estériles sobre si un MVP (Minimum Viable Product) debe ser en su lugar Lovable (MLP), Marketable (MMP), Valuable (MVP), Usable (MUP), Feasible (MFP), Delightful (MDP) o Sellable (MSP). Las palabras importan, pero vamos por el mal camino cuando nos obsesionamos. Lo importante es el concepto, ¿qué queremos conseguir con un MVP?
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.
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.
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.
¿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.
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.
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.
¿Deberían haber tenido una beta con algunos clientes?
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.
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í.
Conclusión
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.
Y por cierto, yo uso y recomiendo Cron Calendar (lo compró Notion).
¿Qué casos de MVPs de productos o funcionalidades has tenido? ¿Cuáles han funcionado y cuáles no? ¿Qué has aprendido?
Te animo a echar un vistazo a los cursos que tengo abiertos:
Fundamentals of Software Engineering si quieres tener una base técnica para trabajar mejor con ingeniería. Es un curso que puedes hacer a tu ritmo.
Fundamentals of Product Analytics si quieres empezar a ser analítico. Es un curso que puedes hacer a tu ritmo.
Advanced Course in Product Engineering si desde ingeniería o datos quieres acercarte a negocio y producto. La tercera edición comienza el 14 de febrero. ¡Coméntaselo a tus compañeros!
En las próximas semanas decidiré que cursos nuevos organizaré durante Q2. ¡Gracias a todos los que habéis completado la Encuesta sobre Formación! Si no lo has hecho todavía, tienes hasta el viernes.
Muy interesante el artículo Javier. Me ha gustado el ejercicio de ver primero el video explicativo de la funcionalidad y luego leer el artículo. Además, el hecho de que el propio creador explique cómo y por qué ha hecho su producto así, y además que haya respondido a tus preguntas, da mucha información que no solemos tener en todos los casos.
Mi opinión personal: No existen blancos o negros, todo es gris. Sí entiendo que, como bien dices, si quieres sacar "otra app de calendario" tu primera versión tiene que venir cargadita para diferenciarte. Es verdad que me cuesta entender por qué no han hecho una beta privada, pero claro, también con este nivel de compañía, solo con el video de Jason en X, seguramente creen un hype enorme, mucha gente la use (Try Hey free) e iteren rápido... Lo bonito es que lo vamos a ver en directo y podremos opinar :). Gracias por tus artículos !