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

Posts from the ‘descubrimiento de mercados’ category

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) 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 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.
  • 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

En muchas ocasiones, el “ingrediente secreto” de una innovación de éxito está en identificar riesgos, priorizarlos y encontrar maneras creativas de eliminarlos.

Muchos directivos tienen (¿tenemos?) cableada en la cabeza la típica relación entre rentabilidad y riesgo de los activos financieros –a mayor riesgo, mayor rentabilidad– y la utilizan para medir nuevos negocios, productos y empresas. Desde ese punto de vista, que liga de manera estática ambas variables, el mayor riesgo es el precio a pagar por una mayor rentabilidad. Y, tal como prescriben las herramientas de análisis financiero al uso, aquellos nuevos proyectos cuya rentabilidad es inferior a la de otros proyectos con un nivel de riesgo equivalente sencillamente se quedan sin recursos para acometerlos.

Pero en realidad, como hemos dicho otras veces en este blog, la innovación se caracteriza por una serie de riesgos (tecnológicos, de mercado,  etc.) y las técnicas de reducción de la incertidumbre y de aprendizaje organizacional son imprescindibles en su eliminación y/o gestión. Por eso se agradecen artículos como “Beating the Odds When You Launch a New Venture”, de C. Gilbert y M. Eyring, que explican cómo la innovación de éxito no se basa en buscar la alta rentabilidad asociada a un riesgo elevado, sino en identificar rápidamente y eliminar sistemáticamente riesgos en el orden correcto y usando el nivel de recursos y los métodos más adecuados.

En el razonamiento de los autores resulta central la idea de que el valor y el riesgo de un nuevo producto o empresa están relacionados inversamente. Cuando reducimos el riesgo estamos aumentando el valor de la empresa. Pero es vital el orden en que abordamos estos riesgos, porque no todos son iguales. Por ejemplo, alguien interesado en lanzar un nuevo sitio web de comercio electrónico puede ir gestionando los riesgos a medida que se le van presentando -y probablemente el primero sería el diseño del sitio web. Sin embargo, a menos que primero confirme la demanda de los clientes éstos no van a comprar (por muy interactivo que sea el sitio) y si no responde a la pregunta del mix de producto es posible que se abastezca de productos que no va a poder vender.

Resolver rápidamente los riesgos más importantes acelera la curva de valor de la iniciativa o proyecto de que se trate. Gilbert y Eyring distinguen entre tres tipos de riesgos:

  • Riesgos fatales (deal-killer) son aquellos que si no se resuelven pueden dar al traste con toda la operación y habitualmente toman la forma de asunciones no justificadas o no contrastadas sobre las que se basa el negocio. Por ejemplo, ¿existe demanda para mi producto?
  • Riesgos que dependen de las decisiones tomadas (path-dependent) son aquellos que aparecen cuando el tomar la decisión o el camino equivocado (p.ej., la tecnología a aplicar, el mercado a abordar) podría significar la pérdida de grandes cantidades de tiempo y/o dinero.
  • Riesgos operativos que pueden resolverse sin gastar mucho tiempo ni dinero. Puesto que probablemente no vamos a tener dinero para resolverlos todos, aquí la clave está en cuáles y en qué orden se resuelven. La respuesta está en seleccionar aquéllos en los que el ratio de riesgo eliminado (o el consecuente aumento de valor) frente al coste del experimento necesario para eliminarlo –una especie de ROI del experimento– es más favorable.

Para hacer más predecible y eficiente la creación y gestión de nuevos productos y mercados es imprescindible identificar y priorizar sus riesgos y a continuación concebir y ejecutar experimentos que los resuelvan sistemáticamente. En cuanto a los tipos de experimentos más útiles, los autores distinguen dos:

  • Experimentos enfocados: se utilizan para eliminar un riesgo específico, habitualmente de tipo fatal o dependiente de las decisiones.
  • Experimentos integrados: están diseñados para comprobar cómo diversos elementos (el modelo de negocio, el producto, el mercado) funcionan conjuntamente. En esencia, implican lanzar el negocio –o una parte de él– en un ámbito restringido, p.ej., pilotos, prototipos, mercados de prueba.

Los grandes emprendedores no asumen riesgos: los gestionan. Determinar cuáles de las asunciones clave son correctas -y cuáles no- y hacer rápidamente los ajustes pertinentes marcan a menudo la diferencia entre el éxito y el fracaso.

Y tú ¿ya has identificado tu incertidumbre más importante?

12 comentarios

Las startups no suelen fracasar por falta de tecnología, sino de clientes. Y sin embargo, muchas se concentran en sus productos y no dan ese paso esencial de intentar conocer a sus potenciales clientes hasta que ya es demasiado tarde. Resulta primordial aprender lo máximo posible sobre ellos mediante un proceso sistemático e iterativo.

Steve Blank es un emprendedor en serie que después de más de 20 años en ocho startups tecnológicas  -en los sectores de semiconductores, ordenadores, videojuegos y software- y de sacar a bolsa su última compañía (E.piphany) se dedica entre otras cosas a la consultoría y a impartir clases de creación de empresas en las universidades de Stanford y Berkeley.

En su libro “The Four Steps to the Epiphany” sostiene que los enfoques de crecimiento de startups centrados en modelos de Desarrollo de Producto (p.ej., Stage-Gate) no bastan – aunque funcionen bien para lanzar un producto en un mercado establecido y bien definido. La realidad es que pocas startups saben cuál es su mercado y su mayor riesgo no es el desarrollo de productos, sino el descubrimiento y comprensión de sus clientes.

Para llegar a esa “revelación” Blank propone un método, que él denomina Customer Development, basado en estos principios:

  • Salir fuera del edificio. Como dice Blank “dentro del edificio de una startup no existen hechos, sólo opiniones” y es probable que nuestro plan de negocio no sea más que la plasmación de una visión. Necesitamos salir a la calle y contrastar nuestras hipótesis, descubrir si nuestra visión es real o tan solo una alucinación. Curiosamente, pronto empezaremos a entender quiénes podrían ser los clientes de nuestro producto y cómo llegar a ellos.
  • No todos los mercados son iguales. La clave de los diferentes retos y horizontes temporales que afrontan las startups está en el escenario de producto-mercado en el que se mueven. Blank define tres tipos básicos: crear un mercado completamente nuevo, introducir un nuevo producto en un mercado existente y resegmentar un mercado existente (mediante ofertas de nicho o bajo precio). El tipo de mercado afecta a su tamaño, a cómo evaluamos las necesidades del usuario, a la velocidad de adopción o a cómo debemos lanzar el producto. Como hemos dicho otras veces en este blog, todo depende del grado de innovación.
  • Encontrar un mercado para el producto tal como está especificado. No se trata de escuchar al máximo de potenciales clientes ni de incorporar al producto todas las funcionalidades que pidan. Nuestro objetivo es descubrir el mínimo conjunto de features que nos permita conseguir los primeros clientes. Tenemos que encontrar un mercado -cualquier mercado- para el producto tal como está actualmente especificado. Y si no encontramos ese mercado lo más sensato es iterar el concepto, contrastándolo cada vez con el conjunto de hechos que hemos ido recolectando sobre los potenciales clientes. Esta idea de buscar un mercado que valore los atributos actuales del producto es similar a la que Christensen prescribe para comercializar tecnologías disruptivas.
  • Earlyvangelists: los clientes más importantes. Constituyen una figura clave es nuestro esquema porque no sólo son entusiastas que reconocen el potencial del producto para resolver un problema crítico y pueden ayudar a difundir la novedad, sino que también son clientes visionarios que asumen el riesgo y lo compran.
  • Aprendizaje e iteración, en lugar de ejecución lineal. Todas las fases del proceso de Customer Development son iterativas. La propia naturaleza del proceso de búsqueda de un mercado garantiza que lo vamos a hacer mal varias veces, así que es mejor aceptarlo e intentar aprender lo máximo posible en cada iteración. La noción principal del modelo es que las startups deben  invertir tiempo con un enfoque de aprendizaje e iteración, antes de pasar a la ejecución. El criterio para pasar de un enfoque al otro es el llegar a un proceso de venta repetible, demostrado por clientes tempranos que pagan dinero por el producto.
  • No sustituye, sino que complementa al Desarrollo de Productos. Desarrollo de Clientes y Productos deben estar sincronizados y operar concertadamente. La peculiaridad de las startups es que éstas empiezan con una especificación de producto conocida y ajustan su Desarrollo de Producto a unos clientes desconocidos.

Las fases del proceso de Customer Development, tal como se presentan en el gráfico, son:

  1. Descubrimiento de Clientes. Consiste en descubrir si existen clientes para nuestra idea y si el problema que resolvemos es importante para ellos (y cuánto estarían dispuestos a pagar por el producto).
  2. Validación de Clientes. Construye un proceso de marketing y ventas repetible y escalable basado en las lecciones aprendidas vendiendo el producto a earlyvangelists.
  3. Creación de Clientes. Consiste en la generación de demanda y construcción de pipeline.
  4. Construcción de Empresa. Transición desde una organización basada en el aprendizaje hacia otra orientada a la ejecución.

Las dos primeras fases corroboran el modelo de negocio -mercado, clientes, valor percibido del producto, comprador, precio …- y están conectadas también en sentido inverso ya que si en la fase de Validación no encontramos suficientes clientes que compren el modelo vuelve a la fase de Descubrimiento para redescubrir qué necesitan (y están dispuestos a pagar) nuestros clientes, en un proceso que se conoce como “pivotar”.

Las ideas de Blank han tenido gran aceptación y el Desarrollo de Clientes se ha incorporado como una de las bases del concepto Lean Startup, definido inicialmente por Eric Ries en su blog. En conjunto, dichos pilares son:

  • El uso de plataformas basadas en software open source y gratuito.
  • La aplicación de metodologías de Desarrollo Ágil, que mejoran el uso de recursos y fomentan la creatividad en el desarrollo de productos.
  • La iteración rápida e intensiva centrada en el cliente, como por ejemplo la metodología de Customer Development.
19 comentarios

En este blog hemos hablado en varias ocasiones sobre las innovaciones discontinuas -las que abren nuevos negocios o crean categorías de producto- y sobre las dificultades para descubrir y entender sus (previamente inexistentes) mercados. Resulta evidente que las prácticas de gestión que han probado su eficacia en el caso de innovaciones incrementales (en cuanto a investigación de mercados, desarrollo de productos, etc.) pueden resultar contraproducentes en este otro escenario, donde las incertidumbres y los riesgos son mucho mayores.

Por eso nos hemos referido a diversos enfoques para alcanzar la necesaria comprensión del mercado en el caso de innovaciones discontinuas -que algunos expertos han denominado marketing expedicionario o marketing agnóstico- y que tienen en común el basarse en rápidas y baratas incursiones en el mercado que permiten a las empresas ir aprendiendo y replanteando su oferta. Con esta filosofía, las empresas que comercializan innovaciones discontinuas deben renunciar a acertar a la primera y han de concentrarse, según una expresión un tanto equívoca, en “fallar deprisa” para posteriormente enderezar el rumbo. Por eso lamentablemente algunos equiparan este enfoque a ir dando palos de ciego hasta que -un poco por casualidad- nos encontramos con el mercado deseado. Pero nada más lejos de la realidad.

En su clásico (y muy recomendable) artículo “Marketing and Discontinuous Innovation: The Probe and Learn Process”, los autores G. Lynn, J. Morone y A. Paulson analizan empresas con innovaciones discontinuas en varias áreas (fibra óptica, telefonía móvil, TAC, …) y sintetizan las prácticas comunes que les llevaron al éxito en su búsqueda de un mercado. Curiosamente, aunque en todos estos casos se utilizaron técnicas convencionales de investigación de mercados (tests de concepto, encuestas, análisis conjuntos, focus groups,…) la mayor parte de la información generada fue imprecisa o errónea y dejada de lado en el desarrollo de la innovación.

Estas prácticas de éxito se agrupan en un proceso que los autores denominan “Sondear y Aprender” y que se resume en las siguientes características:

  • El proceso consiste en introducir versiones iniciales del producto en una variedad de segmentos potenciales, aprender de estos experimentos e intentarlo otra vez.
  • Estos experimentos (incursiones en el mercado) tienen sentido como vehículos para el aprendizaje sobre las características de la tecnología, el mercado, los clientes, etc.
  • La pregunta clave no es cómo acertar con el producto a la primera, sino qué pasos hay que dar para generar la máxima información y maximizar el aprendizaje.
  • En lugar de un proceso analítico de búsqueda del mejor encaje producto-mercado, se utiliza uno de aproximación sucesiva basada en la experiencia real.
  • Como consecuencia, el proceso consume gran cantidad de tiempo y recursos y el camino hacia el éxito está plagado de sorpresas y vueltas atrás que hacen imprescindible una gran dosis de perseverancia.
  • ¿Cómo filtrar aquellas oportunidades a las que está justificado dedicar esos recursos y esfuerzos? Las oportunidades a perseguir tienen que encajar en el enfoque y el contexto estratégico de la empresa.

En definitiva, lo que los autores proponen para la comercialización de innovaciones discontinuas no es un proceso de “prueba y error” sino uno de “experimentar y aprender” de una manera deliberada y planificada mediante sucesivas incursiones en el mercado.

13 comentarios
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 509 seguidores

A %d blogueros les gusta esto: