¿Qué es el product discovery?

El product discovery o descubrimiento de producto son todas aquellas actividades orientadas a determinar qué producto debemos crear. A entender si merece la pena o no dedicar tiempo y dinero para crear un determinado software. El objetivo es obtener evidencia de que el producto tendrá viabilidad antes de si quiera escribir la primera línea de código, en cuatro apartados:

– Viabilidad de mercado o hipótesis de valor: ¿Pagarán los clientes por este producto o servicio?

– Usabilidad: ¿Los clientes pueden usarlo fácilmente?

– Viabilidad técnica: ¿Podremos crear el producto?

– Viabilidad de negocio: ¿El producto ofrece un modelo de negocio sólido y encaja dentro de la estrategia de la empresa?

Lo habitual será que el product manager orqueste estas actividades de descubrimiento, trabajando junto con el equipo de desarrollo, con especial mención a los diseñadores, y en colaboración con stakeholders y clientes.

Principios o ideas generales sobre product discovery

Algunos principios a tener en cuenta a la hora de afrontar el product discovery son los siguientes:

1/ No es responsabilidad de los clientes descubrir qué producto crear. Es más: no te fíes en exceso de lo que los clientes digan. Ten muy en cuenta su opinión, por supuesto, pero seamos conscientes de que una cosa es que el cliente diga que le encanta el prototipo que le hemos mostrado y otra bien distinta que ese mismo cliente use la solución una vez que esté desarrollada. Cuidado.

2/ Si la propuesta de valor es lo suficientemente potente, los clientes comprarán tu producto, incluso salvando problemas de usabilidad o relativos al canal de ventas. He visto webs que facturan millones de euros y que tienen una usabilidad pésima.

3/ Dicho lo anterior en 2/, lograr una buena experiencia de usuario suele ser más complicado que la programación del back-end y un factor determinante del éxito del producto.

4/ Muchas ideas no tendrán sentido y las descartaremos en la fase de discovery. Para eso justamente hacemos el discovery: si no conseguimos “pruebas” suficientes que acrediten el valor y viabilidad del producto, mejor no hacerlo. Mejor tirar una idea a la basura que un producto ya creado a la basura. Mucho mejor. Al mismo tiempo, respecto a aquellas ideas con potencial, es probable que requieran de varias iteraciones para que demuestren que de verdad funcionan, durante la fase de discovery o, incluso, una vez en producción.

5/ Lo decíamos antes y volvemos a insistir: implicar a los desarrolladores en el discovery es fundamental. Si la primera vez que los desarrolladores ven una idea es en la Sprint Planning, mal asunto. Significa que estos no han participado del proceso y que, como poco, la viabilidad técnica de la solución no ha sido valorada. Se trata de generar un entendimiento compartido antes de llegar a la Sprint Planning.

6/ El product manager no debe delegar el trabajo de discovery, pues se trata de una parte esencial de su rol.

Técnicas de product discovery

A continuación enumeramos y describimos sucintamente algunas de las principales técnicas de product discovery.

Técnica 1. Evaluación de oportunidades. Simplemente consiste en pararnos a responder a una serie de preguntas básicas sobre el producto:

– ¿Qué objetivo de negocio contribuirá a conseguir?

– ¿Cómo sabremos si el producto tiene éxito? (en jerga OKR, nos referimos al key result)

– ¿Qué problema solucionará a nuestros clientes?

– ¿A qué tipo de cliente nos dirigimos?

Si no podemos responder a estas preguntas de manera satisfactoria y clara, seguramente sea conveniente descartar la oportunidad.

Técnica 2. Creación de una nota de prensa sobre el producto, antes de que empecemos a trabajar en el mismo. Esta es más bien una técnica de validación interna, puesto que la nota de presa de prensa está destinada a nuestro propio equipo o a responsables de dentro de la organización. Si la nota de prensa no convence internamente, pocas posibilidades tendrá de cautivar a nuestros clientes. Es una técnica popularizada por Amazon. Donde digo nota de prensa digo también blog post, aquel que te gustaría publicar para anunciar el lanzamiento del nuevo producto o feature.

Una variante a la nota de prensa es la de elaborar una carta dirigida al CEO, escrita por un supuesto cliente que habla de las maravillas del producto y de cómo su vida ha mejorado gracias a este. La técnica también incluye una carta imaginaria escrita por el CEO al equipo de producto, en la que les felicita y explica cómo han ayudado a la empresa.

Técnica 3. Business model canvas.  Cuando en una empresa establecida estamos evaluando el crear un producto nuevo con un nuevo modelo de negocio asociado, o cuando estamos ante un nuevo producto que desembocará en la creación de una startup, una herramienta como el business model canvas o lienzo de modelos de negocio nos permite obtener una visión global sobre este y cómo interactúan todas sus patas.

