Conversis Consulting – Marketing orientado a resultados para mercados tecnológicos

Posts from the ‘descubrimiento de mercados’ category

Después de varios años como la metodología imperante en el desarrollo de nuevos negocios se empiezan a alzar voces contra Lean Startup (algunas de ellas entre sus fundadores). Ciertos fracasos notables en su implementación y un nuevo escenario de emprendimiento que requiere otros enfoques de inversión y desarrollo nos llevan a reflexionar sobre la vigencia de este método.

Llevamos ya casi diez años aplicando el método de Lean Startup y es un buen momento para hacer balance. Como era de esperar, son muchas las voces críticas que abogan por una reforma del método o por declararlo como un fracaso y enterrarlo. La comunidad más fiel, por el contrario, sigue siendo partidaria de aplicarlo ciegamente, como si fuera el único enfoque válido (para algunos de estos fieles, debe resultar incomprensible que en la historia de la humanidad se hayan desarrollado negocios de éxito antes de que Lean Startup llegara para iluminarnos a todos ;-).

Una opinión reciente que ha tenido gran repercusión, por venir de donde viene, es la de Steve Blank (uno de los “padres” del método), que en un artículo “NewTV Is the Antithesis of a Lean Startup. Can It Work?” (versión ampliada en su blog con el intrigante título “Is the Lean Startup dead?”) reflexiona sobre alguna de las limitaciones del enfoque.

Blank se hace eco de la reciente noticia de que “Jeffrey Katzenberg Raises $1 Billion for Short-Form Video Venture”, en un ejemplo de comportamiento “anti-lean”, para analizar el nuevo entorno de financiación del emprendimiento y especular si Lean Startup sigue siendo vigente en él.

Un poco de historia

Lean StartupEl movimiento Lean Startup surgió como respuesta a la escasez de capital tras el estallido de la burbuja “puntocom” del año 2000. En aquella época las startups y sus inversores necesitaban una metodología para preservar su capital y sobrevivir el tiempo suficiente como para generar ingresos y beneficios. Y entonces ya no valían el mantra de “constrúyelo y vendrán” o la ventaja del primer entrante.  Necesitaban estar seguros de que lo que estaban construyendo era lo que los clientes necesitaban y de que su modelo de negocio podía tener éxito. Y sus suposiciones iniciales se mostraban equivocadas necesitaban un proceso que les permitiera cambiar pronto en el proceso, cuando los costes de cambio fueran pequeños.

Fue entonces cuando una generación de emprendedores y académicos (Steve Blank, Eric Ries, Alex Osterwalder) construyeron las herramientas y crearon un nuevo lenguaje para la innovación y el emprendimiento moderno. Desarrollaron Lean Startup como un stack basado en Modelos de Negocio / Customer Development / Desarrollo Ágil en el que los emprendedores en primer lugar mapean sus hipótesis sobre su modelo de negocio y después ponen a prueba esas hipótesis en el mercado real y usan una metodología de desarrollo iterativo e incremental para construir el producto. Un componente importante es la necesidad de realizar experimentos de Producto Mínimo Viable con un gran número de clientes para conseguir feedback inmediato. Y cuando lo emprendedores descubrían que sus hipótesis eran erróneas (como irremediablemente ocurría) el resultado no era una crisis sino un evento de aprendizaje llamado pivotar y una oportunidad para cambiar el modelo de negocio.

Según Blank, toda startup está en una carrera contra el tiempo. Tiene que llegar al encaje producto-mercado antes de quedarse sin dinero. Lean Startup tiene sentido cuando el capital es escaso y necesitamos mantener baja nuestra velocidad quemando dinero. Como resultado de Lean Startup los emprendedores ahora tienen herramientas que aceleran la búsqueda de clientes, aseguran que lo que se está construyendo satisface las necesidades de estos, recortan el tiempo de entrada en el mercado y reducen los costes de desarrollo.

De todos modos, como saben los lectores de este blog, los apóstoles de Lean Startup no fueron los primeros en proponer la experimentación en el mundo real como método para reducir los riesgos y descubrir mercados para un nuevo producto: antes existieron, por ejemplo, el Marketing Expedicionario de Hamel y Prahalad, el Marketing Agnóstico de Christensen, la Planificación Dirigida por Descubrimientos de McGrath y MacMillan, o el método Sondear & Aprender de Lynn, Morone y Paulson.

Lean Startup no es una garantía

Es obvio decir que Lean Startup no garantiza el éxito. Y probablemente el caso de aparente fracaso en la aplicación de Lean Startup del que más se ha hablado últimamente es el de General Electric (GE).

En 2012 el entonces CEO de General Electric, Jeffrey Immelt, llamó a Eric Ries. Quería insuflar en su organización la clase de energía emprendedora de la que Ries hablaba en su libro “The Lean Startup”. Aquello dio lugar al programa FastWorks en GE, que llegó a ser la implementación de Lean Startup más grande del mundo y que aplicó los métodos de Ries para reducir el tiempo de desarrollo, a la vez que mejoraba la calidad de los productos y su encaje en el mercado. FastWorks sirvió de inspiración y ejemplo a batallones de consultores que asesoraban sobre Lean Startups a las grandes organizaciones que querían transformarse e innovar más.

Sin embargo, a pesar de toda la inversión de tiempo, dinero y personas, los resultados y la cotización de GE no reflejaron las mejoras que se suponía que Lean Startup iba a aportar. Últimamente GE ha atravesado tiempos difíciles: ha sufrido pérdidas masivas y despidos e Immelt ha tenido que abandonar su puesto; GE ha incluso salido del índice Dow Jones, después de 100 años.

Y como todas las crisis requieren un chivo expiatorio muchos se apresuraron a culpar de la situación a la firme creencia de Immelt en Lean Statup. Y, según los críticos, incluso si no fue así directamente por lo menos Lean Startup sirvió para distraer a GE de su competencias y negocios esenciales. O tal vez la explicación sea que al mismo tiempo que GE aceleraba el desarrollo y mejoraba la calidad de, por ejemplo, las turbinas de gas, con el auge de las energías renovables sus clientes ya no compraran esas turbinas. O que GE estaba tan sumergida en unos negocios y unas prácticas tan caducos que un poco de Lean Startup no pudo cambiar esa inercia.

Obviamente estos análisis son simplistas e incompletos porque nos falta mucha información de contexto sobre el peso, importancia y alcance reales que se dio a Lean Startup dentro de la organización. Lo que sí parece dudoso es que una iniciativa que afectaba a una pequeña parte de una estructura gigante como GE haya llevado al traste a toda la empresa. Y también resulta paradójico que, en tiempos de incertidumbre y cambio, una metodología específicamente orientada a mitigar el riesgo como Lean Startup haya podido perjudicar a sus practicantes.

Entrando en una era de grandes apuestas

Algunos están vaticinando el fin de Lean Startup debido a que estamos entrando en una época de grandes apuestas, que requieren enormes inversiones. Por ejemplo, según Steve Case  estamos iniciando una “tercera ola” de Internet, posterior a la era social y móvil, en que las tecnologías de la Red estarán integradas en todo lo que hacemos y los productos que usamos. Sectores como la salud, la educación o el transporte, que hasta ahora se han visto marginalmente afectadas por la revolución tecnológica se verán impactadas por una conectividad ubicua que los emprendedores podrán aprovechar para innovar y crear disrupción.

Pero debido a que los productos en estas industrias son muy caros de crear y distribuir (pensemos en un medicamento) y suelen ser sectores muy regulados, para tener éxito en esta nueva ola las empresas tendrán que realizar cuantiosas inversiones financieras, desarrollar alianzas e intentar influir en las políticas de los gobiernos. Y como, según los detractores de Lean Startup, este método se aplica sólo a emprendimientos “baratos” con inversiones reducidas y visiones “pequeñas” y dedicadas a construir productos digitales, no resulta aplicable en el nuevo entorno. En definitiva, según ellos el nuevo rango de apuestas que hay que hacer deja fuera el enfoque Lean Startup y éste tiene los días contados.

Sin embargo, estas predicciones se basan en un concepto erróneo de Lean Startup. En realidad este método no tiene que ver con el tamaño de la inversión en innovación, sino con hacer las cosas adecuadas en el momento correcto, y es perfectamente aplicable a productos físicos. El que los orígenes de Lean Startup estén en emprendimientos frugales y productos digitales no implica que sus principios no se puedan aplicar en emprendimientos más financiados y productos de otra índole.

En el próximo post hablaremos de los límites de Lean Startup y de su vigencia en el nuevo escenario de abundancia de financiación.

El post “¿Tiene futuro Lean Startup? (1)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Estrategias de crecimiento en mercados tecnológicos y Marketing estratégico para empresas tecnológicas te pueden ayudar.]

Anuncios
Deja un comentario

¿Cómo acotar el espacio del problema a la hora de definir un producto? Entender las necesidades de los clientes es la primera etapa, como paso previo a expresarlas como un conjunto de requisitos.

En la primera parte de este post hablamos de la importancia de acotar el espacio del problema a la hora de desarrollar un producto. Como veremos en las siguientes entregas, esto se consigue en primer lugar entendiendo las necesidades de los clientes, para poder articularlas luego en forma de requisitos agnósticos respecto a la solución.

Cómo entender el problema del cliente

LInvestigación Clientesa comprensión de las necesidades de los clientes es uno de los temas más habituales de este blog. A continuación presentamos una breve panorámica de algunas de las técnicas que se aplican, con enlaces a otras entradas para los que queráis profundizar en este asunto. En resumen las técnicas para descubrir y entender problemas de mercado se pueden clasificar en cinco categorías, basadas en los siguientes aspectos:

Lo que los clientes dicen

Aquí se recogen las técnicas más tradicionales de investigación de mercados, tanto cualitativas (exploratorias) como cuantitativas (estadísticamente representativas), por ejemplo, entrevistas en profundidad, focus groups o encuestas. El foco de estas técnicas en la expresión del pensamiento consciente, y su dificultad para recoger necesidades no articuladas, no reconocidas o inconscientes han hecho que frecuentemente se complementen con herramientas provenientes de la Psicología tales como las técnicas proyectivas o el laddering. Últimamente la “netnografía” -el análisis de las publicaciones y comportamientos online espontáneos de los usuarios- ha venido a ampliar el repertorio de técnicas de esta categoría, aunque algunos la consideran a caballo entre ésta y la siguiente.

Lo que los clientes hacen

Se trata de técnicas que provienen del mundo de la Antropología y el Diseño y que consisten en “empatizar” con el cliente, bien observando directamente sus contextos, actitudes y comportamientos -para descubrir problemas no expresados, comportamientos compensatorios y limitaciones de los productos actuales- bien sumergiéndonos profundamente en dichas situaciones, para “sentir su dolor” en primera persona. Las visitas a clientes, las consultas contextuales, la investigación de factores humanos o el mapeado de experiencias de usuario son ejemplos de estas técnicas, que también nos ayudan a descubrir necesidades no expresadas o inconscientes.

Lo que los clientes construyen

En ocasiones, los usuarios avanzados “fabrican” soluciones para sus problemas más acuciantes. La técnica de los lead users nos permite de una manera sistemática no sólo aprovechar esa identificación de necesidades, sino también la innovación generada por los propios clientes. Con un enfoque diferente, la técnica de elicitación de metáforas nos permite sortear las limitaciones de la expresión consciente, la lógica y la verbalización al invitar a los clientes a elaborar collages a partir de fotografías y recortes de revistas que involucren sus canales de pensamiento y expresión no verbales (especialmente, visuales) y nos proporcionen información profunda sobre cómo conceptualizan un problema o experimentan un producto.

La interpretación del mercado

En lugar de preguntar u observar a los propios clientes, a veces es útil recurrir a “intérpretes” (expertos provenientes de ámbitos diversos) que analicen con nuevos ojos la experiencia global de los usuarios y nos ayuden a imaginar experiencias nuevas y no solicitadas. Éste enfoque nos sirve para descubrir necesidades anticipadas o inciertas y es habitual en lo que se conoce como innovación de significado o “dirigida por el diseño”.

La experimentación y aprendizaje en el mercado

Este enfoque, puesto de moda a raíz de las filosofías de Customer Development y Lean Startup, pero que cuenta con predecesores en forma de Marketing Expedicionario o Probe&Learn, consiste en realizar incursiones en el mercado real con versiones preliminares de la oferta que nos permitan validar el encaje problema/solución y el encaje producto/mercado e ir refinando dicha oferta.

Algunas de las técnicas y metodologías anteriores (por ejemplo, lead users, Customer Development) no son solo herramientas de investigación sino también de innovación en el sentido de que cubren todo el ciclo completo que va desde el descubrimiento de necesidades hasta la construcción del producto o solución.

Al final el método de investigación más adecuado depende del tipo de insight que deseemos obtener y de factores como nuestro grado de familiaridad con los clientes y sus necesidades y el de innovación de las soluciones que podemos proponer. Pero el éxito de nuestras investigaciones siempre va a depender de un factor clave: nuestra capacidad para desproveernos de nuestros prejuicios y opiniones preconcebidas; porque como dice el proverbio la empatía no consiste únicamente en caminar con los zapatos de otro, antes tienes que quitarte tus propios zapatos.

En la tercera parte de este post hablaremos de cómo destilar estas necesidades en forma de requisitos.

El post “Definiendo tu producto: explorando el espacio del problema (2)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

La definición del problema que va a resolver nuestro producto es un aspecto al que no se le suele prestar la debida atención. Hacerlo así y saltar prematuramente al diseño y a la implementación del producto (solución) puede traer consecuencias fatales.

Como hemos dicho más de una vez por estas páginas, esencialmente un producto es una solución a un problema de mercado. Para que haya una oportunidad para un producto debe existir un problema de mercado que sea lo suficientemente importante, urgente y generalizado dentro de un conjunto de potenciales clientes.

Espacios de problema y solución

Por eso en estrategia de producto hablamos de espacios de problema y de solución:

  • El espacio del problema es donde residen las necesidades que queremos que cubra nuestro producto. Este espacio se expresa en forma de problemas, necesidades, trabajos y objetivos que encontramos en los clientes y, a un nivel más bajo, de resultados deseados, requisitos, etc.
  • El espacio de la solución es donde residen los productos que aportamos para resolver esos problemas. Este espacio se expresa en términos de productos y soluciones y, a un nivel más bajo, de funcionalidades, prestaciones, características, atributos, especificaciones, etc. de dichos productos.

Al final, un producto de éxito es el que con mayor fortuna logra una intersección o mapeado óptimo entre los espacios de problema y de solución.

Espacio problema vs espacio solucionUna vez evaluada una oportunidad de mercado la primera fase en el desarrollo de un nuevo producto consiste en lo que algunos denominan Definición de producto, que consiste en descubrir y cuantificar esos problemas de mercado, y articularlos en forma de requisitos. Esta definición es un componente esencial de la estrategia de producto y una de las responsabilidades más importantes del Product Manager. De forma más o menos solapada con la Definición de producto, las actividades de Diseño crean una conceptualización, una funcionalidad y una experiencia de usuario para la solución y las de Implementación construyen dicha solución.

La decisión sobre qué problema vamos a resolver y para quién (y, por extensión, de los problemas que NO vamos a resolver) es la primera encrucijada clave de un producto.

No saltes demasiado pronto al espacio de solución

Uno de los errores más frecuentes que socavan las actividades de desarrollo de nuevos productos es saltar apresuradamente a concebir la solución sin haber llegado a comprender adecuadamente el espacio del problema. Especialmente en el caso de las empresas que deben comercializar nuevas tecnologías, la urgencia por aplicar éstas en soluciones hace que todo lo veamos desde la óptica de estas tecnologías y no dediquemos suficiente esfuerzo a entender y cuantificar los problemas de los clientes (como se suele decir, “al que tiene un martillo todo le parecen clavos”). La consecuencia es una mala comprensión de la verdadera naturaleza, importancia, urgencia y extensión del problema y de la variedad de soluciones alternativas que los clientes pueden utilizar para resolverlo.

Uno de los ejemplos más citados en la literatura sobre Product Managemente en relación a este tema es el del famoso “bolígrafo espacial”. Parece ser que en los pasados años sesenta, en plena carrera espacial entre americanos y soviéticos, ambos rivales se encontraron con la necesidad de dotar a sus astronautas de dispositivos para escribir en las naves espaciales, donde la falta de gravedad impedía el funcionamiento de bolígrafos y plumas convencionales. Los americanos se enfrascaron en un millonario proyecto para el desarrollo de un bolígrafo con un cartucho de tinta presurizado, capaz de funcionar en ausencia de gravedad. Por el contrario los soviéticos, que formularon el problema como “dispositivo para escribir en ausencia de gravedad”, dotaron a sus astronautas de… lapiceros. En conclusión, una mala comprensión del problema nos puede llevar a la construcción de productos inadecuados para el mercado.

¿Quiere esto decir que no deberíamos empezar con las fases de diseño hasta que no hayamos identificado y analizado exhaustivamente el problema de los clientes? Pues lo cierto es que no. Como veremos a continuación la comprensión de los problemas de mercado es una labor extremadamente difícil y a veces la mejor manera de acabar de entender las necesidades de los clientes, incluyendo su importancia y el grado de satisfacción con otras soluciones, es exponer a esos clientes a versiones preliminares de nuestros productos. Y de hecho, los nuevos enfoques ágiles en desarrollo de productos nos llevan a solapar las actividades de definición, diseño e implementación. Pero lo que siempre debemos impedir es que una insuficiente comprensión de las necesidades de mercado nos lleve a soluciones “miopes”.

El problema define el mercado

Como hemos dicho varias veces por aquí, el problema es el que crea y mide el mercado. No es sólo, como decía Theodore Levitt, que “la gente no quiere un taladro de un cuarto de pulgada, sino agujeros de un cuarto de pulgada”, en realidad probablemente lo que la gente quiere es un “método para fijar un cuadro a la pared de la manera más sencilla y menos invasiva posible”, abriendo el camino a otras soluciones como por ejemplo las fijaciones adhesivas.

Sólo cuando miramos al mercado desde el prisma del problema a resolver entendemos su magnitud y contra qué otras soluciones competimos. Un mercado no está específicamente ligado a un tipo de solución que cubre esas necesidades. Ése es el motivo por el cual solemos asistir a “disrupciones”, cuando un nuevo tipo de producto (espacio de solución) cubre mejor esas necesidades de mercado (espacio de problema).

En las siguientes entregas de este post pasaremos revista a las técnicas para entender los problemas de los clientes y a cómo expresarlos en forma de requisitos.

El post “Definiendo tu producto: explorando el espacio del problema (1)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

(ACTUALIZACIÓN IMPORTANTE: en febrero de 2015 Textalytics ha pasado a llamarse MeaningCloud)

En Daedalus llevamos algún tiempo explorando nuevos modelos de negocio para comercializar nuestras tecnologías semánticas. Estas tecnologías permiten extraer elementos de significado (personas, marcas, conceptos, temas, hechos, opiniones) del contenido no estructurado, para poder clasificarlo, recuperarlo, relacionarlo, interpretarlo y en general explotarlo mejor.

Como hemos comentado por aquí en otras ocasiones, para un pequeño fabricante de software con presencia principalmente local y que compite en un mercado muy rápido con algunos de los mayores players del sector tecnológico, los modelos de negocio basados en API (Application Programming Interface) constituyen una alternativa natural.

Daedalus ha estado colaborando con sus clientes, explorando durante más de un año diversos modelos de negocio basados en API. Estos experimentos en el mercado han cristalizado en Textalytics, un nuevo concepto de oferta semántica en modo SaaS.

Textalytics - Meaning as a Service

Textalytics, Meaning as a Service (ahora MeaningCloud) ofrece a aquellos desarrolladores / integradores que quieran incorporar procesamiento semántico avanzado a sus productos de manera eficaz, rápida y barata una funcionalidad multilenguaje de alto nivel. Contrariamente a otras ofertas de tecnología semántica en modo SaaS, Textalytics ofrece varias API, cada una de ellas con una funcionalidad específica y cercana a un dominio de aplicación, así como SDK, plug-ins… que hacen que el aprendizaje y el uso sea mucho más fácil, reduciendo el tiempo necesario para obtener resultados y el time-to-market.

Textalytics es Meaning as a Service en dos sentidos: primero, es un servicio web que extrae elementos de significado de todo tipo de contenidos no estructurados (documentos, conversaciones sociales…). En segundo lugar, e igualmente importante, empaqueta y publica esa funcionalidad de modo que tenga significado desde el punto de vista del negocio y del escenario de aplicación. Textalytics oculta la dificultad técnica y salva la brecha entre las API semánticas y los desarrolladores enfocados en su negocio, acelerando el aprendizaje y multiplicando la productividad.

De momento Texctalytics ha conseguido llamar la atención de los medios especializados y los analistas tecnológicos más importantes. Si queréis saber más podéis ir al blog de Daedalus o a las reseñas que hacen SemanticWeb o Programmable Web.

Pero si eres un desarrollador/integrador interesado en “semantizar” tus productos y aplicaciones de manera sencilla y sin riesgos te recomiendo que te registres gratis (hacerlo en MeaningCloud) y empieces a jugar con sus APIs.

Deja un comentario

Cuando ni siquiera conocemos bien el problema de mercado que queremos resolver es dudoso que las soluciones que planteemos sean correctas. Un proceso continuo e iterativo de descubrimiento y validación de producto nos ayuda a eliminar incertidumbres y a utilizar eficazmente nuestros recursos.

En escenarios de innovación con alta incertidumbre en cuanto a necesidades, clientes, tecnologías, etc. lo más seguro es que nuestras ideas estén equivocadas y que desarrollar  y lanzar el correspondiente producto sin una adecuada validación lleve al desastre.

Sin embargo, en años recientes mantras mal entendidos como el Fail Often, Fail Fast, Fail Cheap o el “Ready, Fire, Aim!” (especialmente en sectores donde resulta barato y rápido construir y “lanzar al mercado cualquier cosa y ver qué ocurre”) condujeron a una urgencia por implementar y comercializar el producto.

Pero ni siquiera en escenarios “sencillos” de necesidad-clientes-tecnología ésta es una buena estrategia. Cuando nuestra prioridad debería ser identificar y eliminar riesgos del modo más rápido y barato posible, construir y lanzar el producto real es generalmente la manera más lenta y cara de hacerlo.

Y, en cierto modo, las nuevas tendencias del Lean Startup y similares -con su énfasis en la validación del modelo de negocio, Producto Mínimo Viable, etc.- son una respuesta a los enormes riesgos de dicha estrategia.

Básicamente, en lugar de apresurarnos en construir y lanzar el producto, lo que deberíamos hacer es:

  1. Identificar un producto que valga la pena implementar (construir e intentar empezar a vender). Esto es lo que denominamos “descubrimiento del producto”.
  2. Identificar un producto que valga la pena escalar (fabricar, distribuir, comercializar… en volumen). Esto es lo que llamamos “validación del producto”.

Descubrir y Validar Producto

Y aunque ambas actividades son diferentes en muchos aspectos (como veremos a continuación) comparten algunas características:

  • Están basadas en la evidencia del mercado (capturada mediante experimentos)
  • Son procesos continuos e iterativos, constituidos por secuencias de experimentos que van despejando incertidumbres y que pueden llegar a refutar nuestras ideas y asunciones
  • Son desempeñadas por el conjunto del equipo de desarrollo de producto: Gestión de Producto, Diseño, Ingeniería…
  • Pueden tener un cierto grado de solapamiento y no ser secuenciales.

La óptica de descubrimiento y validación de producto nos permite superar el concepto de la captura de requisitos, la elaboración de especificaciones y la construcción como un proceso secuencial, programado y predecible. Y de este modo, sustituirlo por un proceso iterativo de definición, diseño e implementación de producto validado por el feedback de clientes y otros involucrados.

Descubre un producto que valga la pena construir

En primer lugar, necesitamos descubrir si existen clientes reales que tienen el problema y querrían el producto. Adicionalmente, necesitamos descubrir una solución al problema que sea útil, usable, deseable, factible y viable. Es decir, tenemos que identificar el mercado y conceptualizar el producto teniendo en cuenta las necesidades tanto de compradores como de usuarios, para inmediatamente contrastar esa oportunidad y ese concepto con los clientes y los involucrados internos de nuestra empresa (negocio, tecnología…).

El objetivo del descubrimiento de producto es llegar a una especificación (preliminar y no detallada) de un producto con las máximas probabilidades de tener éxito en el mercado, y hacerlo antes de invertir intensivamente en la construcción del producto. El descubrimiento de producto consiste en llegar a algo que valga la pena construir: su resultado es una especificación inicial de producto en la forma más adecuada para el escenario de que se trate (p. ej.: documento, prototipo anotado, backlog…)

Esta situación final del descubrimiento de producto es lo que se suele denominar “encaje problema / solución”.

Valida un producto que valga la pena escalar

Para validar necesitamos comprobar que hay clientes que compran el producto real (aunque sea en una versión preliminar), que lo usan y nos dan su feedback para mejorarlo. La clave está en encontrar compradores que “voten con su cartera” por nuestro producto y nos ayuden a refinarlo.

Para ello necesitamos encontrar esos clientes visionarios que aceptan trabajar con un producto inmaduro y que van a contribuir a su mejora y a su difusión (los earlyvangelists, según la terminología del Customer Development).  Es ahora cuando comprobamos que nuestro producto es realmente útil, usable, deseable, factible y viable.

La validación de producto consiste en llegar a algo que valga la pena escalar en cuanto a fabricación, distribución y comercialización (algo esencialmente importante cuando no se trata de aplicaciones web y contenidos digitales). Su resultado es un producto totalmente definido, diseñado y construido, un proceso de compra identificado en los clientes y un proceso de comercialización replicable.

Esta situación final de la validación del producto es lo que se suele denominar “encaje producto / mercado”.

Prácticas y herramientas

Las técnicas y herramientas angulares de este proceso son:

  • Entrevistas, encuestas, observaciones contextuales, etnografía, buyer personas, user personas, escenarios, etc. para estudiar y modelar a los clientes
  • Storyboards, mockups, prototipos, simulaciones y versiones preliminares y limitadas del producto para solicitar e incorporar su feedback.

Hasta hace relativamente pocos años muchas de estas herramientas eran caras, sólo estaban al alcance de las grandes empresas y se aplicaban principalmente en aquellos productos que resultan difíciles y costosos de fabricar (p. ej.: automóviles).

Sin embargo, las nuevas tecnologías de prototipado rápido, modelado, simulación, impresión 3D, etc. han abaratado enormemente los costes de obtención de feedback de los clientes. E iterar estos artefactos con los clientes permite no sólo recoger requisitos, explorar diseños alternativos y confirmar implementaciones, sino compartir y comunicar fielmente entre los distintos miembros del equipo: marketing, gestión de producto, ingeniería.

Especialmente en productos donde la experiencia de usuario es importante, el trabajo con prototipos durante el descubrimiento de productos es crucial para identificar personas y escenarios y definir el modelo de interacción y las líneas generales del look-and-feel. Cuando se tratan aspectos complejos de deseabilidad, usabilidad y utilidad necesitamos hacer el mayor número de experimentos con el coste más barato y a la mayor velocidad posible. Y en esas circunstancias los prototipos rápidos y desechables son mucho más eficaces y eficientes que malgastar valiosos recursos y ciclos de implementación. Hay que evitar usar un producto construido como el prototipo más ineficiente del mundo.

Por el contrario, cuando se trata de empezar a vender el producto, que los clientes nos ayuden a mejorarlo con sus sugerencias, identificar en qué segmentos se consigue más tracción… y a ser posible, ingresar algo de dinero en el proceso es inevitable utilizar un producto real. Las mejores prácticas sugieren empezar con versiones preliminares del producto, centradas en los elementos de valor para el cliente más diferenciales y que ejecuten extremadamente bien el “trabajo” que el producto debe hacer.

Muy relacionada con estos aspectos está la cuestión de cuál es la “fidelidad” de prototipos y Productos Mínimos Viables más adecuada en cada momento. Tal vez, en lugar de cumplir la prescripción habitual de “baja fidelidad” en las fases iniciales del desarrollo y “alta fidelidad” al final, la clave esté en aplicar la “fidelidad correcta”: analizar qué incertidumbre deseamos eliminar en cada momento y qué nivel de fidelidad y de costes son los más adecuados para cada caso.

Este post en “Marketing & Innovación”.

[Desarrollar nuevos productos basados en la tecnología plantea retos muy particulares. Descubra en este taller práctico cómo una función de Product Management orientada al mercado ayuda a desarrollar productos tecnológicos que los clientes quieran comprar.]

4 comentarios

La aplicación de una “ingeniería ágil” en el desarrollo de nuevos productos puede provocar que  la mayor parte del feedback del mercado se concentre durante las actividades de construcción del producto.  Pero esta realimentación puede ser tardía, cara e ineficaz.

Hace unos días, impartiendo un seminario sobre gestión de productos tecnológicos, alguien preguntó (con muy buen criterio) en qué se diferencian esos Productos Mínimos Viables de “baja fidelidad” ­-según la terminología de moda- que se utilizan para validar el encaje problema/solución y los tests de concepto del marketing tradicional. Y en mi opinión, la respuesta es: en nada… y en mucho:

Diseño Coche

  • Esencialmente, el objetivo es el mismo: validar el interés en un concepto o descripción preliminar del producto por parte de su mercado potencial antes de construirlo. El test de concepto empezó a aplicarse inicialmente en productos de consumo a principios del siglo XX y se ejecutaba presentando a potenciales compradores una descripción del (inexistente) producto con sus características y beneficios principales plasmados en una hoja de papel (o, más tarde, elaborados en forma de anuncio). Básicamente se trata de averiguar si el mercado podía percibir al potencial producto como algo que solucionara sus problemas, si estarían dispuestos a comprarlo frente a otras alternativas y cuánto podrían pagar por él. Tradicionalmente se han venido usando entrevistas en profundidad y focus groups para explorar y verificar cualitativamente ese encaje y cuestionarios sobre muestras significativas de compradores para validarlo cuantitativamente.
  • Lo que sí ha cambiado radicalmente son los medios. Herramientas audiovisuales de bajo coste (presentaciones, vídeos, animaciones) permiten presentar el concepto a los clientes de manera mucho más explícita, rica e interactiva. Y una simple página web que presente las bondades de nuestro futuro producto y dé opción a comprarlo, junto con un mínimo presupuesto de publicidad PPC que dirija tráfico hacia ella, han pasado a ser la forma más rápida y barata de validar un concepto.

Esto viene a colación de que las nuevas metodologías y herramientas para incorporar el feedback del mercado están afectando no sólo a la forma de realizar pruebas de concepto, sino a todas las actividades del desarrollo de nuevos productos. Especialmente en aquellos casos en que el producto a desarrollar es realmente nuevo (en cuanto a mercado, aplicación, tecnología, etc.) hemos aprendido que un proceso secuencial de requisitos-especificación-construcción (o cualquiera que sea el nombre que le demos) que no incorpore un input continuo de los clientes es ineficaz y suele conducir a productos que estos no quieren comprar.

Las filosofías lineales y secuenciales de desarrollo de nuevos productos, donde la opinión de los clientes permanece “desconectada” entre la prueba de concepto inicial y los tests alfa/beta (y los tests de mercado) con el producto ya terminado, hace mucho que dejaron de ser el único camino. Paulatinamente se han ido incorporando prácticas y técnicas provenientes de disciplinas como el marketing, el diseño y la ingeniería, que promueven un flujo continuo de feedback de los potenciales clientes a través de un proceso iterativo y concurrente de desarrollo del producto.

Una de esas técnicas es la implementación/ingeniería ágil de producto (un tema sobre el que últimamente hablamos mucho por aquí). Lamentablemente, la práctica actual en muchos equipos de desarrollo consiste en concentrar la mayor parte del esfuerzo de realimentación del mercado durante las iteraciones de Agile en fase de construcción del producto. Y posiblemente este comportamiento no es ajeno a una aplicación miope de la técnica del Producto Mínimo Viable (un concepto habitualmente mal entendido y con un nombre desastroso).

No dejes el feedback del mercado para la fase de construcción del producto

Pero la agilidad en la implementación no debe ocultar la necesidad de iterar, descubrir -y eventualmente “pivotar”- el producto antes de empezar a construirlo. Cuando en un post anterior hablábamos de las funciones de Definición, Diseño e Implementación del producto ya decíamos que en general no son actividades lineales y secuenciales, sino iterativas, solapadas y guiadas por el input del mercado. Concentrar el feedback de los clientes durante los sprints de la implementación puede ser tardío, lento, ineficiente… cuando no a veces imposible.

  • El feedback durante la construcción puede ser inútil si la iteración es imposible (o muy difícil) tal como ocurre en algunos sectores o tecnologías. Toda la flexibilidad y bajos costes de evolución en las industrias del software o los contenidos digitales se convierte en rigideces y dinero malgastado masivamente en sectores donde la tecnología, el consumo de materiales o el uso de equipamientos caros hacen prohibitiva la iteración.
  • El feedback durante la construcción puede serdemasiado tardío. Si entre las primeras pruebas de concepto (cualquiera que fuera su forma) y la primera iteración de la implementación no has tenido input de los clientes has estado volando a ciegas demasiado tiempo.
  • El feedback durante la construcción puede ser excesivamente lento y caro. Cuando estamos validando requisitos, funcionalidades, experiencias de usuario, etc. necesitamos realizar muchos experimentos de manera rápida y barata. Las semanas o meses del típico ciclo de sprint imponen unas latencias y unos costes excesivos sobre el proceso, comparado con las horas o días que se pueden conseguir con técnicas de prototipado y simulación.
  • El feedback durante la construcción puede ser ignorado. Aunque las metodologías de implementación ágil fomentan el aprendizaje y la adaptación, siempre es caro y difícil cambiar de dirección cuando se ha invertido un tiempo y un dinero considerables en un determinado enfoque o arquitectura.

Con esto no estoy ni mucho menos abogando por que en la fase de implementación no se aplique el feedback de los clientes ni la iteración (más bien al contrario). Lo que quiero decir es que ese input del mercado y esa iteración deben producirse desde antes, de manera más rápida y más barata y en un proceso continuo que abarque todas las actividades del desarrollo del producto. De todo ello hablaremos en el siguiente post, y especialmente de lo que significa “descubrir” un producto (una pista: no consiste en diseñarlo en detalle).

Este post en “Marketing & Innovación”.

[¿Estás interesado en identificar oportunidades de mercado, valorando y priorizando los riesgos? Este documento te enseña cómo descubrir y comprender mercados que todavía no existen.]

10 comentarios

¿Cómo descubrir las necesidades de un mercado? Las entrevistas en profundidad con clientes son la herramienta más sencilla y eficiente, en especial si se las combina con técnicas de observación y exploración.

Las entrevistas en profundidad con clientes -potenciales o actuales- son desde hace muchos años la herramienta básica de la investigación de mercados. Obviamente se trata de una investigación cualitativa, esencialmente exploratoria e inductiva, y centrada en el descubrimiento y la identificación de necesidades, preferencias y comportamientos. (Por el contrario, cuando buscamos la validación, la estimación o la predicción debemos recurrir a herramientas cuantitativas).

Como cualquier técnica de investigación basada en lo que el cliente dice (generalmente contaminado por la racionalidad, la lógica y la autocensura) las entrevistas adolecen de limitaciones en cuanto a su espontaneidad, sinceridad y expresión del pensamiento inconsciente. Sin embargo, como hemos dicho en otras ocasiones, combinando las entrevistas con técnicas de observación y exploración del pensamiento y el comportamiento de los clientes se pueden generar customer insights muy valiosos.

Ahora que los gurús del nuevo emprendimiento nos animan a “salir fuera del edificio” y a hablar con los clientes para descubrir mercados y validar modelos de negocio, las entrevistas en sus múltiples formatos -en persona, por videoconferencia, por teléfono… incluso por email- aportan flexibilidad, inmediatez y profundidad en el análisis a un coste razonable.

En post como “12 Tips for Customer Development Interviews”, “How to Structure (and get the most out of) Customer Development Interviews” o “10 Tips for Amazing Customer Development Interviews” podéis encontrar consejos muy útiles para sacar el máximo partido a las entrevistas con clientes en un contexto de Customer Development.

Por tratar de hacer alguna aportación adicional, en esta entrada nos vamos a centrar en el caso específico de entrevistas para descubrir necesidades de los clientes (es decir, intentamos identificar los problemas que quieren resolver, los trabajos que quieren realizar o los resultados que desean alcanzar: no buscamos soluciones, productos o features). Y nuestro objetivo debería ser descubrir un conjunto de dichas necesidades lo más completo posible, estructurado en temas o categorías y priorizado por los clientes.

Si no nos conformamos con “salir y preguntar a dos o tres amigos” y tomar nuestras decisiones a partir de una evidencia anecdótica, estas son algunas de las cosas que tendríamos que hacer:

Antes de la entrevista

  • No basta con entrevistar a tres o cuatro clientes (y menos si se trata de los clientes más accesibles o amigos). Si nuestro objetivo es el descubrimiento exhaustivo -cercano al 100%- de las necesidades de un segmento de clientes algunos estudios hablan de que para conseguirlo son necesarias entre 10 y 20 entrevistas (a potenciales clientes, clientes de soluciones alternativas, no usuarios, etc.) Si existen varios segmentos -caracterizados por diferentes necesidades y sus prioridades- hay que multiplicar esa horquilla por el número de segmentos.
  • Si no usamos una empresa externa de investigación de mercados sino que utilizamos recursos de nuestra compañía, es aconsejable crear equipos multidepartamentales de entrevistadores (p. ej., representantes de gestión de producto, marketing, tecnología). De este modo se consigue la involucración de los diferentes departamentos y todos tienen la oportunidad de escuchar de primera mano la voz del cliente y de hacer buenas preguntas.

Durante la entrevista

  • Aunque pueda resultar un consejo muy obvio, lo importante es escuchar al cliente (no hablar nosotros). Una proporción entre escuchar y hablar de 75%/25% se suele considerar adecuada. Es imprescindible hacer preguntas abiertas (en lugar de “Sí/No” o de respuesta múltiple), estar preparados para salirnos del guión si aparece un desvío interesante y, sobre todo, no pedir a los clientes que nos den soluciones sino ayudarles a identificar problemas.
  • Poner en contexto al cliente, contar y solicitar historias, hacerle evocar experiencias pasadas. Hacer preguntas directas e indirectas para que el cliente hable sobre situaciones específicas, no sobre conceptos abstractos.
  • No confundir opiniones con hechos. Estos últimos tienen más capacidad predictiva.
  • Entender el escenario del cliente, identificar las soluciones que usa actualmente para lidiar con el problema y descubrir el impacto y las consecuencias de no resolverlo adecuadamente.
  • Profundizar en las respuestas. Repreguntar e ir a las causas de los problemas (en ocasiones hay que llegar a la cuarta o quinta pregunta). Herramientas originadas en el campo de la psicología como el laddering, las técnicas proyectivas o la elicitación de metáforas pueden ayudar a indagar en necesidades, significados, motivaciones y valores.
  • Preservar las expresiones y el lenguaje del cliente. Si es posible, grabar en vídeo la entrevista. La manera de expresarse (y desde luego el lenguaje no verbal)  del cliente proporcionan mucha información sobre cómo percibe y experimenta el problema.

Después de la entrevista

  • Involucrar a los clientes en la estructuración y clasificación de las necesidades. Las entrevistas con los clientes suelen producir típicamente 100-200 frases que se consideran expresión de necesidades. Es imprescindible ordenas esas expresiones en categorías o jerarquías que definan los grandes “temas” o áreas de dichas necesidades. Mapas de afinidad y diagramas en árbol multinivel son herramientas útiles en este proceso, habitualmente realizado por el equipo que realiza la investigación. Sin embargo, se ha comprobado que en estos casos la clasificación suele acabar representando la división en departamentos de la propia empresa o el modo en que se construirá la solución. Es útil involucrar a los clientes para que la clasificación refleje cómo ellos experimentan el problema o usarían la solución.
  • Los clientes deben priorizar explícitamente las necesidades. Una vez clasificadas las necesidades se debe asignar a cada una un grado de importancia y un nivel de satisfacción con las soluciones actuales. Podemos estar tentados de hacer nosotros mismos esta priorización, por ejemplo utilizando la frecuencia con que una necesidad es mencionada por los clientes como un indicador de su importancia. Sorprendentemente se ha comprobado que los clientes no mencionan con mayor frecuencia las necesidades que más importantes les parecen. Es necesario aplicar técnicas complementarias de investigación de clientes para solicitar de ellos tanto la importancia como el nivel de satisfacción actual de las necesidades detectadas. Aquellas necesidades con mayor importancia para los clientes y que según ellos están menos cubiertas por las alternativas actuales ofrecen mayor oportunidad para el desarrollo de nuevas soluciones.

Las entrevistas en profundidad no solo son extraordinariamente útiles para descubrir (o validar) necesidades de mercado, también lo son para otros usos:

Como es natural, en cada caso hay que adaptar el guión y la ejecución de la entrevista a los objetivos que vayamos buscando. Y, por supuesto, allí donde las entrevistas no lleguen (necesidades latentes, nuevas tecnologías con aplicaciones desconocidas…) podemos complementarlas con herramientas tales como la etnografía, los lead users, la intuición guiada o la experimentación en el mercado.

Este post en “Marketing & Innovación”.

[Entender a los clientes es primordial a la hora de descubrir nuevos mercados, desarrollar ofertas o comercializar productos. Aprende en este documento cómo descubrir “customer insights” que revelen motivaciones y necesidades ocultas de los usuarios.]

5 comentarios

La técnica del Producto Mínimo Viable nos ayuda a despejar incógnitas sobre la viabilidad de nuestro negocio. Pero muchas veces la viabilidad no es nuestra incertidumbre más prioritaria.

Como decíamos en otro post, el Producto Mínimo Viable (MVP) es una técnica muy útil pero poco entendida. Hay quien considera que el MVP debe ser mínimo desde una perspectiva del usuario/cliente (“la funcionalidad mínima para que al usuario le resulte útil y nos pague”) y quien le da a esta característica la perspectiva del proveedor (“el experimento más sencillo y barato que podemos realizar para despejar una incertidumbre de negocio”).

Pero no podemos olvidar que el MVP es un enfoque cuyo objetivo último consiste en evitar el construir productos que los clientes no desean. Los campos del software y la Web 2.0 proporcionan ejemplos de MVPs que han llegado a ser muy habituales:

  • Presentaciones, animaciones, vídeos, mockups… para validar ideas, conceptos y diseños iniciales.
  • Smoke test con una landing page que describe los beneficios de nuestro nuevo -y todavía inexistente- producto e invita a sus visitantes a registrarse/comprar. Contabilizando esos clics obtenemos una medida del interés del futuro producto para sus potenciales clientes.  Habitualmente el tráfico hacia la página se compra con anuncios PPC.
  • La clásica técnica de pruebas  de usabilidad conocida como “Mago de Oz” o “Turco Mecánico”, que consiste en simular una cierta funcionalidad por medios manuales. Así podemos comprobar si una funcionalidad compleja -pero que todavía no hemos desarrollado-  le podría resultar útil a sus usuarios.

Como vemos, estas técnicas buscan despejar incertidumbres esenciales sin necesidad de embarcarse en la creación de un “producto” o algo similar por lo que el cliente vaya realmente a pagar. Por eso decíamos que el MVP no debe ser realmente un producto. En un MVP -como en todos los casos de investigación de mercado- la clave está en priorizar nuestras incertidumbres/hipótesis a validar, en definir qué información deseamos adquirir y en diseñar una manera creativa y barata de conseguirla.

En cuanto a cuáles son las incertidumbres más importantes relacionadas con un producto, la respuesta depende del caso y del punto de vista. Probablemente si le preguntamos a un partidario del design thinking nos dirá que la incertidumbre más importante es la “deseabilidad”, mientras que un entendido en experiencia de usuario optará por la “usabilidad”… y un ingeniero resaltará la “factibilidad”. En general, según diferentes enfoques y perfiles, solemos hablar de las siguientes áreas de experimentación y validación de un producto (a veces no totalmente disjuntas):

  • Deseable: ¿cuánto les gusta el producto a los usuarios? ¿quieren usarlo?
  • Útil: ¿cómo resuelve el producto los problemas de los usuarios? ¿les sirve para algo?
  • Usable: ¿el producto va a ser fácil de utilizar para sus usuarios? ¿pueden usarlo?
  • Factible: ¿vamos a poder construir el producto con la tecnología disponible?
  • Viable: ¿el producto va a ser un negocio rentable?

Así pues, si hablamos del Producto Mínimo Viable no hay razón para que no lo hagamos también de Productos Mínimos Factibles o Usables… o Deseables. Dependiendo del caso y el momento las incertidumbres prioritarias estarán en una u otra área. En un ejemplo extremo como podría ser un medicamento contra el cáncer los riesgos solo van a estar del lado de la factibilidad, ya que la deseabilidad, utilidad, viabilidad, etc. casi se dan por descontadas.

En la realidad, es posible que una cierta hipótesis -y el experimento correspondiente- esté a caballo de dos o más de estas áreas: por ejemplo, el precio puede tener que ver con la viabilidad pero también con la deseabilidad. Sin embargo, como dice el manual de Estadística deberíamos diseñar nuestros experimentos de modo que los resultados fueran atribuibles a una sola variable.

Este reciente énfasis en el desarrollo de productos dirigido por hipótesis viene motivado por la confluencia del mundo de la Web 2.0 y una serie de enfoques de diseño y experimentación aplicados a la innovación. Estos enfoques se popularizaron durante los últimos años del pasado siglo gracias a la disponibilidad y al abaratamiento de nuevas tecnologías. Técnicas como la simulación, el prototipado rápido o la química combinatoria han ayudado a construir experimentos y “prototipos de alta fidelidad” en las industrias de la automoción, los circuitos integrados, el software o la farmacia.

En sectores donde el desarrollo es enormemente caro, complejo y arriesgado, la experimentación ha servido para eliminar riesgos de todo tipo y en todas las fases del desarrollo (desde la concepción, no sólo en la verificación final). Pero estas técnicas sólo son eficaces si conllevan un cambio de mentalidad: un experimento que “falla” (que no confirma nuestras hipótesis) no es un fracaso, el único experimento que fracasa es el que no nos permite aprender nada. La clave está es utilizar estas técnicas desde el principio y -por supuesto- pensando en los prototipos como algo desechable que sirve para aprender, no como la base para el desarrollo del producto.

Siempre hay sorpresas y es mejor descubrirlas antes de construir el producto y de que éste se encuentre en fase beta… o liberado. Si no lo hacemos así el resultado sí que será realmente un fracaso en el que habremos utilizado a la organización de ingeniería/fabricación para construir el “prototipo más caro del mundo” y a los clientes reales como involuntarios (y decepcionados) “conejillos de indias”.

Para concluir, y volviendo al Producto Mínimo Viable, creo que es un caso de una idea muy buena (aunque no totalmente original) pero con un nombre muy desafortunado.

Este post en “Marketing & Innovación”.

[¿Estás interesado en identificar oportunidades de mercado, valorando y priorizando los riesgos? Este documento te enseña cómo descubrir y comprender mercados que todavía no existen.]

8 comentarios

Uno de los conceptos clave del “emprendimiento ágil” es el de Producto Mínimo Viable. Pero aunque la idea resulta intuitivamente atractiva y comprensible, la realidad es que se aplica de formas muy diferentes y existe una cierta confusión sobre lo que realmente significa en la práctica.

Sin duda uno de los conceptos más mencionados en los últimos dos años es el de Producto Mínimo Viable (MVP, Minimum Viable Product); tanto que no puedes hablar con un emprendedor 2.0 sin que te intente vender SU MVP. Esta técnica se suele aplicar en contextos de emprendimiento ágil (Lean Startup, Customer Development), originalmente en el mundo de las aplicaciones Web 2.0. En esencia se trata de un experimento controlado, consistente en salir al mercado con un producto preliminar que nos permita obtener feedback y medir resultados, aprender e iterar nuestro producto. Pero en este post me gustaría centrarme no tanto en lo que es el MVP como en algunos mitos y concepciones erróneas sobre él.

En primer lugar, la idea de experimentar en el mercado para ir refinando innovaciones discontinuas no es nueva (recordemos el Probe and Learn y otros enfoques) y el propio concepto de MVP tiene antecedentes muy ilustres en forma de Minimum Marketable Feature Set y otros.

Sin embargo, el MVP suele ser un concepto no muy bien entendido y aplicado, probablemente -y esto es mi opinión- porque incluso en el círculo de sus promotores (Eric Ries, Steve Blank, Ash Maurya…) la idea parece haber tenido varias versiones. (Aplicando la terminología al uso, diríamos que el MVP es un concepto que ha “pivotado” ;- ).

Por ejemplo, según Steve Blank uno de los principios del Customer Development es “salir de la oficina” y descubrir cuál es el conjunto mínimo de prestaciones por el que los clientes pagarán en la primera versión del producto.  Este conjunto mínimo es lo que ha pasado a llamarse “producto mínimo viable” y una manera de descubrirlo es preguntarse “¿Cuál es el problema más pequeño o menos complicado que los clientes nos pagarían por resolver?”. Como Steve explica, todavía no estamos comercializando nuestro producto a un público general, sino que estamos vendiendo nuestra visión a los visionarios –valga en este caso la redundancia- pero proporcionándoles inicialmente un conjunto mínimo de características. Estos visionarios-evangelizadores, que adoptarían y promoverían inicialmente el producto y nos proporcionarían feedback (y dinero) para iterarlo y mejorarlo, se denominan “earlyvangelists” en la jerga del Customer Development.

Por su parte, Eric Ries define el MVP como ese producto que posee solo aquellas prestaciones (y no más) que nos permiten despertar el interés de los early adopters, algunos de los cuales nos pagarán en dinero o nos proporcionarán feedback. Sin embargo, en otro post Eric define el MVP como esa versión de un nuevo producto que nos permite adquirir el máximo aprendizaje validado sobre los clientes con el mínimo esfuerzo. Aparentemente, según esta segunda definición el objetivo del MVP es más general que simplemente comprobar si los clientes nos dicen que están dispuestos a pagar… o si efectivamente pagan. Pero sobre todo, la diferencia más importante radica en el hecho de que en la primera definición quien decide cuándo se ha alcanzado el producto mínimo es el cliente (interesándose o pagando por él) y en la segunda definición es el proveedor (si el experimento le permite despejar una incertidumbre de negocio).

Creo que tanto la definición de Blank como la primera de Ries son demasiado restringidas y centradas en el MVP como “producto” orientado a que unos early adopters nos paguen con dinero y/o feedback. (Todos entendemos la diferencia entre un producto y, por ejemplo,  una presentación de un concepto ¿verdad?) Son definiciones obviamente influidas por los conceptos de Core Benefit / Generic Product de T. Levitt en los años 60, el de Minimum Marketable Feature Set de la Incremental Funding Methodology y el de “producto umbral” para vender en el early market antes de desarrollar un producto completo para “cruzar el abismo”. En esa línea, hace varios años que en este blog defendemos que salir al mercado con conjuntos de características reducidos -pero enfocados en “resolver bien un problema”– contribuye a reducir no sólo el time-to-market sino también el time-to-adoption de un nuevo producto.

Pero en una startup -o en el caso de una innovación discontinua- hay muchas incertidumbres relacionadas con el modelo de negocio en general que habría que despejar antes de descubrir si los visionarios pagan por nuestro producto y cómo nos pueden ayudar a mejorarlo. Por ejemplo: si hay un problema en el mercado, a cuánta gente afecta, cómo de importante y urgente es el problema para ellos, si existen soluciones/alternativas ya disponibles (seguro que sí, aunque solo sea el status quo), cuál es el grado de satisfacción con esas soluciones…

El problema de esas primeras definiciones es que pueden llevar a pensar que el MVP es uno, mínimo, viable y producto, cuando en realidad no tiene por qué ser ninguna de esas cosas.

El MVP no es único -como corresponde a cualquier proceso iterativo- y la naturaleza y contenido de cada MVP/experimento dependerá del aprendizaje que queramos adquirir o de la incertidumbre que queramos eliminar.  Nuestro proceso de aprendizaje en el mercado es en parte una sucesión de MVPs.

El MVP no es mínimo, al menos en un sentido “matémático”: no hay procedimiento infalible que nos permita definir el MVP en cada caso y el proceso depende en gran medida de nuestro buen juicio y el sentido común. Y no debe ser mínimo desde la perspectiva del usuario, sino desde nuestra perspectiva como experimentadores: debe ser el experimento más barato que nos permita capturar la información que necesitamos.

El MVP no es viable, en la interpretación habitual de viabilidad económico-financiera (a menos que por “viable” entendamos que “nos permite obtener un aprendizaje validado”). Aunque sí hay un caso particular en el que el MVP tiene esta característica: el de un MVP que consiste efectivamente en un experimento para comprobar la viabilidad del producto (¿los clientes compran y pagan? ¿cuánto? ¿en qué proporción? ¿cuánto nos cuesta conseguirlos como clientes?…)

Pero lo que radicalmente no debería ser un MVP es un producto (o una “versión” de un producto). Si tu primer MVP es algo parecido a un producto (que en su forma actual resulta útil a algún cliente y por lo que está dispuesto a pagar) estás prescindiendo del beneficio principal de este enfoque en cuanto a validación de las hipótesis básicas. Además, un producto -o algo parecido a él- suele exigir invertir cuantiosos recursos en desarrollo y una vez que este proceso está en marcha puede ser difícil cambiar sustancialmente el rumbo. Si esperas a tener algo desarrollado para hacer experimentos puede ser demasiado tarde.

Por eso prefiero definiciones de MVP como ésta (adaptada de Wikipedia): MVP es una estrategia dirigida a evitar el construir productos que los clientes no desean y que busca maximizar la información que se adquiere acerca de nuestros clientes por cada euro invertido. Es un proceso iterativo de generación de ideas, prototipado, recogida de datos, análisis y aprendizaje.

En un próximo post veremos algunos ejemplos de MVPs, hablaremos de cómo utilizar esta técnica para resolver incertidumbres de toda índole relacionadas con un nuevo producto y analizaremos el papel del prototipado en este proceso.

¿Qué opináis? ¿Cuál es vuestra experiencia con el MVP?

Este post en “Marketing & Innovación”.

[¿Estás interesado en identificar oportunidades de mercado, valorando y priorizando los riesgos? Este documento te enseña cómo descubrir y comprender mercados que todavía no existen. ]

11 comentarios

De planificar e intentar preverlo todo -incluso el desarrollo de un mercado totalmente nuevo- hemos pasado al extremo contrario: planificar es inútil, hay que lanzar el producto y “fallar deprisa”. Como en muchas otras cosas, la virtud está en el justo medio.

Durante las últimas semanas he tenido algunas conversaciones muy interesantes tanto con emprendedores como con inversores sobre la utilidad de los planes de negocio cuando se trata de productos/mercados realmente nuevos. Me han venido a la cabeza historias de hace algunos años, cuando trabajaba en una agencia pública de financiación de la I+D (el CDTI) y era política de la casa exigir a las empresas innovadoras unas previsiones financieras detalladas a cinco años de cualquier nuevo producto (desconozco si esto sigue siendo así)… unos números que se introducían en unos modelos de evaluación financiera para producir finalmente unas cifras de ROI totalmente inverosímiles.

En este blog hemos hablado muchas veces de cómo prever la demanda de un nuevo producto de manera mínimamente fiable es tanto más difícil cuanto mayor es su grado de innovación y de por qué en ese escenario de alta volatilidad y riesgo cualquier estrategia y planificación inicial van a ser papel mojado. Parafraseando a un famoso general prusiano, “Ningún plan de batalla (negocio) sobrevive al contacto con el enemigo (mercado)”.  Y mi experiencia en alguna startup me dice que la única cosa más estúpida que un plan de negocio irreal e ilusorio es perseverar en intentar cumplirlo … y repartir premios y castigos en función de ello.

Sin embargo, últimamente el péndulo de la planificación ha pasado al extremo contrario gracias a uno de los mantras de moda en la innovación y en emprendimiento, el famoso “Falla deprisa, falla barato”. Tal como hemos dicho en otras ocasiones, este concepto se ha sobresimplificado y malinterpretado y el problema es que se está tomando casi como un fin, en lugar de como un medio. Y es que, tal como parece desprenderse de este enfoque ¿quién necesita un plan de negocio? Mejor lancemos el producto y veamos qué pasa.

Para aquellos emprendedores que queráis explorar una visión contracorriente sobre el “fallar deprisa” os recomiendo “Why The ‘Fail Fast’ Mantra Needs to Fail, Fast” de Mark Suster, un empresario de éxito metido a inversor. En este post Mark critica la pereza intelectual, la incompetencia profesional y la irresponsabilidad y falta de ética con clientes, empleados e inversores de esta filosofía mal entendida.

Porque -como también hemos dicho por aquí- descubrir nuevos mercados y desarrollar nuevos productos no puede basarse en una “estrategia de palos de ciego”, sino en un proceso iterativo en el que resulta clave formular nuestras hipótesis, identificar y priorizar nuestros riesgos e incertidumbres y despejarlos mediante la experimentación en el mercado.  (Por cierto, para que no quepan dudas Mark Suster es un convencido de los enfoques tipo Customer Development, Lean Startup … y yo también pienso que son los más indicados en algunos casos.)

Y entonces, volviendo a la pregunta inicial ¿tenemos que hacer planes de negocio o no? ¿Valen realmente para algo o sólo para presentárselos a algún inversor con tendencia a la credulidad?

El propio Mark Suster nos propone una excelente reflexión en “Are Business Plans Still Necessary?” Para él, el Plan de Negocio no es un documento prolijo e irreal, sino un modelo financiero que sustancia nuestras hipótesis de negocio: quiénes (y cuántos) son nuestros clientes, qué precio están dispuestos a pagar, cuáles son los costes de proporcionarles nuestro producto/servicio y los de ganarlos como clientes,  qué cuota van a conseguir los productos competidores/alternativos,… y cuánto vamos a ganar. Como dice Mark, si no somos capaces de presentar una estimación mínimamente verosímil de estos números es porque probablemente no hemos hecho bien nuestros deberes.

¿Quiere esto decir que este plan inicial tiene que ser totalmente fiable? Por supuesto que no, ya sabemos que eso es imposible. Pero si el plan nos dice que no vamos a ganar dinero ni siquiera en el escenario más favorable es mejor que busquemos otra idea. No dejamos de pontificar sobre el Producto Mínimo Viable… ¿por qué no hablar antes del Plan Máximo Inviable? (tengo que conseguir el copyright del término antes de que se me adelante Eric ;- ). Imaginemos la situación: planteamos un escenario optimista y resulta que ni siquiera nos salen los números… ¡eso sí que es “fallar deprisa”, antes de haber gastado ni un solo euro en el desarrollo del producto!

Después de haber analizado/escrito personalmente unos cuantos planes de negocio, puedo decir que lo más importante de ellos no son las cifras sino

  • las asunciones o hipótesis en las que se basan dichas cifras (p.ej., tamaño del mercado potencial, cuota a alcanzar…)
  • la sensibilidad de las cifras respecto a las hipótesis (p.ej., si mi volumen de ingresos no es el previsto ¿puedo reducir costes de modo que los resultados no se resientan en exceso?)

Y por supuesto, el plan debe ser un documento vivo: a medida que vamos confirmando (o rechazando) hipótesis y validando (o pivotando) el modelo de negocio tenemos que ir rehaciéndolo, actualizando sus parámetros y recalculando sus previsiones. La planificación de negocio debe ser (igual que el descubrimiento del mercado o el desarrollo del producto) un proceso iterativo que puede empezar con un esfuerzo muy medido.

Para terminar, probablemente la frase que mejor describe la utilidad de los planes en escenarios de alta incertidumbre y competitividad es una de Dwight D. Eisenhower (otro general, esta vez más moderno): “Como preparación para la batalla siempre he descubierto que los planes son inútiles pero la planificación es indispensable.”

8 comentarios
A %d blogueros les gusta esto: