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.

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!

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.

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.