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

Posts from the ‘desarrollo de producto’ category

No todos los experimentos tienen por objetivo contrastar aspectos muy relacionados con la naturaleza, funcionalidad y experiencia del producto (los prototipos funcionales son uno de ellos). También es imprescindible confirmar las dimensiones relacionadas con la viabilidad del negocio.

Damos fin a nuestra serie sobre el papel de la experimentación en el descubrimiento y validación de productos, en este caso con experimentos para contrastar la viabilidad del negocio y prototipos funcionales para confirmar con alta fidelidad todos los aspectos del producto.

Experimentos de viabilidad

En general, el propósito de un producto para la empresa es construir a su alrededor un negocio rentable y escalable. Y sobre eso versan las hipótesis de viabilidad. El éxito de un producto en el mercado no sólo depende (principalmente) de los clientes: también hay que validar su encaje con otros componentes de nuestro proceso de generación de beneficios: marca, generación de demanda, fuerza comercial (sobre el terreno y remota), distribuidores, partners, finanzas, legal, dirección general. Estos son aspectos que a muchos product managers les suelen resultar incómodos (sobre todo si provienen del ámbito técnico) pero son los que contribuyen a dar entidad a su puesto como el “mini-CEO del producto”.

Experimento viabilidadEn fase de descubrimiento los experimentos de viabilidad implican exponer a los implicados de la organización (marketing, ventas, soporte…) a prototipos de producto, para validar las hipótesis que les afectan. Es una forma de crítica interna. No se trata de una sesión tipo demo comercial (el product manager pilota) ni de test de usabilidad (el usuario pilota) sino una sesión interactiva en la que se da al interesado la oportunidad de explorar el producto e identificar cualquier aspecto que pudiera ser un problema en fase de comercialización (por supuesto, no se trata de ocultarles nada, sino todo lo contrario).

Con este enfoque, a continuación se citan algunos de los departamentos afectados y las hipótesis que habría que validar con ellos:

  • Marketing: ¿El producto es consistente con la promesa de nuestra marca (lo que la gente espera de nosotros)? ¿Sería posible construir programas y actividades eficaces y eficientes de generación de demanda para el producto? ¿Implicaría un gran cambio de canales y técnicas?
  • Ventas: ¿El producto requiere una relación personal cercana para su venta? ¿O puede gestionarse con un modelo de inside sales remoto? ¿El precio del producto justifica la inversión en fuerza de ventas? ¿La actual formación y capacidades de los vendedores son adecuadas? ¿O habría que formarlos o contratar nuevo personal?
  • Soporte: ¿El producto requiere un modelo de soporte muy cercano? ¿La actual formación y capacidades del personal de soporte son adecuadas?
  • Desarrollo de negocio: ¿El nuevo producto encaja en nuestras relaciones actuales con partners y distribuidores? ¿Van a poder y querer apoyar el producto? ¿Entra en competencia o conflicto con sus actividades?
  • Legal: ¿El producto tiene implicaciones en cuanto a privacidad, cumplimiento normativo, propiedad intelectual o competencia que puedan traer problemas legales?
  • Finanzas: ¿La estructura de costes del producto es suficiente para sustentar una operación rentable?

Prototipo funcional

En ocasiones necesitamos validar hipótesis en fase de descubrimiento que hacen necesario recoger algunos datos de uso real del producto. Y, por supuesto, lo necesitamos conseguir sin invertir el dinero ni el tiempo que se necesita para construir el producto real, escalable y vendible.

Un prototipo funcional es una implementación limitada del producto, acotada en cuanto a sus casos de uso, UX, funcionalidad y prestaciones. Y típicamente carece de toda la productización que se requiere para el producto final en términos de rendimiento, escalabilidad, pruebas automatizadas, instrumentación de analítica, internacionalización, localización, etc.

El prototipo funcional es sustancialmente más pequeño que el futuro producto (y construido a una fracción de su coste, típicamente 5-10%) y basta con que funcione suficientemente bien como para evaluarlo y recoger datos sobre un conjunto reducido de casos de uso con un conjunto limitado de usuarios.

A diferencia de otros prototipos, éste contiene código funcional que debe ser desarrollado por el departamento de Ingeniería/Desarrollo/Tecnología (no por los diseñadores). Esencialmente es similar a un piloto del producto, pero en el caso del prototipo la implementación es provisional y, en general, desechable.

El prototipo funcional es una técnica que se presta a análisis cualitativos y cuantitativos, y sirve para validar aspectos de deseabilidad, utilidad, usabilidad, comprabilidad, factibilidad y viabilidad.

El camino por delante: validación del producto

Una vez comprobado el encaje Problema-Solución deberíamos acelerar las actividades de Implementación o construcción del producto propiamente dicho, para llegar a algo que sea funcional, replicable, seguro, fiable, escalable, mantenible, soportable por la organización… y facturable. La validación termina cuando se comprueba el encaje Producto-Mercado: hemos llegado a una versión mínima del producto que los clientes valoran, compran y nos ayudan a mejorar con su feedback, y hemos identificado un proceso comercial repetible.

Ingeniería ágil

La mejor práctica para la Implementación en muchos escenarios consiste en aplicar técnicas de ingeniería ágil (por ejemplo, Scum o Kanban). En ellas el feedback del mercado es continuo, pero ya no con artefactos desechables sino con un producto real en continua evolución y mejora. Este feedback nos permite ir iterando y refinando el producto a lo largo de su construcción.

Como durante el descubrimiento, tenemos que seguir sometiendo al producto (ahora, real) a experimentos cualitativos que contrasten su deseabilidad, utilidad, usabilidad, comprabilidad, factibilidad y viabilidad. Pero en esta fase, gracias a la analítica de producto,  cobran mucha más importancia los experimentos cuantitativos basados no ya en lo que los clientes dicen, sino en su comportamiento real (lo que hacen).

Analítica de producto

Especialmente en productos digitales (software, contenidos), pero en general en cualquier tipo de producto o servicio habilitado por software (y cada vez son más, desde los electrodomésticos a los servicios de retail que mezclan online y offline) la tecnología permite realizar una monitorización exhaustiva del uso de ellos que hacen los clientes: cuándo lo usan, durante cuánto tiempo, qué funciones son las más utilizadas… Nunca había sido tan fácil saber exactamente cómo usan nuestro producto los clientes.

En “Analítica del funnel en negocios SaaS” describíamos cómo analizar la experiencia de cliente en negocios de software como servicio, pero lo que allí decíamos puede aplicarse fácilmente a negocios de otra índole, con tal de que su funnel comercial y su producto estén instrumentados para recoger los datos necesarios para realizar estos análisis.

Algunas técnicas y aspectos clave, muchos de los cuales hemos cubierto en posts anteriores:

  • Definición del funnel que mejor representa a nuestro producto (p. ej.: Awareness, Acquisition, Activation, Retention, Referral, Revenue) para estructurar el análisis.
  • La importancia de la retención de los clientes como motor del crecimiento: si no optimizamos la retención de nuestro producto estaremos acelerando un funnel con “escapes”. Métricas de abandono (churn).
  • Experimentos A/B y multivariable: donde se comparan diferentes alternativas de procesos y experiencias de cliente, para medir cuál se comporta mejor.
  • Análisis de cohortes: para analizar las diferencias entre grupos homogéneos de usuarios (p. ej., los que provienen de un mismo canal o se registraron el mismo mes).
  • Economías unitarias: CLTV (Customer Lifetime Value) y CAC (Customer Acquisition Cost).

Y con esto termina nuestra serie sobre la experimentación y su valor para el descubrimiento y validación de productos. Espero haber aportado una panorámica mínimamente descriptiva de los experimentos más habituales. Pero recordad: la idoneidad de uno u otro para vuestro caso depende de cuáles sean las incertidumbres más importantes para vuestro negocio y de cuál es la mejor manera para eliminarlas.

El post “Experimenta para descubrir y validar tu producto (4)” 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 Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

Un aspecto primordial a gestionar en el descubrimiento de un producto es todo lo relacionado con la implementación técnica: cómo y en qué momento invertir en demostrar que la funcionalidad del producto es valiosa y cómo confirmar que es factible. Para eso sirven experimentos como el Mago de Oz y los prototipos de factibilidad.

Seguimos con la descripción de experimentos de descubrimiento de producto, en esta ocasión prototipos de alta fidelidad para comprobar la utilidad, usabilidad, deseabilidad, comprabilidad y factibilidad.

Mockups y prototipos interactivos

Los mockups son el siguiente paso en cuanto a fidelidad de los prototipos, alcanzando un nivel medio. No van más allá del nivel de UI, los hay estáticos (pantallas aisladas) e interactivos (“clicables”) y suelen tener “perfección de píxel” en su calidad visual pero no exponen funcionalidad real y, a veces, tampoco interacción (modalidades estáticas).

Loa mockups se suelen construir combinando aplicaciones de diseño gráfico (para conseguir la máxima fidelidad gráfica) y herramientas de prototipado para dotarlas de interactiviad y permitir la compartición en equipo, iteración, etc.

Los prototipos interactivos son un paso más allá en cuanto a fidelidad sobre los mockups, al estar típicamente implementados con las tecnologías y lenguajes en los que se programa la UI del producto final. En ellos, la fidelidad gráfica y de interacción es prácticamente perfecta (aunque la funcionalidad no esté implementada).

Los mockups presentan una “carcasa” de media fidelidad del producto y son aptos para una experimentación cualitativa, centrada en validar aspectos de deseabilidad, utilidad, usabilidad y comprabilidad con un mayor nivel de fiabilidad que los wireframes. Al presentar fielmente elementos sensoriales, los mockups nos permiten validar componentes estéticos, de refuerzo de acciones de usuario, de tono de la comunicación, de reacción emocional y de consistencia y creación de marca.

Mago de Oz

El experimento de Mago de Oz o de “Turco Mecánico” o “Los Picapiedra” es un paso hacia la fidelidad funcional de los prototipos, si bien se trata de una fidelidad simulada. Consiste en proporcionar el producto (aunque sea en una versión mínima), con sus características gráficas y de interacción completas, pero con la funcionalidad que se busca implementada por medios manuales. En ningún caso esta circunstancia debería ser conocida por el evaluador, que cree estar enfrentándose a una versión preliminar del producto real. Obviamente esta técnica sólo es útil en escenarios donde la funcionalidad prevista del producto pueda ser simulada por medios humanos con un mínimo de calidad, verosimilitud y eficiencia.

Mago de OzEs decir, por ejemplo, en lugar de desarrollar esa tecnología de inteligencia artificial que necesitaríamos para implementar realmente el producto, la simulamos con un pequeño batallón de personas. De este modo podemos validar de una forma muy completa el valor de la solución sin acometer los costes de implementación (obviamente, los tiempos de respuesta y la escalabilidad del montaje no van a ser los óptimos, pero supongamos que en este entorno las expectativas de los evaluadores se pueden manejar).

Como hemos dicho antes, el experimento Mago de Oz se suele confundir con el Concierge (descrito antes), pero se diferencian en que en este último el evaluador era totalmente conocedor del proceso manual y que, en lugar de ser una técnica generadora de ideas, el Mago de Oz es totalmente evaluativa.

Como tal, Mago de Oz es una técnica eminentemente cualitativa (aunque también se presta a implementaciones cuantitativas basadas en analítica de producto), centrada en validar aspectos de deseabilidad, utilidad, usabilidad y comprabilidad (evidentemente, NO de factibilidad técnica).

Prototipos de factibilidad

Con los experimentos de factibilidad la empresa trata de contrastar las hipótesis relacionadas con su capacidad para entregar el producto con las características necesarias de funcionalidad, rendimiento, replicabilidad, escalabilidad, seguridad, fiabilidad, soportabilidad, etc.

Por ejemplo, actualmente con la incorporación de la inteligencia artificial a escenarios innovadores, este paso es obligado para descubrir si estas tecnologías se pueden adaptar a las nuevas aplicaciones y si los productos resultantes poseen las características técnicas y operativas imprescindibles.

Estos son riesgos que, dependiendo del contexto, pueden ser tan importantes como para tener que eliminarlos cuanto antes, de ahí la necesidad de hacerlo en fase de descubrimiento de producto. Los experimentos de factibilidad suelen consistir en prototipos donde se implementa el “motor” tecnológico de la solución (evitando sofisticaciones de UX) y se evalúan sus parámetros de calidad funcional y técnica. Un prototipo de factibilidad es equivalente a una prueba de concepto (PoC) de uso interno.

Además, involucrar a los departamentos de Ingeniería/Desarrollo/Tecnología desde las primeras fases del desarrollo del producto es importante y beneficioso porque

  • De ese modo se consigue su participación, interés y compromiso desde el principio
  • El tener conocimiento de los problemas de los clientes y de la solución que se está diseñando desde el inicio les permite planificar y acometer con tiempo y garantías la cuestión de la factibilidad
  • De este modo, no sólo van a traer buenas respuestas sobre la factibilidad, sino que aportarán mejores maneras de resolver el problema, gracias a su conocimiento sobre las soluciones innovadoras que habilitan las últimas tecnologías.

En el próximo post hablaremos de experimentos de viabilidad (negocio) y prototipos funcionales, y del camino por delante en cuanto a validación del producto.

El post “Experimenta para descubrir y validar tu producto (3)” 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 Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

La experimentación en el mercado nos ayuda en todas las actividades del descubrimiento de producto: desde la generación de ideas de diseño, a la prueba del concepto, a la validación de aspectos de experiencia de usuario y su impacto en la deseabilidad, utilidad, usabilidad y comprabilidad.

Empezamos a describir los diferentes tipos de experimentos para la fase de descubrimiento de un producto, centrándonos en algunos tipos que nos permiten generar soluciones e idearlo (concierge), probar el concepto (smoke test) y validar aspectos básicos de deseabilidad, usabilidad y utilidad (bocetos y wireframes).

Los experimentos como investigación de mercado

En tanto que herramientas de investigación de mercados, los experimentos nos proporcionan información de dos tipos:

  • Cualitativa : se trata de una investigación exploratoria, que busca el descubrimiento y la identificación de aspectos relevantes. Tiene unos objetivos abiertos y flexibles y una significancia anecdótica: se extrae significado de cada interacción. Se suele decir que la investigación cualitativa busca entender el “¿por qué?”.
  • Cuantitativa: es una investigación descriptiva y causal, que busca la validación, la estimación, la relación y la predicción. Tiene unos objetivos específicos y bien definidos y una significancia estadística: se extrae significado analizando los resultados agregados. Habitualmente la investigación cuantitativa busca responder a “¿cuánto?” o “¿cuántos?”.

En general, para contrastar una hipótesis utilizamos insights híbridos: descubrimos insights cualitativamente, y los validamos cuantitativamente.

Tipos de experimentos

Generalmente, en fase de descubrimiento (cuando todavía no se ha construido el producto real) los experimentos consisten en MVPs basados en artefactos de tipo prototipo. Un prototipo es un artefacto que adelanta o reproduce algunas de las características del futuro producto, y que se pone en manos de los potenciales clientes para solicitar su feedback.

Un aspecto que caracteriza a los prototipos y otros experimentos es su “fidelidad”, que tiene varios aspectos:

  • Visual/gráfica: cómo de cerca está el prototipo de la imagen gráfica del producto final.
  • De interacción: cómo el prototipo refleja el comportamiento en cuanto a flujos y procesos del producto final (con independencia de la funcionalidad que haya detrás, que en muchos casos es simulada).
  • De funcionalidad: cómo de cerca está el prototipo de realizar la operativa y funciones del producto final de manera real.

Los prototipos son herramientas extraordinariamente útiles porque avivan la creatividad, permiten explorar opciones y validar hipótesis y mejorar la comunicación. De hecho, los beneficios principales de los prototipos no están sólo en experimentar en el mercado, sino también como herramienta de comunicación entre las áreas de la empresa involucradas en el desarrollo del producto, especialmente entre Gestión de Producto y Diseño con Ingeniería/Tecnología/Desarrollo.

Veamos a continuación algunos de los tipos de experimentos más utilizados.

Concierge

En el experimento concierge uno de nuestros expertos humanos se sienta codo a codo con el cliente para resolver manualmente su problema, como lo haría una empresa de consultoría tradicional (o el conserje de un hotel). El objetivo es entender mejor el problema del cliente y las características que debería poseer una buena solución al mismo (en cuanto a inputs, necesidades de configuración, interacción, resultados deseados, etc.).

ConciergeEl experimento concierge es útil para soluciones que esencialmente tratan de automatizar un proceso humano o para productos que se pueden simular manualmente.

Es un experimento cualitativo, que permite entender los drivers de valor para el cliente, y eminentemente generativo, enfocado en la generación de ideas para la posible solución.

El experimento concierge se suele confundir con el de tipo Mago de Oz (descrito aquí), aunque son fundamentalmente diferentes: el concierge no trata de ocultar el proceso manual (al contrario, lo hace explícito) y no trata de validar un producto sino de generar ideas para diseñarlo.

Smoke test y fake door

El smoke test o experimento de página de aterrizaje se utiliza para validar un concepto de producto y consiste en una página web a la que dirigimos potenciales clientes mediante anuncios y que contiene la descripción del producto que nos estamos planteando desarrollar y una llamada a la acción para que los visitantes puedan expresar su interés dejándonos su contacto para mantenerlos informados, apuntándose a una beta privada, consultando información sobre precios, etc.

La fake door se utiliza para validar una posible nueva feature en un producto ya existente y consiste en insertar el botón/enlace de acceso a la característica allí donde sería su lugar natural en el producto. Obviamente el acceso no lleva a la feature sino a una página informando de que ésta se encuentra en desarrollo. De este modo se mide el interés por la nueva característica.

Estos dos experimentos son de tipo cuantitativo, enfocados en la deseabilidad, utilidad y comprabilidad.

Bocetos a mano y wireframes

Los wireframes son una representación de baja fidelidad del producto que da idea de sus componentes y cómo se organizan (arquitectura de información). Son un modelo a nivel de UX y los hay estáticos (pantallas aisladas) e interactivos (“clicables”). No tienen “perfección de píxel”, sino que proporcionan una presentación esquemática y monocolor del layout del producto. Evitan incorporar imágenes reales para no distraer la atención del evaluador y presentan (en sus modalidades interactivas) una versión esquemática de la interacción y el flujo del producto, pero sin ninguna funcionalidad real.

Como paso previo a los wireframes encontramos los bocetos hechos a mano, que bosquejan el concepto, los componentes y (en ocasiones, usando métodos totalmente manuales) la interacción del producto. Por tanto, tienen incluso tienen menor fidelidad que los wireframes en todas las dimensiones. Son una herramienta útil para comunicar ideas internamente pero demasiado tosca para exponerla a la evaluación de los clientes (salvo en situaciones muy informales).

WireframeExisten herramientas especializadas en la construcción de wireframes, tanto de aplicaciones para ordenador como para móvil, que además proporcionan bibliotecas de componentes predefinidos y permiten compartirlas en un equipo e ir iterándolas.

Los wireframes presentan una “carcasa” de baja fidelidad del producto y son aptos para una experimentación cualitativa alrededor de la experiencia de usuario y  centrada en validar aspectos de deseabilidad, utilidad, usabilidad y comprabilidad.

En el siguiente posts hablaremos de experimentos de más alta fidelidad para descubrir la deseabilidad y la factibilidad del producto.

El post “Experimenta para descubrir y validar tu producto (2)” 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 Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

El desarrollo de productos está sujeto a incertidumbres y riesgos de toda índole. Las nuevas filosofías de desarrollo proponen la experimentación temprana, rápida y barata en el mercado para gestionar activamente y mitigar esos riesgos y conseguir el éxito.

A nadie le gusta invertir en desarrollar un producto que no vaya a gustar a sus potenciales clientes. La mejor manera de evitarlo es someterlo a lo que en este blog llamamos descubrimiento y validación del producto (siguiendo una nomenclatura paralela a la de Customer Development de Steve Blank):

  • El descubrimiento de producto consiste en identificar un (concepto de) producto que valga la pena construir. El descubrimiento se extiende a lo largo de las fases de Definición y Diseño del desarrollo de producto y termina cuando se comprueba el encaje Problema-Solución.
  • La validación de producto consiste en construir un producto que valga la pena replicar y escalar. La validación se extiende a lo largo de la fase de Implementación del desarrollo de producto y el inicio de su comercialización, y termina cuando se comprueba el encaje Producto-Mercado.

Experimentación en el mercadoIncorporar ingredientes de descubrimiento y validación durante el desarrollo de producto implica aplicar una mentalidad que asume que todo en este proceso está sometido a incertidumbres y tratamos de eliminar los riesgos lo antes posible, de la manera más barata y aplicando un modelo iterativo con continuo feedback del mercado.

Gestionando las incertidumbres

El proceso de descubrimiento y validación de producto consiste en ir contrastando las asunciones y suposiciones relacionadas con ese producto y su modelo de negocio de una manera sistemática y eficiente. Para ello podemos seguir el siguiente proceso:

  1. Identificar nuestras asunciones, p. ej., “Creemos que a nuestro mercado potencial le interesa mucho nuestro nuevo concepto de producto de herramienta de chat empresarial.”
  2. Concretar y convertir dichas asunciones en hipótesis falsables (por favor, dejemos de llamarlas hipótesis “falsificables”), que podamos contrastar, p. ej., “Si presentamos nuestro concepto a una muestra de su mercado potencial, más del 70% va a expresar interés y a solicitar más información.”
  3. Priorizar esas hipótesis en función de su incertidumbre (imprevisibilidad) y su potencial impacto (consecuencias) para el negocio.
  4. Ejecutar experimentos “mínimos” (en cuanto a consumo de recursos, tiempo y dinero) para intentar confirmar o refutar dichas hipótesis. A eso es a lo que vamos a dedicar los siguientes posts.

Las asunciones (y sus correspondientes hipótesis) pueden tener que ver esencialmente con los diferentes aspectos del producto y su negocio:

  • Deseabilidad: ¿cuánto les gusta el producto a los clientes? ¿es significativo para ellos? ¿van a querer adoptarlo?
  • Utilidad: ¿cómo resuelve el producto los problemas de los clientes? ¿les resulta valioso? ¿les sirve para algo?
  • Usabilidad: ¿el producto va a ser fácil de utilizar para sus clientes? ¿van a poder usarlo? ¿van a poder aprenderlo?
  • Comprabilidad: ¿el producto va a persuadir a los compradores del cliente? ¿los clientes van a querer (y poder) comprarlo? Esta característica es importante en productos donde los compradores y los usuarios del cliente no son las mismas personas y pueden tener objetivos diferentes.
  • Factibilidad: ¿vamos a poder construir el producto con la tecnología y los medios disponibles? ¿va a funcionar cumpliendo los requisitos de rendimiento, fiabilidad, etc.?
  • Viabilidad: ¿vamos a poder construir alrededor del producto un modelo de negocio rentable? ¿vamos a ganar dinero con él?

NOTA: algunas de estas características, como las del trinomio Deseable-Útil-Usable, se solapan.

Desde el punto de vista de la fase en el desarrollo de producto, las incertidumbres provienen de:

  • Definición: es la fase que tiene por objetivo conseguir una comprensión del cliente y sus problemas, sintetizados en personas, viajes, escenarios y requisitos de mercado. En esta fase las principales incertidumbres están en la naturaleza, importancia, extensión y cuantificación del problema a resolver.
  • Diseño: esta etapa culmina con la conceptualización de la solución y la generación de una propuesta de valor, una experiencia de cliente y una especificación funcional que sirvan de base para la construcción del producto. En esta etapa los principales riesgos provienen de que el cliente valore esta propuesta de solución y la juzgue como una respuesta adecuada a sus problemas.
  • Implementación: esta fase tiene por objetivo generar una especificación técnica y construir y probar la “unidad 0” del producto real. Aunque esta etapa es posterior a aquéllas durante las cuales se lleva a cabo el descubrimiento de producto, tiene todo el sentido adelantase en la gestión de riesgos y eliminar incertidumbres relacionadas con esta fase, que esencialmente tienen que ver con la factibilidad técnica y organizativa del producto.
  • Comercialización: en esta etapa tratamos de convertir el producto en un negocio rentable. Nuevamente, aunque se trata de una fase posterior al descubrimiento de producto, es conveniente adelantarse y eliminar incertidumbres que se manifestarán en esta etapa, y que básicamente tienen que ver con la viabilidad económica del negocio.

Experimentos

Los experimentos de producto en el mercado son la herramienta principal para el descubrimiento y validación. Es imprescindible experimentar antes y después de empezar a construir el producto. Ambos tipos de experimentos son valiosos y ambos tienen que llevarse a cabo. Pero experimentar antes de empezar a construir nos evita muchos riesgos y nos permite hacerlo con artefactos baratos y desechables, con un coste mucho más bajo y una velocidad mucho mayor que si utilizáramos producto real.

En los siguientes posts nos vamos a centrar en experimentos de distinto tipo, no en otras herramientas de investigación como pueden ser las entrevistas en profundidad, los focus groups, la observación e inmersión etnográficas en los contextos del cliente, las encuestas, etc.

El post “Experimenta para descubrir y validar tu producto (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 Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

A la hora de priorizar problemas de mercado para resolver con nuestro producto hay que tener en cuenta que no todos esos problemas son iguales desde el punto de vista de la satisfacción que producen en el cliente y de la rentabilidad financiera que aportan a la empresa.

Seguimos analizando enfoques para la priorización de problemas de mercado para resolver con nuestros productos, en este caso centrándonos en el modelo de Kano y el análisis Rentabilidad-Inversión.

El modelo de Kano

Este modelo, desarrollado por Noriaki Kano en los 1980s, trata de describir cómo conseguir la satisfacción del cliente resolviendo sus problemas o proporcionándole soluciones. Para ello utiliza un plano con estos ejes:

Modelo Kano

  • Grado de cobertura en la resolución del problema o necesidad, o beneficio o funcionalidad de la solución. Va desde lo muy malo, pasando por lo nulo, hasta lo excelente.
  • Nivel de satisfacción del cliente, en función del grado de cumplimiento. Va desde la frustración, pasando por lo neutro, hasta el entusiasmo.

IMPORTANTE: el grado de cobertura puede referirse tanto a problemas/necesidades como a soluciones/atributos y en cada caso el modelo de Kano se puede utilizar para priorizar respectivamente problemas a resolver o soluciones a entregar. En este escenario de priorización nos centraremos en el primer caso.

La enseñanza principal del modelo de Kano es que no todos los problemas de cliente son iguales desde el punto de vista de la satisfacción que producen en el cliente. Simplificando, el modelo de Kano clasifica los problemas en tres categorías principales:

  • Lineales, de rendimiento o unidimensionales: son los más “intuitivos”, su resolución aumenta la satisfacción y su no resolución aumenta la insatisfacción. Son necesidades lineales o “simétricas”. Por ejemplo, la distancia recorrida por litro de combustible en un automóvil o la duración de la batería en un portátil son necesidades de tipo rendimiento.
  • Requeridas (must-haves): Son necesidades “mínimas” o que se dan por descontadas para que los clientes estén satisfechos. Son asimétricas en el sentido de que su cumplimiento no produce satisfacción pero su incumplimiento produce gran insatisfacción. Por lo tanto, una vez alcanzado un cierto grado de cumplimiento no es necesario seguir invirtiendo en ella. El disponer de agua corriente en una habitación de hotel o la robustez en un teléfono móvil son necesidades requeridas.
  • De entusiasmo (delighters): son necesidades inesperadas que superan las expectativas de los clientes. También son necesidades asimétricas en el sentido de que su incumplimiento no produce insatisfacción pero su cumplimiento produce gran satisfacción. Hace unos años, la guía a la conducción en un automóvil o la pantalla gráfica táctil en un móvil eran necesidades de entusiasmo.

La categorización de las necesidades de nuestros clientes en un diagrama de Kano se puede hacer utilizando entrevistas y encuestas diseñadas a tal efecto.

Hay dos aspectos primordiales sobre el modelo de Kano:

  • Las categorías de las necesidades cambian con el tiempo. Lo que pudo ser hace tiempo una necesidad de entusiasmo evoluciona hacia una tipo rendimiento y terminar siendo una requerida. Imaginemos, por ejemplo, las pantallas táctiles en los móviles. La evolución de la tecnología, la competencia y las expectativas de los clientes hacen cambiar estas categorías a lo largo del tiempo.
  • Hay una jerarquía de necesidades. Al igual que ocurre con las necesidades humanas, desde el punto de vista de producto hay una jerarquía que va desde las más básicas y fundamentales hasta las más avanzadas. Esta jerarquía hace que primero tengamos que satisfacer las necesidades imprescindibles (requeridas) antes de pasar a las de rendimiento, para pasar finalmente a las de excitación.

El análisis basado en el modelo de Kano nos permite entender de una manera más profunda la relación entre la cobertura de necesidades (o beneficios para el cliente) y satisfacción del cliente, identificando las de obligado cumplimiento, optimizando la cobertura para maximizar la satisfacción, evitando situaciones de necesidades “infraservidas” y “sobreservidas”, identificando opciones para deleitar a los clientes y, en general, descubriendo oportunidades para una innovación basada en el valor.

El análisis Rentabilidad – Inversión

El análisis Rentabilidad – Inversión se puede usar para priorizar problemas/necesidades, aunque se ajusta de una manera más natural -en una fase posterior- a la priorización de funciones/características del producto ya diseñado. En este esquema, los problemas a resolver se evalúan según dos ejes:

  • Inversión: una medida del esfuerzo necesario para resolverlo.
  • Rentabilidad: una medida del resultado para la empresa de resolverlo. Este resultado está relacionado con el valor creado para el cliente al satisfacer esa necesidad.

Rentabilidad e inversión se pueden combinar en una medida de ROI:

ROI  = Rentabilidad / Inversión

Con estos parámetros, la regla consiste en priorizar problemas según su mayor valor de ROI y, en caso de empate (los ROIs coinciden), lo más sensato en muchas ocasiones es priorizar el que exige una inversión más baja.

Cuando se priorizan problemas puede resultar difícil cuantificar con precisión estas variables. Empezando por la inversión, que es muy dependiente de la solución que diseñemos. Por eso este modelo se usa más para priorizar soluciones, funcionalidades o características.

Pero tampoco es necesario llegar a una cuantificación precisa de estos parámetros, sino que muchas veces basta con estimar la posición relativa de unos problemas respecto a otros en el plano o cuantificar las variables en una escala bajo-medio-alto y dividiendo el plano en nueve sectores. Eso bastaría para llevar a cabo nuestra priorización de una manera aproximada.

Conclusión

En este post y su primera parte hemos descrito tres de los diversos esquemas mediante los cuales las empresas priorizan los problemas a resolver pos sus productos. Aunque los tres aportan perspectivas útiles ninguno de ellos proporciona una respuesta definitiva para resolver el problema de la priorización, por lo cual una buena idea puede ser combinarlos y aplicarlos según la información que necesitemos en cada momento:

  • El análisis Importancia – Satisfacción nos permite descubrir y evaluar oportunidades de creación de valor para los clientes.
  • El modelo de Kano nos ayuda a entender en profundidad la influencia de la cobertura de una necesidad en el grado de satisfacción de los clientes, permitiéndonos modular el esfuerzo a realizar en la resolución de cada problema para optimizar la satisfacción.
  • El análisis de Rentabilidad – Inversión, aunque más adaptado a la priorización de funcionalidades y características, cuando se aplica a la priorización de problemas y necesidades nos proporciona una medida de cómo la cobertura de las diferentes necesidades nos ayuda a alcanzar nuestros objetivos financieros.

El post “Definiendo tu producto: eligiendo problemas que valga la pena resolver (2)” 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 Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

Una empresa puede descubrir múltiples problemas de mercado por resolver. Investigar a los clientes para entender la importancia que dan a cada problema y el grado de satisfacción con las soluciones actuales nos ayuda a priorizar el desarrollo de producto.

Una de las etapas principales en el desarrollo de nuevos productos (o de nuevas características, o en la renovación de productos existentes) es la definición de dicho producto.  La definición de producto es un proceso iterativo que empieza con el descubrimiento de necesidades de los clientes, continúa con la construcción de personas de compradores y usuarios y sus “viajes” y escenarios de compra y uso, y termina con la elaboración de un conjunto de requisitos (problemas de mercado) priorizados. Como vemos, en esta fase nos mantenemos esencialmente inmersos en el espacio del problema, sin pasar todavía a la formulación y validación de una solución.

Como resultado de esas actividades previas de descubrimiento de clientes con suerte nos vamos a encontrar con un conjunto de expresiones de problema (en los términos usados por los propios clientes o transcritas a alguno de los formatos estructurados más habituales), en el mejor de los casos deduplicados y agrupados por temas en forma de mapas de afinidad o diagramas en árbol multinivel.

Y el siguiente paso es priorizar esos problemas a resolver con nuestro producto ¿Por qué es importante priorizar los problemas? Hay varias razones:

  • Porque lo más seguro es que no vayamos a tener recursos y dinero para resolverlos todos.
  • Porque aunque no fuera así, probablemente resolviéndolos todos llegaríamos a un “producto Franskenstein”, complejo y no centrado en ninguna persona en particular y que no satisface completamente a nadie, lo que lastra la satisfacción de los clientes y la adopción del producto.
  • Porque lo que nos interesa no es desarrollar y lanzar ciegamente un producto, sino continuar con un proceso de descubrimiento en el que -una vez elegidos los problemas de mercado a resolver- diseñemos una solución que habrá que validar con los clientes mediante prototipos y otros artefactos (antes de empezar a construir el producto real). Y para ello lo más útil es definir un producto “mínimo” que haga más fácil, rápido y económico ese proceso. Porque necesitamos empezar a recibir feedback del mercado cuanto antes y de la forma más barata posible.

Y es que esencialmente la estrategia (incluyendo la de producto) no consiste sólo en decidir lo que se va a hacer sino (y más importante) en decidir lo que NO se va a hacer.

Para la priorización de problemas de mercado podemos aplicar varios enfoques, que vamos a describir en éste y el siguiente post:

  • El marco Importancia-Satisfacción
  • El modelo de Kano
  • El análisis Rentabilidad-Inversión.

El marco Importancia – Satisfacción

Importancia Satisfacción

Este enfoque consiste en representar los problemas en un plano con dos ejes:

  • Importancia del problema: es una medida de cuán importante es un cierto problema, necesidad o beneficio para un cliente determinado. Por ejemplo, para una persona la necesidad de compartir fácilmente contenidos con sus amigos puede ser muy importante y menos importante la necesidad de privacidad. La importancia es un concepto específico del espacio del problema, independiente de cualquier tipo de solución.
  • Satisfacción con las soluciones actuales: es una medida de cuán satisfecho está un cliente con las soluciones actualmente disponibles para un problema determinado. Expresa en qué grado las soluciones actuales satisfacen los problemas de los clientes y nos ayuda a identificar necesidades “infraservidas” (y “sobreservidas”) con bajo nivel de satisfacción.

Es importante que tanto la importancia como la satisfacción sean evaluadas explícitamente por los clientes cuya opinión hemos recabado en nuestra investigación, y no sean “impresiones” del equipo investigador. De este modo nos aseguramos de capturar la forma en que los clientes perciben y expresan sus problemas y necesidades. Luego, la importancia y la satisfacción de cada problema se evalúan como un score calculado promediando sobre el conjunto de clientes.

Según sus scores agregados, los problemas pueden caer en uno de cuatro cuadrantes:

  • Alta Importancia, baja Satisfacción: este es un caso claro, representa la oportunidad de innovar resolviendo un problema que es importante pero que no está adecuadamente cubierto. La recomendación en este cuadrante es invertir.
  • Baja Importancia, alta Satisfación: este también es un caso claro, pero en sentido contrario. No hay mucha oportunidad en resolver un problema poco importante que además está adecuadamente cubierto con las soluciones actuales. La recomendación aquí es evitar.
  • Alta Importancia, alta Satisfacción: este es un escenario dudoso. Podemos encontrarnos ante un mercado interesante pero muy competitivo, donde resulte difícil hacerse un hueco. Sin embargo, la importancia del problema y la oportunidad de mercado pueden justificar invertir en desarrollar soluciones innovadoras.
  • Baja Importancia, baja satisfacción: finalmente, otro escenario dudoso. La baja satisfacción con las soluciones actuales puede abrir una oportunidad, pero la baja importancia del problema puede hacer que no valga la pena.

Podemos utilizar el marco Importancia – Satisfacción para obtener una medida del valor para el cliente creado por una cierta solución a un cierto problema:

Valor para el Cliente = Importancia x Satisfacción (área del rectángulo)

Análogamente, la oportunidad de creación de valor de un producto que incrementara el nivel de satisfacción de una necesidad desde un valor Satis0 hasta otro Satis1 (manteniendo constante la importancia en su valor Impor0) sería:

Oportunidad de Creación de Valor = Impor0 x (Satis1 – Satis0) (incremento de área)

El marco Importancia – Satisfacción nos permite evaluar diferentes oportunidades de creación de valor y centrarnos en las más prometedoras.

En el próximo post revisaremos otros dos enfoques para la priorización de problemas de mercado: el modelo de Kano y el análisis Rentabilidad-Inversión.

El post “Definiendo tu producto: eligiendo problemas que valga la pena resolver (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 Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

El desarrollo de productos de datos plantea retos que solo pueden contrarrestarse mediante la aplicación temprana de técnicas de diseño de producto. Por otra parte, para garantizar el éxito de estos productos a lo largo de todo su ciclo de vida es imprescindible la involucración de un buen Product Manager.

Finalizamos nuestra serie sobre productos basados en datos (ver aquí y aquí) hablando del papel que en ellos debe tener el diseño de producto y de cómo gestionarlos a lo largo de su ciclo de vida.

Diseño desde el principio

Los productos basados en datos son inherentemente complejos tanto desde el punto de vista de los problemas que resuelven como de las tecnologías involucradas, lo que hace difícil cumplir la promesa de valor para el cliente. Además específicamente plantean serios retos tanto en la entrada como en la presentación de los datos, que constituyen aspectos clave de la experiencia de usuario.

Diseño de productos de datosPor ello estos productos hacen imprescindible incorporar los roles de diseño desde el principio. Recordemos que el diseño de producto va mucho más allá del diseño visual y consiste en la conceptualización de la solución al problema que se quiere resolver, incluyendo su especificación funcional y su experiencia de usuario. Estos son algunos consejos para aplicar el diseño al desarrollo de productos basados en datos:

  • Diseña tu producto para que sea comprable, no solo usable. Hay que enfocarse en los compradores, no solo en los usuarios (cuando son distintos). Es necesario mirar más allá de los analistas que van a usar los datos, para descubrir a la gente que ve el valor y tiene el presupuesto para respaldar su interés. Es crucial conseguir que el producto sea comprable por diseño.
  • Diseña con datos reales. Cuando crees mockups de interfaz para mostrar a potenciales clientes usa datos reales. Los datos inventados que no tienen que ver con la realidad son peligrosos en la fase de diseño de un producto: perderemos inmediatamente el interés de cualquier cliente con el que queramos validar los resultados. Valida usando datos reales que cuenten historias reales de manera que los clientes puedan decirte cómo valoran las historias que estás contando con tu producto.
  • Entiende la diversa soltura de tus usuarios en el manejo de datos. Seguro que vamos a tener mucha variedad en la capacidad de los usuarios para trabajar con datos. ¿Cómo seducir a los “yonquis de los datos” a la vez que se da respuesta a los novatos?
  • Evita el “vómito de datos”. A los científicos de datos les encantan los datos en crudo porque saben cómo manejarlos, combinarlos, analizarlos y visualizarlos, pero la mayoría de nuestros clientes no tienen esa capacidad. Resulta natural desarrollar el producto que querríamos nosotros, pero es muy fácil sobreestimar las capacidades de nuestros usuarios. Uno de los mayores retos de desarrollar un producto de datos es decidir cómo se le van a devolver los datos al usuario. Devolverles demasiados datos, de una manera que resulta abrumadora y paralizante, es “vomitar datos”. Si quieres impresionarles con la cantidad de cosas que puedes hacer con los datos probablemente estás vomitando datos. Por el contrario, si eres capaz de llevarlos a una serie clara de acciones, entonces has construido un producto con un foco definido.
  • Mantén la sencillez en la visualización. Tenemos que evitar que, si somos unos “locos de la visualización” nuestro entusiasmo por una excesiva sofisticación en este aspecto perjudique al producto. Lo más importante es mantener simple la visualización de los datos, de modo que los resultados sean consumidos fácilmente por los clientes que no son unos expertos en esta área.
  • Ve directo al asunto rápidamente. Hay que concentrarse en entregar valor. No hagamos trabajar a nuestros usuarios escudriñando exhaustivamente los datos para extraer conclusiones. Resulta tentador crear cosas abiertas que permiten una exploración ilimitada. Pero esto es peligroso. Los clientes son gente ocupada e impaciente que utilizan nuestro producto para resolver un problema real – ayudémosles a llegar a la línea de meta rápidamente.
  • En definitiva, informa las acciones de los clientes. Muchas soluciones proporcionan datos que son interesantes pero que no se conectan con las decisiones. La mejor manera de evitar el vómito de datos es concentrase en la accionabilidad de los datos. Es decir ¿qué acción queremos que los usuarios emprendan? ¿qué información es accionable?

Contrata a un buen product manager

Cuando tenemos el producto ya desarrollado eso no significa (contrariamente a lo que muchos ingenieros podríamos pensar) el principio del fin, sino el fin del principio. La mayor parte de la vida de un producto -y sus posibilidades de ingresos- están más allá del período de desarrollo.

En empresas orientadas a productos para un mercado (no proyectos a medida de un cliente) es imprescindible una figura que gestione el producto como un negocio a lo largo de todo su ciclo de vida, desde el análisis de la oportunidad, pasando por la concepción y construcción del producto hasta su explotación comercial y ulterior retirada: ese es el rol que se suele conocer como Product Manager y que se suele describir como un “mini-CEO” del producto.

Gestión de productos de datosLos productos de datos no son una excepción y las empresas basadas en ellos necesitan personas que se responsabilicen  de hacer productos que la gente quiera comprar y del éxito de esos productos en el mercado, con toda la extensión y profundidad de actividades que requiere esa función. Y como vemos, el desarrollo de producto es solo una parte de la gestión de producto.

Como en todas las empresas tecnológicas, en empresas de datos existirá la tentación de asignar la función de gestión de producto a una persona más o menos competente del departamento de Tecnología/Ingeniería (al fin y al cabo, los perfiles tecnológicos abundan en ese tipo de empresas). Pero eso suele ser un error: esas personas carecen de formación y experiencia en la vida del producto fuera de su fase de desarrollo y en muchos casos no tienen ni tiempo ni ganas de salir de su zona de confort tecnológica.

En esas circunstancias es mejor que ese tecnólogo ejerza las funciones de Technical Product Manager o de Product Owner y se ocupe del enlace entre el “negocio” y el equipo de implementación. Y adicionalmente debería contratarse a un Product Manager experto (aunque esa experiencia no sea exactamente en el sector de los datos y la analítica) que se ocupe de los aspectos más estratégicos y de relación con el mercado: descubrimiento y cuantificación de oportunidades de mercado, comprensión de los clientes y sus necesidades, definición de requisitos, análisis competitivos, diseño de producto, lanzamiento, habilitación y coordinación con marketing y ventas, evaluación y control.

Y todo ello aplicando un enfoque de Product Management más Agile/Lean que se caracterice por un intenso foco en el mercado y en las experiencias del cliente, una máxima flexibilidad y adaptación y una mínima burocracia, que se aplican en todo el ciclo de vida del producto.

El aspecto clave de crear un producto de datos es poner el “producto” primero y los “datos” después. O dicho de otra manera, los datos son un mecanismo por el cual hacemos que el producto esté centrado en el cliente.

El post “Desarrollando productos basados en datos (3)” se publicó primero en “Marketing & Innovación”.

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

1 comentario

La dificultad del desarrollo de productos basados en datos aconseja filosofías de desarrollo basadas en la iteración y la experimentación en el mercado. Por otro lado, los datos resultan ser una materia prima muy difícil de tratar.

Seguimos hablando del desarrollo de productos basados en datos, enfocándonos en las filosofías más recomendables y en la dificultad de usar datos como materia prima.

Los productos de datos tienen que construirse de manera diferente

Aparte de los inevitables riesgos de clientes y mercado los productos basados en datos se caracterizan por un elevado nivel de riesgo tecnológico. La dificultad intrínseca de desarrollo de productos basados en datos aboga por un proceso iterativo y centrado en los objetivos del cliente.

Parafraseando la famosa frase “la gente no quiere un taladro de un cuarto de pulgada, quiere agujeros de un cuarto de pulgada” la gente no quiere datos, sino que quiere soluciones e información accionable. Los clientes probablemente están considerando tu producto basado en datos para entender cómo les puede ayudar a tomar una decisión o realizar una acción. Así que tenemos que averiguar qué quieren hacer con el resultado y facilitarles que lleguen a algo tangible.

Productos de DatosEn “Designing great data products” J. Howard, M. Zwemer y M. Loukides proponen el enfoque Drivetrain, una filosofía basada en objetivos para diseñar productos de datos. Con este enfoque no usamos los datos para generar nuevos datos (en forma de predicciones) sino que usamos los datos para producir resultados accionables.

Por su parte DJ Patil, uno de los primeros científicos de datos de LinkedIn y Chief Data Officer de la administración Obama propone en su libro “Data Jujitsu” un método para resolver problemas de datos que evita intentar “la gran solución” desde el principio y en su lugar se concentra en construir algo rápido e iterar. A esto as a lo que llama Data Jujitsu, basado en aplicar la filosofía de esta antigua arte marcial que consiste en manipular la fuerza del oponente contar él mismo en lugar de enfrentarnos a ella con nuestra propia fuerza.

Data Jujitsu es el arte de usar varios elementos de datos de manera inteligente para resolver iterativamente problemas que, cuando se combinan, solucionan un problema de datos que de otra forma sería intratable. Como vemos, una especia de “divide (e itera) y vencerás”.

Según este enfoque no deberíamos resolver el problema entero de una vez. En su lugar tenemos que resolver una parte sencilla que nos demuestre si hay interés en el mercado y vamos a poder encontrar clientes. No tiene que tratarse de una gran solución; basta con que sea suficientemente buena como para hacernos saber si vale la pena ir más allá. Como vemos, este lenguaje del Data Jujitsu está totalmente en sintonía con los principios de Lean Startup y Customer Develoment (ej.: Producto Mínimo Viable o MVP).

La iteración y la experimentación son clave en el desarrollo de un producto de datos y algunas técnicas de MVP están especialmente indicadas en estos escenarios. La gran ventaja de algunas de ellas es que nos van a permitir sustituir tratamientos automáticos por procesamiento manual y así evitarnos el incurrir costes en desarrollar tecnologías e implementar productos que no va a ser necesarios. Por ejemplo:

  • Concierge. Consiste en resolver el problema del cliente de una manera abiertamente manual, mediante un experto en continua interacción con el usuario. El objetivo es encontrar la mejor manera de resolverlo y descubrir una solución replicable. Es, por consiguiente, una técnica generativa que produce ideas de producto.
  • “Mago de Oz” (también conocida como “Turco Mecánico” o “Los Picapiedra”). Consiste, en lugar de desarrollar la tecnología necesaria, en implementar la solución mediante procesos manuales. Esta circunstancia es desconocida por el usuario, que tiene una experiencia similar (aunque inevitablemente más lenta) a la que tendría con el producto final. De este modo validamos si la solución es aceptable. Una manera de implementar esta técnica de MVP es mediante un servicio tipo Amazon Mechanical Turk (cuyo irónico slogan es “Artificial Artificial Intelligence”). Se trata, por tanto, de una técnica evaluativa que nos permite comprobar si una solución concreta es válida y vale la pena implementarla.

Cuidado con los datos

Los datos son una materia prima muy complicada y difícil de conseguir, limpiar y adaptar para su uso. Según algunos estudios, las actividades de limpieza de datos habitualmente van a suponer el 80% o más del trabajo. En un escenario de desarrollo de productos basados en datos estos son realmente parte del problema y contribuyen a la dificultas del proceso.

  • ¿De qué datos vamos a poder disponer? No tiene sentido construir un producto alrededor de datos que no tenemos. Más de una vez me he encontrado, al definir un producto de datos con un partner, que ese proveedor que nos iba a proporcionar la materia prima de nuestro producto al final no disponía de ella con los requisitos de volumen y calidad necesarios. Por otra parte, las nuevas leyes de protección de datos de carácter personal (p.ej., GDPR en la UE) son cada vez más restrictivas en cuanto al tratamiento que se puede hacer de los datos personales. Eliminemos estos riesgos comprobando que podemos aprovisionarnos de los datos antes de empezar el diseño. Del mismo modo que los grandes chefs empiezan a cocinar en el mercado, descubriendo qué ingredientes están disponibles y frescos, a la hora de “cocinar” con datos deberíamos seguir la misma política.
  • ¿Cómo vas a conseguir esos datos? También me ha sucedido que a pesar de que el conjunto de datos parecía accesible a la hora de la verdad -y debido a problemas de índole técnica o legal- poder extraerlos con las consultas necesarias era un quebradero de cabeza. Si no eres al propietario de los datos haz un análisis de las capacidades técnicas y de licenciamiento del proveedor.
  • ¿Cómo de limpios y completos son tus datos? Por mucho que nuestro proveedor diga que el conjunto de datos es exacto nunca lo es. Siempre hay problemas, sean datos que faltan, valores erróneos o esquemas ambiguos. Hay que intentar afrontar estos problemas lo antes posible ya que cambiar un script es barato, reimplementar un producto es caro y publicar algo basado en datos erróneos es devastador.
  • Los insighst no se formulan, sino que se descubren. La extracción de insights a partir de datos se infrenta a unas incertidumbres y riesgos que no se dan en otros problemas. Y es que en general no vamos poder identificar a priori ni qué insights se van a derivar ni qué métodos y algoritmos van a ser los mas eficaces para extraerlos. Esto nos obliga a que este proceso sea muy especulativo, de exploración de diferentes alternativas para descubrir cuál es la mejor manera de avanzar, y donde las técnicas iterativas y ágiles son inevitables.

En el próximo post hablaremos de la necesidad de incorporar el diseño de producto a los productos basados en datos y de cómo gestionarlos a lo largo de todo su ciclo de vida.

El post “Desarrollando productos basados en datos (2)” se publicó primero en “Marketing & Innovación”.

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

Deja un comentario

La oportunidad para desarrollar y comercializar productos basados en datos nunca había sido tan grande. Pero hacerlo exige aplicar una “mentalidad de producto” diferente a la de proyectos a medida.

Ahora que “los datos son el nuevo petróleo” asistimos a un auge del desarrollo de nuevos productos basados en ellos. Nunca había sido tan grande la oportunidad para desarrollar productos de datos, a la que han contribuido la explosión del big data -que ha multiplicado la “materia prima” para estos productos- y la madurez y accesibilidad de las nuevas herramientas de almacenamiento y analíticas, que permiten su transformación.

Podemos definir un producto de datos como un producto que facilita un objetivo final mediante el uso de datos. O, dicho de otra manera, un activo de información envuelto en analítica que proporciona un valor a sus clientes. Ejemplos de productos de datos son un motor de búsqueda, un recomendador de productos, los datos de compras con tarjeta de crédito distribuidos por hora y ubicación, un servicio DMP (Data Management Platform), o un generador predictivo de leads para Account Based Marketing.

LProductos basados en datosEn general un producto de datos se compone tanto de datos como de procesos analíticos, pero hay productos donde los datos son más manifiestos y visibles como parte del resultado (por ejemplo, la función “gente que podrías conocer” de una red social) y otros donde los datos están más encubiertos (por ejemplo, el software para proponer la “siguiente mejor acción” a los usuarios de un sitio de e-commerce).

¿Cualquier solución basada en datos es un producto de datos?

Para muchos profesionales de los datos, desarrollar un producto no es ni obvio ni su primera opción. En general, suelen ser personas más acostumbradas a otras actividades y negocios basados en datos/analítica: mejora de procesos y decisiones internos, desarrollo de proyectos, consultoría externa.

Resulta difícil adoptar una “mentalidad de producto”, especialmente para un cierto perfil de data scientist que se encuentra más familiarizado y cómodo en el mundo de los desarrollos a medida para un cliente (sea interno o externo). Sin embargo, las perspectivas de rentabilidad y escalabilidad de este tipo de negocios los hacen muy atractivos.

Este asunto de la diferencia de los negocios basados en producto estándar frente a los basados en proyectos a medida lo hemos tratado anteriormente en el blog desde una perspectiva general. Por centrarnos en este caso digamos que, frente a otras actividades y negocios basados en datos, los productos poseen  unos aspectos diferenciadores esenciales:

  • Los productos de datos deben ser replicables y para un mercado. Cuando hablamos de “producto” no utilizamos el término en el sentido en que se usa en proyectos a medida, y que designa al resultado final de ese proyecto. Un producto debe ser replicable, en el sentido de debemos poder vender unidades del mismo (con las mínimas modificaciones) al mayor número de clientes posible, y orientarse a un mercado, compuesto de clientes relativamente heterogéneos y difíciles de acceder.
  • Uno de los aspectos primordiales de los productos para un mercado es cómo entender a los clientes y sus necesidades y decidir en qué segmento nos enfocamos para poder desarrollar un producto suficientemente estándar y rentable.
  • Los productos de datos se caracterizan por unos costes de desarrollo y unos costes de replicación que definen completamente la rentabilidad del negocio. Estos costes de desarrollo, habitualmente muy elevados, hacen que un producto sea rentable con la repetición y su negocio plantee unas necesidades financieras muy exigentes al principio.
  • Las expectativas de los clientes, especialmente si el producto se dirige al mercado de consumo, son muy elevadas. Acostumbrados a unas experiencias de uso impecables en todo tipo de productos, los clientes no van a exigir menos de los productos de datos. Y, sobre todo, no se van a conformar solo con los datos: el producto debe habilitar a los usuarios a hacer lo que quieren hacer (que muchas veces no tiene nada que ver con consumir datos).

Si no se tienen en cuenta estos aspectos diferenciadores nuestras iniciativas de desarrollo de productos de datos pueden fracasar

Desarrollo de productos

El desarrollo de un producto no es lo mismo que el desarrollo de un proyecto. La gran diferencia proviene del hecho de que un producto por su propia naturaleza debe satisfacer las necesidades de un conjunto amplio de clientes y, para garantizarlo, las actividades de diseño y construcción deben ser precedidas por (y hasta cierto punto simultaneadas con) actividades de comprensión de los clientes y descubrimiento de sus necesidades. Lo hemos descrito en detalle aquí aquí.

Desarrollo de Productos

El desarrollo de producto propiamente dicho está a su vez precedido por una fase previa en la que se identifican problemas de mercado y se cuantifican las oportunidades que representan. De esa evaluación se seleccionan las oportunidades que vale la pena perseguir y que pasarán al proceso de desarrollo de producto estrictamente hablando. En resumen, el proceso queda así:

Fase previa

0. Identificar problemas de mercado y evaluar oportunidades

Desarrollo de producto (fases que se solapan en un proceso iterativo):

1. Definición. Entender el mercado, recoger requisitos (= problemas de mercado) y definir los que el producto va a resolver

2. Diseño. Conceptualizar la solución y elaborar la especificación funcional y la experiencia de usuario

3. Implementación. Elaborar la especificación técnica, construir y probar la solución

Podéis encontrar más información sobre el proceso de desarrollo de productos en los numerosos posts sobre el tema que hemos publicado.

En el próximo post seguiremos hablando del desarrollo de productos de datos, centrándonos en las peculiaridades de su proceso de construcción y de los datos como su materia prima.

El post “Desarrollando productos basados en datos (1)” se publicó primero en “Marketing & Innovación”.

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

Deja un comentario

El crecimiento ya no consiste en una lista de “growth hacks” o tácticas que pueden funcionar en tu caso o no. El growth hacking es ahora un sistema, un proceso. Incluso una filosofía sobre cómo llevar un negocio al siguiente nivel.

La pregunta más habitual que reciben los expertos en growth hacking es “¿Qué táctica debería usar para hacer crecer mi negocio?” Muchas veces esta pregunta surge de una concepción del crecimiento como algo mágico, y del deseo de encontrar un truco o receta secreta que libere el potencial de desarrollo de un negocio.

Pero se trata de una pregunta equivocada y cualquier intento de responderla sin más contexto está destinada al fracaso. Según Brian Balfour (ex VP Growth de HubSpot y fundador de Reforge) la respuesta en realidad está en dejar de buscar las tácticas primero y en su lugar empezar a establecer una filosofía y unos fundamentos de crecimiento.

Principios, antes que tácticas

Una filosofía de crecimiento está basada en principios, que se materializan en un proceso y un equipo, no en tácticas.

  • Principios. Son los valores esenciales que guían al equipo hasta el éxito. Dirigen la articulación de nuestro proceso, forman parte de los requisitos para contratar a nuevos miembros del equipo y ayudan a tomar decisiones difíciles. Estos son algunos de los principios habituales en los equipos de growth hacking de éxito: maximizar el aprendizaje, buscan el impacto, equilibrar creatividad y analítica y aceptar el cambio.
  • Proceso. ¿Cómo articular nuestras actividades para que, partiendo de nuestros objetivos de crecimiento, lleguemos a descubrir una serie de tácticas escalables y replicables que nos permitan alcanzarlos? Nuestro proceso da respuesta a estas preguntas y despliega la capacidad de nuestro equipo para generar crecimiento. El proceso es nuestra máquina de crecimiento: un marco que nos ayuda a generar ideas, priorizarlas, evaluarlas, implementar las mejores tácticas e ir mejorando nuestras capacidades para hacer crecer el negocio.
  • Equipo. Necesitamos una mezcla de personas con un conjunto de capacidades organizadas para ejecutar nuestro proceso.  Los equipos de growth hacking suelen ser multidisciplinares, compuestos de personal de marketing, producto, analítica e ingeniería.
  • Tácticas. Las tácticas son el resultado del proceso: una combinación única de ingredientes que hacen posible el crecimiento de nuestro negocio. Nuestro trabajo es descubrir esa combinación única.

Según Brian Balfour existen varias razones por las que hay que priorizar el proceso antes que las tácticas:

  • El crecimiento resulta de la suma de muchas pequeñas partes. Antes y después de una curva tipo “stick de hockey” hay una multitud de factores que se combinaron para desatar el crecimiento inicialmente y para mantenerlo vivo después. La realidad es que no hay “balas de plata”: aunque pueda haber experimentos que produzcan resultados excepcionales, solo es posible llegar a ellos como resultado del aprendizaje combinado de multitud de otros experimentos. Es necesario un proceso que genere nuevas ideas, las pruebe eficientemente, aprenda de los resultados y use ese aprendizaje para generar crecimiento de una manera continua.
  • La velocidad de cambio en los canales digitales está incrementándose. Aparecen nuevos canales continuamente y las tácticas que funcionaban hace unos meses ya no son eficaces. Necesitamos un proceso que permanentemente adapte nuestras tácticas a este entorno cambiante.
  • Lo que funciona para una empresa no funciona necesariamente para las demás. Las audiencias son diferentes, los productos son diferentes, los ciclos de vida de los clientes son diferentes, los modelos de negocio son diferentes… en una palabra los negocios son diferentes. Debemos tomar lo que ha funcionado para otros como una inspiración, no como una prescripción. Necesitamos un proceso que descubra las combinaciones únicas de elementos que funcionan para nuestra audiencia, producto y modelo de negocio.
  • Necesitamos una máquina de crecimiento. Para alcanzar el éxito no basta con encontrar una táctica que funcione. El éxito está en construir un motor de crecimiento, una máquina que sea escalable, predecible y repetible. Un proceso de growth hacking, que reciba como entrada los objetivos a alcanzar y produzca como resultado las tácticas, constituye esa máquina.

Elementos de un proceso de growth hacking

No existe un proceso de crecimiento correcto o perfecto. Lo importante es tener uno, ajustarse a él e ir mejorando con el tiempo. Pero cualquier proceso de crecimiento debería incorporar una serie de elementos clave:

Proceso Growth Hacking

0. Alcanzar encaje producto/mercado

El growth hacking debería empezar con un producto y el encaje producto-mercado es un requisito previo y la base del growth hacking. Si no tenemos todavía un producto y un modelo de negocio validados es mejor parar.  No podemos aplicar growth hacking para llegar al encaje problema-solución o producto-mercado, así que tenemos que enfocarnos en eso antes. Es necesario asegurarnos de que entendemos bien nuestros segmentos de clientes, propuesta de valor, estructura de costes, corrientes de ingresos, etc. antes de continuar.

1. Definir objetivos accionables

Nuestros objetivos no pueden ser tan amplios que no sean significativos. Por supuesto que el objetivo es el crecimiento, pero uno no alcanza ese tipo de resultado final si no se divide éste en tareas más pequeñas y alcanzables. Una manera de conseguirlo es enfocándose en algunas de las etapas del funnel AAARRR (Awareness, Acquisition, Activation, Retention, Referral, Revenue) y, dentro de ella, descomponiéndola en subobjetivos.

2. Idear

Generar hipótesis para estrategias, campañas y tácticas que se alineen con la consecución de nuestros objetivos y puedan avanzar nuestros indicadores. Estas hipótesis pueden estar relacionadas con canales de marketing o características del producto y juntas constituyen nuestro backlog de ideas. Las técnicas de fomento de la creatividad como el brainstorming o el mindstorming son útiles en esta fase. Cuando un objetivo se puede descomponer como el resultado de varios inputs hay que generar ideas para mover dichos inputs, mejor que el resultado final.

3. Priorizar

Aplicar un proceso riguroso para determinar qué hipótesis perseguir. Existen diversos enfoques para, de una manera relativamente científica, asignar puntuaciones a cada idea en el backlog. Uno de ellos, comúnmente aceptado, es el ICE (Impact, Confidence, Ease) que les otorga un score en función de su efecto previsto en los objetivos, probabilidad de éxito  y cantidad de recursos necesarios para ejecutarlas.

4. Experimentar

Diseñar y ejecutar los experimentos para ver qué ideas producen las mayores ganancias. En esta fase es útil un enfoque de Experimento Mínimo Viable, que con el mínimo coste proporciona el máximo aprendizaje, eficiencia y validez. En el diseño del experimento, además de la hipótesis que queremos validar/refutar debe figurar el proceso de la prueba y la métrica que vamos a utilizar para evaluar el resultado. Lo importante de los experimentos es aprender algo, con independencia del resultado concreto.

5. Analizar

Sin analítica, los objetivos están vacíos. Se trata de descubrir nuevas oportunidades de crecimiento mediante análisis cualitativos y cuantitativos. En el análisis de éxito/fracaso debemos cuantificar el impacto real (diferencia respecto a la predicción de la hipótesis) y entender el porqué de esos resultados. Obviamente, la infraestructura y procesos de análisis deben estar desplegados antes de empezar con los experimentos.

6. Sistematizar

Utilizar los resultados de los experimentos para optimizar nuestra ejecución y sistematizar las ideas que funcionan, productizándolas (aplicando tecnología e ingeniería) o materializándolas en guías paso a paso para hacerlas repetibles.

7. Repetir el ciclo

Volver a ejecutar el ciclo, intentando cada vez ser más precisos en nuestras predicciones, más eficientes en la realización de experimentos y más eficaces en el aprendizaje. Y hacerlo con la mayor cadencia posible: el growth hacking es, en gran parte, un juego de velocidad.

El éxito en el growth hacking proviene principalmente de seguir escrupulosamente un proceso, porque la mayoría de la gente no lo hace. El proceso es difícil y puede resultar frustrante y, de hecho, es muy fácil desviarse de él y perseguir el último “objeto brillante”, pero eso nos llevará a la ineficacia. En su lugar, hay que enfocarse en configurar los anteriores elementos en un proceso que funcione para nuestra organización.

El post “El growth hacking es un proceso, no una lista de tácticas” 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 Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario
A %d blogueros les gusta esto: