¿Es una ilusión validar antes de lanzar?
Decía Jason Fried que la validación es una ilusión. En mi experiencia, la investigación y la validación de los productos nos ayudan a desarrollar intuición de producto y a manejar la incertidumbre.
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.
¡Feliz año! Espero que hayas pasado unas felices fiestas y hayas descansado para empezar con energía este año. Yo lo he hecho, y empiezo el año con ganas de compartir muchas reflexiones.
El otro día Jason Fried, fundador y CEO de 37signals, publicó una reflexión de producto con el titulo “Validation is a mirage”. Me sorprendió, porque va en contra de mi experiencia y de lo que comparto. Me la guardé y la he releído varias veces. Te invito a leerla antes de seguir con esta newsletter. Dejo aquí algunas frases sobre las que reflexionaré.
There’s really only one real way to get as close to certain as possible. That’s to build the actual thing and make it actually available for anyone to try, use, and buy. Real usage on real things on real days during the course of real work is the only way to validate anything. And even then, it’s barely validation since there are so many other variables at play. Timing, marketing, pricing, messaging, etc.
You can’t validate something that doesn’t exist. You can’t validate an idea. You can’t validate someone’s guess. You can’t validate an abstraction. You can’t validate a sketch, or a wireframe, or an MVP that isn’t the actual product.
If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be. But make that, put it out there, and learn. If you want answers, you have to ask the question, and the question is: Market, what do you think of this completed version 1.0 of our product?
That said, there’s one common way to uncertainty: That’s to ask one more person their opinion. It’s easy to think the more opinions you have, the more certain you’ll be, but in practice it’s quite the opposite. If you ever want to be less sure of yourself, less confident in the outcome, just ask someone else what they think. It works every time.
Primero, el contexto
Siempre que alguien hace una reflexión o da un consejo, incluido a mi mismo, es importante entender su contexto. En este caso:
Jason es un gran profesional de producto con más de 30 años de experiencia en el mismo sector → Tiene mucha experiencia e intuición de producto en el sector de SaaS de gestión de proyectos, y algo menos en el sector de Email
Está actualmente lanzando su nuevo producto Hey Calendar → Ellos mismos son los usuarios por lo que llevan muchos meses usando su propio producto en su día a día
Sí, hay que lanzar el producto para terminar de validarlo
La línea de pensamiento de David es que para validar un producto hay que lanzarlo al mercado. Es la única manera de realmente saber si los usuarios lo usan, lo compran y cuál es su feedback real. Todo lo que hagamos anteriormente no nos va a dar esa validación completa.
¿Estoy de acuerdo? Yo estoy de acuerdo con la parte de que efectivamente hasta que no vemos el uso real no podemos dar el producto por validado. Puede que nos hayan dado buen feedback los usuarios en los tests, pero puede suceder que nuestro producto no solucione un problema suficientemente relevante para ellos. Puede suceder que nos hayamos quedado cortos con las funcionalidades, o que haya problemas a nivel legal o de integraciones para su adopción. Puede haber problema de pricing, o de cómo y a quién se lo vendemos.
Ahora bien, ¿Es realmente la validación de producto una ilusión? ¿O podemos aprender antes de lanzar?
Hacer producto es manejar incertidumbre
En cierta manera creo que hacer producto es manejar incertidumbre. Cuando estamos comenzando con un nuevo producto o una nueva funcionalidad, no sabemos exactamente qué problema realmente queremos resolver ni a qué segmento de usuarios, no sabemos la visión y no sabemos qué forma va a tener. Según vamos avanzando por el proceso de producto, vamos teniendo claro qué problema queremos resolver y a quién, fijamos una visión de hacia dónde queremos ir y vamos validando con los usuarios ciertas hipótesis y partes de la solución. Una vez lanzamos cada parte, vamos terminando de validar que todo lo que teníamos en nuestra mente era o no correcto.
Es importante interpretar las reflexiones de Jason bajo el prisma de que él está haciendo un producto del cual él mismo es el usuario y puede fijar su propia visión. Este contexto de cuando tú eres el usuario es muy distinto a cuando estás haciendo producto para otros clientes y usuarios.
Cuando fijábamos la visión del producto de Ontruck, necesitábamos entender el día a día y los problemas de nuestros clientes, fijar una visión, un roadmap del producto y validar con ellos que potencialmente tenía sentido lo que estábamos pensando. Nosotros no éramos los usuarios de nuestros productos. Necesitábamos estar cerca de nuestros clientes.
Quiero recalcar que el contexto influye mucho en la forma de hacer producto. Hace meses el CEO del Linear decía que ellos no necesitan por ahora Product Managers porque los ingenieros y diseñadores tienen todo el contexto. Los ingenieros son los propios usuarios de Linear. En el caso de los productos que hace 37signals ellos mismos son los propios usuarios también. Sin embargo, posiblemente el 90% de la industria hace productos que no usan ellos mismos. No hay dog-fooding.
Es clave desarrollar intuición de producto en el mercado en el que estés
En cierta manera me parece peligroso el consejo de Jason porque no es lo mismo llevar 30 años de experiencia en producto en un sector que ser un profesional con experiencia en producto en un nuevo sector que no conoces o incluso no tener experiencia en producto y estar aprendiendo. Está claro que tienes que desarrollar intuición de producto cuanto antes en el mercado en el que estés trabajando actualmente. Antes de fijar la visión, tienes que empaparte de toda la información que tengan los fundadores y directivos de tu empresa, tus managers, tus compañeros, las personas de ventas, de atención al cliente y por supuesto los clientes y usuarios.
Por tanto, si no tengo experiencia o tengo poca en el sector, ¿qué va a hacer que haga mejor trabajo? ¿Pensar yo mismo cómo creo que debe ser un nuevo producto o funcionalidad, programarlo y lanzarlo? ¿O plantear una solución, coger feedback de los clientes, entender ese feedback bien y programar una solución iterada? En mi experiencia, y lo que recomiendo, es lo segundo. Cuando no tenemos experiencia, un buen proceso de producto nos ayuda.
Yo en Ontruck hice mucho énfasis con el proceso de producto desde el comienzo. Estaba encima de todo Product Manager y Product Designer que entrara asegurándome que cumplían cada una de las fases, incluyendo el research con usuarios primero y luego la validación de las soluciones antes de programarse. ¿Por qué hacía eso? Porque las personas que fichábamos no tenían experiencia en logística. Por tanto, podían hacer muchísimas hipótesis que traían de otros sectores que no aplicaban aquí.
Cuanto más feedback y cuanto antes lo tuviéramos de nuestros clientes, más información teníamos para decidir qué hacer. ¿Siempre hacíamos caso al feedback de nuestros clientes? No, hay que interpretar lo que te dicen los clientes. No siempre hay que hacerles caso, pero hay que entender su contexto. El hecho de que todo el equipo de producto e ingeniería siguiera este proceso de producto, hizo que desarrolláramos en los squads esa intuición de producto y que nos ayudara a fijar esa visión de los productos de Ontruck con una buena base.
Por tanto, si creo que se puede validar antes de lanzar
Tengo muchos ejemplos de funcionalidades que estábamos yendo por un camino y al presentárselas a usuarios nos dieron feedback de temas que no habíamos caído y nos hicieron iterar. Esas validaciones, buscando estar equivocados, nos ayudaron a construir correctamente la primera versión de las funcionalidades, acertando con las soluciones y consiguiendo los objetivos que perseguíamos. Ocho años después de poner las primeras piedras, el producto tiene una gran solidez.
En mi experiencia, aprendes muchísimo cuando haces investigación y validación con usuarios. Los usuarios nos ayudan a entender diversos contextos, a darnos cuenta de temas que no teníamos en mente, a adaptar nuestro producto a diversos modelos mentales, a iterar los copys para reducir fricción y dudas, etc.
Recomiendo validar con 5-10 usuarios, de diversos segmentos. Empresas pequeñas vs grandes. Usuario nuevo vs antiguo. Usuario frecuente vs uso ocasional. Hombre vs Mujer. Edad mayor vs joven. Cuanta más diversidad tengas, más aprendizajes vas a tener. La diversidad la vas a tener que decidir en base a tu producto y mercado.
Estas validaciones nos van a dar información para manejar la incertidumbre que tenemos, para tener más confianza en lo que estamos pensando construir, en desarrollar más intuición de producto y en ir fijando más bloques sobre los que desarrollar la visión de producto. Yo no veo nada negativo en hacer research con usuarios y validar las soluciones que estamos planteando.
Obviamente, nosotros tenemos que tener el timón y fijar una visión. Los clientes y usuarios nos ayudan a que naveguemos en la dirección correcta. Precisamente, creo que el gran problema de nuestra industria es que demasiados equipos diseñan y construyen lo que alguien definió en una lista de requisitos, y luego nadie se preocupa si se usa.
Por tanto, en mi opinión, la validación no es una ilusión, la validación es necesaria.
Eso sí, validemos siguiendo las buenas prácticas
Recientemente alguien me comentaba que habían estado yendo por un camino incorrecto porque habían preguntado a los usuarios que les parecía una nueva funcionalidad que estaban pensando. Los usuarios les dijeron que era muy interesante pero luego cuando la lanzaron nadie la usó. Es un final esperado, no puedes preguntar a un usuario qué le parece. Tienes que entender su día a día y qué necesidades y problemas tiene y hacer producto acorde a eso.
Si hacemos las preguntas correctas, sí que podemos captar si el problema que estamos tratando de solucionar es relevante para el usuario. Con la conversación adecuada, podemos entender bien todo su contexto para asegurarnos de que la funcionalidad que vamos a lanzar es mínima y cumple con lo mínimo que necesitan para empezar.
Por ejemplo, hace un par de meses, ayudando a un founder con su producto pre-PMF, le animé a cobrar un setup fee de miles de euros a las empresas que querían probar su producto. Esto le ayudó a entender bien cuál era el pain real que tenían, y la solución por la que estaban dispuestos a pagar. El setup fee no era un objetivo per se, era simplemente una barrera artificial para asegurar que los clientes estaban realmente interesados.
Una gran cantidad de personas que habéis rellenado la Encuesta de Formación en Producto, Ingeniería y Datos (si no lo has hecho, te agradezco si lo haces), me habéis dicho que estaríais interesados en un curso que profundice en Product Discovery. Es claramente un tema relevante del que no hay muchas referencias.
¿Qué problemas te encuentras en tu día a día? ¿Cuándo te ha funcionado o no te ha funcionado validar con usuarios? Escríbeme y comentamos.
Si os interesa este tema, os aconsejo la charla de Lenny con Judd Antin (lideró research en Airbnb). Hacen follow-up de un artículo muy interesante que escribió Judd en Mayo, y que levantó muchas ampollas. En la charla Judd comparte su reflexión sobre:
Where user research went wrong over the past decade
The three types of research—macro, middle-range, and micro—and the purpose of each
How to effectively integrate researchers into the product development process
The “user-centered performance” phenomenon and why it’s a waste of time
Common tropes about PMs, from researchers
¡Buena semana!