Técnica 4. User story map. Su uso se ha popularizado en los últimos años, gracias a su sencillez y al hecho de que encaja a la perfección con Scrum & Agile, cuando se usan historias de usuario. Es una técnica que funciona muy bien en proyectos de consultoría de software, puesto que ayuda a dinamizar la tradicional recogida de requerimientos con el cliente. 

En esencia, consiste en identificar las actividades principales del cliente o usuario, y de ahí destilar las historias de usuario en una suerte de mapa.

Técnica 5. Programa de discovery. Esta técnica es singularmente interesante para productos B2B. Implica un enorme esfuerzo pero los resultados merecen la pena. Algunos de los pasos principales a tener en cuenta para su implantación son:

– Seleccionar a un mínimo de seis clientes potenciales. Si se trata de un producto B2C o C2C, se recomienda un grupo más amplio de al menos diez clientes o usuarios potenciales.

– Estos clientes deben tener un interés profundo en adquirir una solución al problema que experimentan.

– Los clientes deben estar dispuestos a dedicarnos su atención y tiempo. Se trata de que de verdad tengamos acceso a estos clientes y de que podamos trabajar colaborativamente con ellos.

– El objetivo del programa es descubrir y desarrollar una solución genérica para los clientes incluidos en el mismo –y para muchos otros-, no una solución ad hoc para cada uno de ellos. En todo caso, asumimos el compromiso de crear un producto que funcione realmente bien para estos clientes.

No es cuestión de que el producto incluya todas y cada una de las características que los clientes que participan en el programa pidan, sino de encontrar una única solución que sirva a todos.

5/ Contractualmente, dado que en el momento de iniciar el programa aún no tenemos el producto, lo lógico sería que los clientes involucrados paguen o empiecen a pagar una vez que el producto esté listo. En algunos casos, igual habremos acordado un adelanto…

6/ La ventaja del programa de discovery es que no solo lograremos un producto validado, sino también casos de estudio, clientes de referencia reales que el equipo de ventas podrá utilizar. Es importarte pactar que podremos utilizar sus nombres a estos efectos.  

Técnica 6. Entrevistas con clientes. En mi opinión esta es la técnica de discovery más simple y de mayor valor. Es algo tan básico como hablar con tus clientes. Preguntarles qué quieren, qué les gusta, qué no, etcétera. A mí me gusta hacer entrevistas una vez a la semana, y estar con en contacto continuo con el equipo de soporte para asegurarme un “suministro” continuo de usuarios con los que charlar. A veces aprenderemos más, otras menos si hay temas o problemas que se van repitiendo por distintos usuarios. Pero siempre se aprende algo.

En muchos casos llegaremos a establecer relaciones duraderas con ellos y podremos pedir su opinión y consejo respecto a features muy diversos. No obstante, recuerda: no es su responsabilidad decirnos qué producto hacer.

Técnica 7. Hacer soporte al cliente. Ayudar al cliente cuando está teniendo un problema puede hacernos descubrir un gran número de mejoras. En este otro post hablamos en profundidad sobre esta técnica de discovery.

Técnica 8. Hack days. Nos dan la oportunidad de involucrar a los ingenieros, formar equipos de trabajo diferentes a los habituales y crear prototipos funcionales en tiempo récord que, incluso, presentaremos a usuarios u a otros compañeros al final de la jornada.

Creo que es importante que los equipos trabajen sobre un tema u objetivo específico, a pesar de que esto limite su libertad; por ejemplo, “soluciones que mejoren la conversión del proceso de compra”. De lo contrario, y me ha pasado en más de una ocasión, terminamos con un “batiburrillo” de soluciones de prioridad cuestionable y que nunca llegarán a ver la luz.

Técnica 9. Prototipado. Los prototipos nos ayudan a aprender sobre una posible solución, a mucho menor coste que si desarrolláramos el producto al completo. Además, nos dan la oportunidad de colaborar y crear un entendimiento compartido en el equipo y dentro de la empresa. El nivel de fidelidad adecuado del prototipo dependerá de cada caso en particular. Comentamos seguidamente algunos tipos de prototipos:

– Prototipos para valorar la viabilidad técnica: así ocurrirá cuando el equipo de desarrollo quiera probar el rendimiento o la escalabilidad de una determinada tecnología, o cuando no tenga experiencia trabajando con esta, o cuando quiera integrar librerías o APIs de terceros que no hemos usado previamente, etcétera. En Scrum y Agile en general, esta investigación suele concebirse como spike.

– Prototipos “de cartón” orientados al usuario: pueden ser de baja fidelidad -unos meros wireframes– o de alta fidelidad –con diseños pixel perfect-, y pueden permitir que el usuario realice interacciones, realizando clics o introduciendo datos. Herramientas como InVision son de gran utilidad aquí. En la técnica 10 profundizamos al respecto.

– Prototipos en producción para captura de datos reales: en este caso, creamos una versión tal del producto a la que podamos enviar tráfico para obtener analíticas reales. Por ejemplo, podemos crear una página de aterrizaje y comprar tráfico en Google o Facebook, y medir cuántos usuarios realizan una determinada acción. La técnica 11 hace mención a esta clase de prototipos.

-Suele citarse también la técnica de prototipado de “Mago de Oz”, quizás un tanto en desuso en los últimos años, pero que puede ser interesante en según qué situaciones. Consiste en crear una experiencia de uso completamente real para el cliente o usuario, que no sabe que, “por detrás”, en realidad se sigue un proceso bastante manual. Por ejemplo, imaginemos que implementamos un proceso de validación de la identidad de los usuarios, donde estos piensan que todo está automatizado, cuando en realidad hay una persona haciendo la validación.

Técnica 10. Sesiones de user testing. Junto con las entrevistas, quizás las sesiones de user testing son la técnica de discovery más potente, y en la que nos serviremos de un prototipo elaborado previamente. La “receta” es la siguiente:

– Reclutamos a clientes o usuarios con quienes realizar el testeo.

– Preparamos el prototipo -normalmente elaborado por el product designer- y un guion para el usuario, es decir, qué acciones queremos que realice usando el prototipo.

– Lo conveniente es que a la sesión asistan el product manager, el product designer y alguno de los ingenieros, y que al menos uno tome notas.

– Mientras que el usuario utiliza el prototipo, será importante contenernos y guardar silencio en la medida de lo posible. Observemos. No guiemos o influyamos al tester en un sentido u otro.

– Aseguremos comida, e incluso algún obsequio para nuestros testers. He hecho muchas sesiones de “testing and pizza” y créeme, ¡la comida siempre ayuda!

Recuerdo unos de mis primeros tests de observación, con una plataforma web ya en producción. Pedí a la usuaria que, en primer lugar, hiciera login en su cuenta –que había creado previamente-. Tenía el área de notificaciones repleta, y pensé que sería ahí donde haría clic de inmediato –o, al menos, ese era el comportamiento deseado-. Para mi sorpresa, prácticamente hizo clic en todo menos en las notificaciones. Al cabo de un rato, ya no pude esperar más y le señalé que tenía no sé cuántas notificaciones sin leer: “Anda, ¡no las había visto!”, me dijo. Se trataba de un icono que indicaba el número de notificaciones pendientes, con el número en blanco sobre fondo gris, invisible para los usuarios.   

Por cierto, hay laboratorios para testear la usabilidad. No suelen ser baratos y a mi juicio crean un entorno demasiado artificial. Prefiero hacer mis propias sesiones, si bien pueden ser una opción a considerar.

Por otro lado, existen herramientas para testing en remoto como usertesting.com, que nos permiten seleccionar el perfil de testers, que siguen el guion que les facilitemos y responden a nuestras preguntas; luego recibiremos una grabación con todo. Estas herramientas no deben suplir a las sesiones presenciales, pero las complementan y amplían.

Técnica 11. Smoke test o test de demanda. En este caso, lo que queremos comprobar es si el producto que pensamos crear tiene interés de mercado suficiente. Para ello, creamos una landing page (o una sección en nuestra web si se trata de un producto ya existente) en la que mostramos la nueva propuesta o feature como si ya estuviera disponible. Cuando el usuario hace clic en el botón o CTA que hayamos definido, lo llevaremos a una página en la que explicamos que estamos estudiando desarrollar el mencionado producto y que nos gustaría hablar con ellos sobre este.

Me encanta la historia de los orígenes del e-commerce Percentil, que François Derbaix relata en su blog:

En aquel momento, a principios del 2012, era dudoso que este negocio pudiera funcionar en España. A diferencia de otros países, en España no había casi mercado de ropa de niños de segunda mano, ni online, ni offline. Ni de guasa podría funcionar por aquí, o ésto parecía.

Entonces hicieron lo que había que hacer: una prueba de mercado, un “click-test“, lanzar una web de prueba, anunciarla y ver si había demanda. Hicieron entonces una copia del código de Tot-a-lot, lo colgaron en un dominio cualquiera, lo rellenaron de productos ficticios (cogidos del mismo Thredup), y gastaron 500€ en Adwords y 500€ en Facebook Ads para anunciar esta web. Sólo era un test, era como una tienda online real, pero al final del proceso no había una pasarela de pago integrada (aunque si se podía introducir los datos de tarjeta de crédito y dar a “comprar”). La tasa de (casi-)conversión de esta web de prueba fue sorprendentemente alta: un 5% de casi-compra, donde el usuario había llegado al último paso antes de pagar y la web le informaba que lamentablemente se trataba de una prueba.

Técnica 12. A/B testing. La mitad de los usuarios reciben una versión A o de control, y la otra mitad una versión distinta o variante. Habitualmente, el A/B testing se utiliza como método de optimización de aplicaciones web o móviles. No obstante, cambios de mayor envergadura en la interfaz de usuario también pueden ser sometidos a A/B test. En este caso, seguramente querremos limitar el número de usuarios expuestos al test a no más del 10%, dependiendo del tráfico que reciba nuestra plataforma. Puede que tengamos nuestro propio sistema para hacer A/B tests o que utilicemos alguna herramienta como Optimizely o VWO.

Técnica 13. Grupo Alpha/Beta testing. Es un conjunto de usuarios a los que hemos invitado a formar parte de un grupo de “beta testers”, esto es, les daremos acceso a nuevas características y productos antes de su despliegue para la totalidad de usuarios, a cambio de su feedback –y puede que de otros incentivos, como descuentos o promociones-. Este programa de testeo con usuarios reales puede ayudarnos a detectar errores técnicos o de usabilidad que no hayan sido sacados a la palestra por otras técnicas de discovery o, incluso, llevarnos a formular replanteamientos más profundos.

Técnica 14. Análisis de datos “puro y duro”. Lo primero que hago por la mañana es revisar las analíticas principales. El product manager debe sentirse “como pez en el agua” estudiando los datos que recabamos respecto al uso y rentabilidad del producto. Cualquier equipo de producto debe contar, como mínimo, con:

– Analíticas básicas del sitio web o app, usando alguna herramienta como Google Analytics o similar.

– Panel de métricas procedente de nuestra base de datos. Hay herramientas como Looker que guardan las consultas SQL y permiten visualizar datos con facilidad. Otras como Geckoboard integran diversas fuentes y nos ayudan a configurar nuestro propio dashboard.

– Datos de facturación, ya provengan de nuestra base de datos o de un tercero como Stripe o Paypal.

– Lo ideal será que lo anterior nos ofrezca una visión sobre los embudos de conversión y cohortes de clientes.

– Quizás algún índice de satisfacción del cliente como el Net Promoter Score o similar.

Si no tenemos la capacidad de medir cómo se está usando ese nuevo feature que vamos a lanzar, casi mejor no lanzarlo. De lo contrario, evaluar su éxito o fracaso será misión imposible y “cuestión de gustos”. No podemos decidir a ciegas.

Técnica 15. Discovery Sprint. Este Sprint es una técnica de discovery ideada por el equipo de Google Ventures, diferente del Sprint o iteración en Scrum. El discovery Sprint es un plan intensivo de cinco días para pasar del análisis de un problema a la validación de un prototipo que le dé solución. Esta técnica se popularizó tras la publicación del libro Sprint: how to solve big problems and test new ideas in just five days.

Product discovery en Scrum y Agile. “Dual track”

Scrum nos dice que, al final de cada Sprint, tenemos que entregar un Incremento de producto usable, potencialmente desplegable. Working software, no meros prototipos. La Guía Scrum designa al Product Owner como responsable de maximizar el valor del producto, sin entrar en el cómo o siquiera mencionar el trabajo de discovery.

El problema surge cuando las actividades de discovery y de implementación de una determinada historia de usuario o elemento del Product Backlog no pueden realizarse en el mismo Sprint, por falta de tiempo. Es aquí donde surge el denominado Agile “dual track”, amado por unos y criticado por otros. “Dual track” reconoce la doble naturaleza del trabajo que hacen los equipos de producto: por un lado, el trabajo de descubrimiento, incluyendo el diseño de UX/UI; y, por otro, el trabajo de desarrollo o implementación. Asimismo, para afrontar esta dualidad, sugiere que el trabajo de discovery vaya una iteración o Sprint por delante del trabajo de implementación. Que el discovery preceda al development.

Lo importante, en todo caso, es que no se creen dos equipos diferentes –uno de discovery y otro de desarrollo-, sino que el mismo equipo sea responsable por el todo, aun admitiendo la indudable doble naturaleza del trabajo a realizar, que debe solaparse al máximo posible y desempeñarse de manera colaborativa entre product manager, diseñadores e ingenieros.