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

Posts from the ‘gestión de producto’ category

El Product-Led Growth implica mucho más que aplicar un modelo freemium o proporcionar una prueba gratuita. Esencialmente significa un compromiso total con la excelencia del producto y un alineamiento de toda la organización alrededor de éste.

La idea básica que subyace a una estrategia de Product-Led Growth (PLG) es que el uso del producto es el principal impulsor de la adquisición y expansión de clientes, sin requerir la intervención de un representante de ventas, es fundamentalmente diferente del enfoque tradicional basado en las ventas que atiende primero a los compradores económicos y segundo a los usuarios finales. Esto es posible gracias a las características incorporadas al producto que automatizan ciertas funciones de comercialización, ventas y éxito del cliente.

Tácticas del crecimiento impulsado por el producto

Generalmente se suele asociar el Product-Led Growth con una atracción y adquisición de clientes basada en la prueba gratuita y el modelo freemium, pero en realidad puede utilizar un repertorio más amplio de tácticas:

  • Free trial: dar acceso gratuito a (típicamente todo) el producto que se está comercializando durante un tiempo limitado.
  • Freemium: ofrecer una versión limitada del producto por tiempo indefinido y versiones más completas de pago.
  • Open source: en el caso de productos software, dar acceso abierto a (parte del) código fuente del producto para que los usuarios puedan usarlo gratuitamente, realizar desarrollos derivados y crear una comunidad.
  • APIs: en el caso de productos software, dar acceso programático a “componentes” de nuestra solución -datos, funcionalidad- para que desarrolladores e integradores puedan implementar nuevas soluciones sobre ellos y podamos llegar a nuevos mercados.
  • Productos “señuelo”: publicar un producto gratuito que posea un gran carácter viral y atraiga a los clientes a nuestro producto real. Este producto señuelo típicamente debe “vender el problema” que nuestro producto real viene a solucionar. El ejemplo más clásico es el Website Grader que HubSpot publicó para evaluar gratuitamente el marketing online de sus usuarios, detectar carencias y prescribir como solución el producto de automatización de marketing inbound de la empresa.

Transformaciones necesarias

Hay dos transformaciones críticas que deben tener lugar para implementar un crecimiento impulsado por el producto: la primera es en nuestro producto, la segunda es en nuestra organización.

Primero y principal, necesitamos tener un producto excelente que cumpla con el valor prometido. Si estás pensando que “impulsado por el producto” suena parecido a “dirigido por el diseño”, tienes razón: la empatía e innovación inherentes al pensamiento de diseño es un componente crucial para el crecimiento impulsado por un producto. Para construir una experiencia de producto verdaderamente atractiva que sea capaz de demostrar su propio valor, se necesita una profunda comprensión del viaje de los usuarios y de los problemas que están tratando de resolver. Todo el producto debe basarse en facilitar a los usuarios la solución de sus problemas, lo que significa eliminar los puntos de dolor siempre que sea posible, ofrecer un onboarding eficaz del usuario centrado en sus objetivos (no en las características del producto) y proporcionar comunicaciones continuas y contextuales dentro de la aplicación para asuntos como las nuevas características, los recordatorios de elevación de producto, etc. Los productos de éxito también utilizan de manera inteligente los datos del usuario para iterar en su producto existente, proporcionar una personalización útil (frente a la de vanidad) y vigilar los cuellos de botella en el viaje del usuario.

La segunda y más difícil transformación debe tener lugar en nuestra organización. Las organizaciones impulsadas por el producto se mueven rápidamente, con un enfoque implacable en las necesidades y deseos de sus usuarios, y una cultura de recopilar y aprovechar el feedback contextual. Además, las empresas impulsadas por el producto están alineadas: el GLP es una metodología de amplio alcance que abarca toda la empresa y que requiere la coordinación y la colaboración de todos los departamentos. Los equipos multifuncionales son tanto un requisito como un beneficio del crecimiento impulsado por el producto. Romper los silos es un paso esencial en el camino de su empresa hacia el PLG, pero también tiene efectos positivos en la capacidad de sus equipos para comunicarse y coordinarse, lo que conduce a una toma de decisiones más informada y alineada en toda la empresa.

Consecuencias sobre la comercialización

Nuestro producto debe incentivar a los usuarios para que inviten a otros a utilizarlo, asegurándose de que su experiencia sea más valiosa y agradable a medida que más compañeros se inscriban. La idea de que nuestro producto sirva como un medio para permitir a los usuarios referir a otros usuarios es el núcleo de productos como Slack, Dropbox y Typeform. Los usuarios no esperan recibir una ganancia monetaria a cambio de invitar a otros. Se les incentiva para que inviten a otros porque al hacerlo aumentan el valor que obtienen del producto. Esto es así porque, por ejemplo, pueden beneficiarse de las características de colaboración del producto o se generan efectos de red (directos, indirectos o de datos).

Debemos construir nuestros mensajes de marca y nuestra voz para que resuene entre los usuarios finales, aquellos cuya vida diaria mejorará gracias a nuestro producto. Idealmente, nuestro objetivo debe ser construir un ejército de campeones que impulsen el cambio en sus organizaciones. Nuestro producto como forma clave de marketing, después de todo, es un principio básico del crecimiento impulsado por el producto. Así que la viralidad debe estar presente en todo lo que hagamos.

La creación de bucles virales en el producto, la comprensión de los canales de comercialización importantes, la creación de una marca en la que confíen los usuarios, el cultivo de la comunidad en torno al producto y el apoyo a un viaje del usuario que facilite la adopción (y el pago) se convierten en apuestas imprescindibles.

En el próximo post hablaremos de las similitudes y diferencias entre las dos tácticas más habituales en Product-Led Growth: freemium y free trial.

El post “Implementando Product-Led Growth” 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 Product-Led Growth proporciona nuevas respuestas acerca de quién, cómo y por qué compra nuestro producto. Y lleva a que la organización se integre y alinee alrededor de dicho producto

La filosofía Product-Led Growth (PLG) utiliza el producto como el principal canal para la adquisición, retención y monetización de clientes. Ello tiene enormes implicaciones en cuanto a la estrategia comercial, la organización y las métricas de negocio.

Crecimiento impulsado por el producto y Go-to-Market

Echemos un vistazo a cómo PLG responde a esas preguntas de “go-to-market”:

  • ¿Quién está comprando nuestro producto? En un enfoque puro impulsado por el producto, nuestro foco inicial deberían ser los usuarios, no los compradores. Debemos involucrar a las personas que potencialmente van a usar e producto, no a unos compradores que pueden estar en las alturas de una organización o formar parte de un comité de compras muy alejado de los flujos de trabajo reales que nuestro producto optimiza. La estrategia impulsada por el producto “pura” es un enfoque de abajo arriba que habla directamente de las necesidades de sus usuarios finales. Sin embargo, como veremos, éste es un enfoque que no funciona en todos los casos y –tal como han descubierto los proveedores de productos de “compra corporativa” – debe ser complementado con otros enfoque que satisfagan las necesidades de información y de valor para el negocio de esos compradores.
  • ¿Dónde descubrirán nuestro producto? PLG se basa en la viralidad y el boca a boca, en lugar de las estrategias de promoción tradicionales. Más específicamente, los usuarios satisfechos compartirán su producto con amigos, compañeros de trabajo y personas en sus círculos sociales y las funcionalidades de colaboración llevarán de manera natural a los usuarios a invitar a otros usuarios.
  • ¿Por qué van a comprar nuestro producto? Como regla general, nuestro producto debería ofrecer más valor, tener mejor UX y ser más útil, usable y fiable que el de nuestros competidores. Para los usuarios finales, las posibilidades de prueba o uso gratuito son la mejor validación de estas características. Eso no implica que no existan compradores con otros objetivos y criterios de negocio a los que haya que persuadir de otros modos. Pero esta posibilidad de uso previo reduce enormemente el riesgo de que el producto no entregue su valor potencial y aumenta la disposición a pagar. Y el uso actual del producto es un factor de compra cada vez más importante para evitar la compra de productos que luego acaban no usándose.
  • ¿Cómo están comprando nuestro producto? Idealmente los usuarios deben convertirse en compradores dentro del propio producto -después de haberlo experimentado en primera persona- en lugar de mediante los vendedores.

Algunas consecuencias de adoptar un enfoque PLG

Integración Product-Led Growth

  1. Los equipos multifuncionales pasan a ser cruciales. En lugar de departamentos inconexos y descoordinados, este enfoque requiere equipos multifuncionales que se orienten en torno a un producto o segmento de clientes en particular. Como mínimo, esos equipos deben tener representantes de Gestión de Producto, Marketing y Éxito del Cliente.
  2. Integrar los silos de datos para un análisis profundo. En muchas organizaciones los datos a menudo permanecen fragmentados dentro de herramientas de software específicas de cada función, nunca se analizan por completo o se centralizan en el contexto de los datos de otros equipos. Las empresas de crecimiento impulsado por el producto están comenzando a elaborar estrategias sobre cómo integrar las actividades compartidas de descubrimiento de productos entre Producto, Marketing y Éxito del Cliente.
  3. Indicadores clave de rendimiento compartidos y no más métricas de vanidad. Los mejores equipos de productos están pasando del enfoque lineal del pasado, centrado en las características del producto, a un enfoque más orientado a los resultados. En lugar de hacer un seguimiento de las métricas de vanidad (tales como cuántas características ha entregado un equipo de producto o cuántos leads ha recogido un equipo de marketing) los equipos multifuncionales deberían centrarse en impulsar el valor del cliente, medido por una métrica como el ingreso medio por usuario (ARPU), el valor del tiempo de vida del cliente (CLV), los usuarios activos diarios (DAU) o el abandono.

Métricas de PLG

Otras métricas de SaaS que son útiles para medir el crecimiento impulsado por el producto incluyen:

Tiempo hasta obtener Valor (Time To Value, TTV). El TTV es un componente crítico de los productos de consumo. Este parámetro mide el tiempo que tardan los nuevos usuarios en llegar a su primer “momento ajá” o evento de comprensión del valor del producto. El objetivo de toda buena experiencia de onboarding de un usuario debe ser reducir el TTV en la medida de lo posible, ayudando a los nuevos usuarios a percibir del valor de nuestro producto lo antes posible.

Ingresos por expansión. También llamado MRR de expansión o ingresos por upsell, mide los ingresos generados por los clientes existentes a través de ventas por elevación de producto, complementos, ventas cruzadas, etc.

Leads Cualificados por Producto (Product-Qualified Leads, PQL). Podemos despedirnos de los MQLs. Y saludemos a los leads que ya han experimentado el valor de nuestro producto a través de una prueba gratuita o el freemium. Los leads calificados por producto son esencialmente usuarios activados, gente que ha completado una acción clave en nuestro producto, ha tenido su “momento de ajá”, y ha visto de primera mano el valor que nuestro producto puede ofrecer de primera mano.

Viralidad y efectos de red. Estos términos se usan a veces indistintamente pero son, de hecho, muy diferentes. Sin embargo, a menudo se dan la mano. Un producto viral es aquel cuya tasa de adopción aumenta con cada usuario adicional gracias a fenómenos como la recomendación y el “boca a boca”. Cuantas más personas se unan, más rápido crece. Un producto con efectos de red, por otro lado, se vuelve más valioso para los usuarios a medida que más personas se unen.

En el próximo post hablaremos de cómo implementar el Product-Led Growth.

El post “Implicaciones del Product-Led Growth” 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 Product-Led Growth está revolucionando la manera en la que crecen las empresas, poniendo al producto en el centro de las estrategias de adquisición, retención y monetización. Esta estrategia multiplica los beneficios y las economías de los modelos de negocio basados en producto. Pero el Product-Led Growth no es para todo el mundo sino que en determinadas circunstancias puede estar contraindicado.

En la filosofía de Product-Led Growth (PLG) es el uso del producto el que sirve como el principal impulsor de la adquisición, retención y expansión de usuarios, de modo que las empresas pueden renunciar a gastar grandes sumas en actividades tradicionales de marketing y ventas. Con este enfoque las compañías dependen de los propios productos para abastecer un canal de usuarios satisfechos y potenciales interesados que pueden convertirse en clientes de pago.

Las ventajas de un modelo de negocio basado en producto son claras, PLG las multiplica

En otras ocasiones nos hemos referido en este blog a los beneficios de un modelo de negocio basado en producto para un mercado (comparado con proyectos a medida de un cliente):

  • El negocio basado en producto es mucho más escalable (y atractivo para los inversores ;- ) ya que se basa en la replicación y -al dirigirse a un mercado- permite capturar enormes economías.
  • Un producto aporta credibilidad: no es lo mismo ofrecer un producto funcional, demostrable, estable, contrastado y usado por cientos (o millones) de clientes que unas “competencias digitales” y capacidades de desarrollo totalmente “vaporosas” (y que en la realidad se suelen traducir por “tenemos un ingeniero junior que cursó en la universidad una asignatura relacionada con este tema… pero ningún cliente en producción”).
  • Un producto aporta visibilidad: los clientes hablan más de productos (y sus proveedores) que de otro tipo de soluciones, los analistas los cubren en sus informes y los influenciadores y medios de comunicación los mencionan. Esto proporciona un alcance orgánico muy superior.

Pero ahora, el Product-Led Growth lleva estas ventajas a otro nivel que permite a las empresas que lo adoptan escalar más rápidamente. Los dos principales beneficios del crecimiento basado en el producto son:

Un motor de crecimiento predominante

Los mecanismos de adquisición del PLG (gratuidad, viralidad) abren nuestro top-of-funnel a muchos más potenciales clientes, mucho antes en su viaje (unos clientes que en lugar de hablar con nuestros vendedores y pedirles demos están explorando en primera persona nuestro producto). Y nos permite escalar fácilmente a un nivel global: en lugar de reclutar nuevos vendedores o partners en cada mercado podemos optimizar con un alcance  general nuestros procesos de onboarding y entrega de valor y servir a miles de clientes, capturando grandes economías.

Costos de adquisición de clientes significativamente más bajos

La posibilidad de que los usuarios puedan explorar el producto y la credibilidad que proporciona el exponerlo abiertamente acortan los ciclos de venta, al permitir a los clientes entender y extraer el valor del producto rápidamente. Y la escalabilidad de estos procesos, que no dependen de un estrecho contacto personal, hace que se puedan implementar con un número comparativamente bajo de empleados, mejorando los ingresos por miembro de la organización.

Estos beneficios permiten acercarse al ideal de que el producto “se venda solo”. Y hacen que según OpenView, los negocios impulsados por el producto están valorados más de un 30% por encima del Índice SaaS del mercado público.

El Product-Led Growth no es para todo el mundo

¿El PLG es solo para productos software? Si pensamos que el crecimiento impulsado por el producto parece aplicarse sólo a una categoría bastante limitada de empresas de software, considerémoslo de nuevo. Las grandes compañías de hardware como Apple o Tesla pueden ser consideradas como compañías de crecimiento impulsado por el producto. El hilo común de muchas de las marcas más valiosas del mundo es la familiaridad con el cliente y un incesante impulso para aumentar el valor entregado a éste. Comprender realmente las necesidades de sus clientes y esforzarse por complacerlos construyendo grandes soluciones para satisfacer esas necesidades, es el corazón de las compañías impulsadas por el producto.

B2C vs B2C. El crecimiento impulsado por el producto ofrece diferentes perspectivas en mercados B2C y B2B:

  • B2C: en mercados de consumo, donde el usuario es típicamente el comprador, se pueden capturar más fácilmente los beneficios del PLG.
  • B2C: en mercados de empresa es más habitual la compra compleja (los usuarios no son necesariamente los compradores y aquéllos pueden tener una influencia pequeña en el proceso) y entran en juego otros factores: políticos, autonomía de unidades de negocio/departamentos, exigencias de compatibilidad e integración, objetivos corporativos, etc. Como ya sabemos, las razones por las que usuarios y ejecutivos compran un producto pueden ser muy diferentes y dependiendo del caso prevalecerán unas u otras. Estas diferencias pueden limitar la aplicabilidad de un enfoque PLG puro.

En realidad, para que el Product-Led Growth encaje en un negocio se deben tener en cuenta dos ejes:

Encaje Product-Led Growth

El producto es fácil de adoptar por los usuarios

  • El producto tienen un caso de uso para el usuario individual muy definido, claro y valioso.
  • La propuesta de valor inmediata para el usuario final debe ser lo suficientemente convincente como para que decida adoptarla por sí mismo.
  • Los usuarios perciben inmediatamente el valor del producto para ellos, tienen su “momento ajá” y se crea un hábito de uso de manera natural.
  • El usuario final puede adoptar el producto sin un proceso de implementación de gran envergadura que requiera recursos profesionales especializados.

El producto no requiere una compra corporativa, típicamente compleja, mediante un comité con decisores de negocio, validadores, etc.

  • No es necesario que el producto permita alcanzar unos objetivos y conseguir unos resultados de negocio (KPIs, ROI) a nivel corporativo (ver nuestros post sobre productos “comprables”).
  • No hay costes por usar varios productos que cubran las mismas necesidades en diferentes áreas de la organización (no es necesario estandarizar) y el producto se puede comprar de manera individual o departamental, no centralizada.
  • Los productos no requieren de una estandarización, validación y autorización (de tipo técnico u otro) a realizar por un departamento centralizado.

En función de estos ejes podemos encontrar cuatro casos:

  • Producto fácil de adoptar, compra no corporativa: es terreno favorable para el Product–Led Growth. Ejemplos serían todo tipo de herramientas de productividad personal o para equipos.
  • Producto fácil de adoptar, compra corporativa: como veremos, este escenario exige complementar el PLG con tácticas de venta top-down (venta Enterprise)
  • Producto difícil de adoptar, compra no corporativa: este escenario exige “acercar el valor al usuario” mejorando su propuesta de valor, simplificando su uso y optimizando el onboarding y la activación de los usuarios.
  • Producto difícil de adoptar, compra corporativa: es el escenario más difícil para el PLG y exigiría una combinación de las acciones de los dos escenarios anteriores. Ejemplos de este caso son los grandes sistemas de gestión empresarial tipo ERP, SCM o CRM.

Algunos apóstoles del crecimiento impulsado por el producto lo están prescribiendo para todo tipo de productos. Pero si el producto está en alguno de los cuadrantes “peligrosos” del plano anterior el intento puede terminar en fracaso total.

En el próximo post analizaremos algunas implicaciones del Product-Led Growth.

El post “Product-Led Growth: ventajas y limitaciones” 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

Después de las filosofías de crecimiento impulsado por las ventas e impulsado por el marketing, el crecimiento impulsado por el producto nos ofrece la promesa de productos que “se venden solos”. Pero esto no es un milagro.  El Product-Led Growth aprovecha el cambio que se está produciendo en la forma en que los clientes evalúan y compran para construir experiencias de producto impecables, alinear toda la organización alrededor de él y convertirlo en el principal motor de adquisición, retención y monetización.

¿Recuerdas cuando un representante de ventas de Zoom te convenció para que empezaras a usar la herramienta? ¿O cuando la agresiva campaña de marketing por email de Slack te hizo probarlo? ¿O incluso cuando los anuncios de Dropbox te convencieron de empezar a usarlo? Eso es. Nada de eso te ha ocurrido. Porque estas empresas utilizan el Product-Led Growth. El crecimiento impulsado por el producto no se basa en carismáticos representantes de ventas o en laboriosos equipos de marketing. Se basa -lo has adivinado- en el producto.

La nueva manera en que los clientes compran nuestros productos (con unos usuarios que son protagonistas y quieren evaluar esos productos de primera mano) y la saturación de los canales de marketing nos está obligando a cambiar la forma en que les vendemos. Hace unos años, el growth hacking nos enseñó que la búsqueda exitosa del crecimiento empieza con el producto y a ver el propio producto como el canal primordial para un crecimiento escalable.

crecimiento impulsado por el producto

Productos que se venden solos

Como evolución y formalización de estas ideas, en los últimos años se ha desarrollado una filosofía conocida como Product-Led Growth que plantea la promesa de que los productos se pueden llegar a “vender solos”.

El término Product-Led Growth (PLG) fue acuñado por la firma de venture capital OpenView Venture Partners para describir a empresas que ofrecen experiencias excelentes de producto, lo que hace que los clientes lo utilicen a menudo y lo recomienden y compartan con sus redes. El crecimiento impulsado por el producto es una metodología de negocio en la que la adquisición, expansión, conversión, retención y recomendación de los usuarios son impulsados principalmente por el propio producto. El Product-Led Growth crea un alineamiento entre los equipos en toda la empresa -desde la ingeniería hasta las ventas, el marketing y el servicio- en torno al producto como la mayor fuente de un crecimiento empresarial sostenible y escalable.

El PLG adopta un enfoque bottom-up al ofrecer productos con una experiencia de “nivel de mercado de consumo” típicamente a través de una prueba gratuita o freemium. Sus esfuerzos de comercialización se centran en gran medida en conseguir que la gente pruebe los productos por sí misma, en lugar de tratar de llevar a la gente a los brazos de un representante de ventas. Y una vez que los usuarios están en el producto, estas empresas ofrecen experiencias de onboarding y mensajes continuos en la aplicación, integrando esencialmente las comunicaciones de ventas, de marketing y de soporte en el propio producto.

El objetivo es que el usuario reciba un valor significativo y duradero de manera rápida y fácil, con poca o ninguna ayuda del personal de la empresa, y acabe utilizando el producto recurrentemente, pagando por él y recomendándoselo a su red. Las empresas dirigidas por el producto hacen esto posible dando al comprador las “llaves” para usar el producto y ayudándole a experimentar un resultado valioso mientras lo usa y descubre la solución por su cuenta.

Una organización alineada alrededor del producto

A un nivel superficial, el crecimiento impulsado por el producto puede parecer un modelo simple para que su cliente lo pruebe antes de comprar. Pero es algo mucho más profundo. El PLG significa que cada equipo de la empresa influye y se alinea en torno al producto. Lo que hace único a un negocio impulsado por el producto es que todos los equipos aprovechan el producto para alcanzar sus objetivos:

  • Un equipo de Ingeniería/Desarrollo impulsado por el producto se pregunta, “¿Cómo podemos crear un producto que aporte al cliente un tiempo de captura de valor corto?”
  • Un equipo de Marketing impulsado por el producto se pregunta, “¿Cómo podemos usar nuestro producto como nuestro principal imán de leads y generar un flywheel de demanda?”
  • Un equipo de Ventas impulsado por el producto se pregunta: “¿Cómo podemos usar el producto para que cualifique a nuestros prospects por nosotros?” De esa manera, tendrán conversaciones con personas que ya entienden el valor del producto.
  • Un equipo de Éxito del Cliente impulsado por el producto pregunta: “¿Cómo podemos crear un producto que ayude a los clientes a tener un éxito máximo sin nuestra ayuda?”

El crecimiento impulsado por el producto no significa crecimiento impulsado por el Product Manager. Esto es así porque los product managers no son los únicos dueños del PLG. En el Product-Led Growth se trata de aprovechar las contribuciones de toda la empresa para construir un producto mejor y que genere un hábito de uso entre sus clientes. Al tener a cada equipo enfocado en el producto, se crea una cultura construida alrededor de un valor duradero para el cliente.

Pero no es sólo alineamiento de la organización: es, sobre todo, eliminar fricciones en el tránsito del cliente a través del producto. Ya no basta con extender nuestro core product hasta llegar a un producto “esperado” o “aumentado” que satisfaga la razón para comprar del cliente o lo diferencie frente a la competencia. El producto debe incorporar ahora experiencias, funciones y  características que permiten comercializarlo, venderlo y hacer el onboarding de nuevos usuarios para que desarrollen rápidamente un hábito natural de uso. El producto debe “venderse solo”.

Flywheels impulsados por el producto

La creación de una experiencia verdaderamente satisfactoria para el usuario también proporciona rentabilidades significativas para el proveedor del producto. Los productos producidos por Slack, Expensify y Dropbox sirven de base para la estrategia de comercialización de esas empresas. El crecimiento liderado por el producto aboga por abandonar el paradigma de que hay que vender a los compradores: se puede empezar por los usuarios (no con los compradores) y aplicar la venta de abajo hacia arriba.

Esta sutil diferencia es un pilar fundamental de la comercialización en el crecimiento impulsado por el producto. Al contrario que las empresas tradicionales que venden a los compradores y se basan en un enfoque de arriba abajo, las empresas de crecimiento impulsado por el producto construyen su base de usuarios desde abajo, confiando en la viralidad para llevar el producto a toda la organización y a nuevos clientes. Se crean así bucles de realimentación que contribuyen a crear un eficaz motor de adquisición, retención y monetización.

Las marcas más exitosas desarrollarán cada vez más un descubrimiento continuo de productos conjunto entre Marketing, Éxito del Cliente y Producto, con el cliente en el centro. Si no estamos pensando activamente en cómo minimizar la fricción en cada interacción con el cliente y cómo fomentar su lealtad y su recomendación, es hora de que nos preocupemos mucho por esos competidores nuestros que sí están impulsados por el producto. Aquellos que no pueden o no quieren hacer estos cambios pueden quedarse atrás.

En el próximo post analizaremos las ventajas y limitaciones del Product-Led Growth.

El post “Product-Led Growth: crecimiento impulsado por el producto” 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 gestión ágil de producto no debe significar que no tengamos un plan. Debemos aplicar un plan que sea flexible para acomodar cambios en las asunciones subyacentes y mantenga un equilibrio entre el largo y el corto plazo. Eso se consigue con el enfoque conocido como Cebolla de la Planificación.

Agile y planificación de producto no son incompatibles. La planificación multicapa o “Cebolla de la Planificación” (por motivos obvios, ver figura)  ayuda a los equipos de producto a elegir el nivel adecuado de detalle dependiendo del alcance temporal en el que están planificando. Estos niveles son:

  • Visión
  • Roadmap
  • Release
  • Iteración
  • Diario

Cebolla de planificación

Visión

En lo más alto del modelo tenemos el nivel de la Visión. Como sabemos, la visión define el futuro del producto a largo plazo (que según el producto de que se trate puede ser un período típicamente de entre uno y varios años): qué problemas va a resolver y para quién los va a resolver. La visión debe expresar y ayudarnos a entender el valor que nuestro producto aporta a los clientes y cómo podría diferenciarse de otras soluciones que intentan resolver los mismos problemas.

Una forma de conseguirlo es elaborar de forma colaborativa con los implicados en la organización un lienzo de visión de producto o un artefacto similar que podamos contrastar con el mercado.

Aunque la visión debe tener una vocación de estabilidad y de referencia a largo plazo esto no quiere decir que no tenga que revisarse periódicamente (sobre todo en mercados muy dinámicos) digamos en plazos de 6 meses a un año, para adaptarla a las nuevas condiciones de clientes, competidores, tecnologías, entorno, etc.

Roadmap

El roadmap es uno de los artefactos principales de la estrategia de producto y define cómo se van a alcanzar los objetivos plasmados en la visión a lo largo del tiempo (próximos meses-años). El roadmap despliega y expande la visión en una sucesión de versiones de producto (o, como veremos a continuación, de backlogs de release).

Especialmente el roadmap interno (dirigido a departamentos y stakeholders de nuestra empresa) suele ser muy detallado -incluyendo calendarios, proyectos, tecnologías- y constituye una potente herramienta de planificación y desarrollo. El roadmap no habla (sólo) de features, sino principalmente de mercados, aplicaciones, personas, problemas, escenarios, valor, capacidades y diferenciadores clave y objetivos de negocio.

Por el contrario, el roadmap externo va dirigido al mercado, es menos detallado y constituye esencialmente una herramienta de comunicación y marketing. En cualquier caso, tanto los roadmaps internos como los externos transmiten una información de prioridades y de disponibilidad.

El roadmap debe centrarse en temas

Desde el punto de vista de planificación de producto, es útil que cada release gire alrededor de un tema que define un objetivo de negocio, una persona o un problema de cliente.

¿Y por qué es importante? Porque sólo enfocándonos en un tema vamos a poder resolverlo al 100%. De lo contrario nuestro producto siempre va a quedarse resolviendo el 40% del problema de mucha gente pero no va a ser excelente para nadie. Y, como sabemos, la gente no tiene “medios problemas”, sino problemas enteros

Las técnicas de integración y despliegue continuos típicas de los productos digitales nos permiten ir liberando un flujo continuo de funciones y características. Pero que algo se “pueda hacer” no quiere decir que sea lo mejor que “debamos hacer”. Enfocar una release en todas las funciones y características que satisfacen un objetivo de negocio, una persona o un problema de cliente tienen ventajas no sólo a la hora de implementar una solución más integrada y consistente, sino a la hora de comunicarla y venderla. Empaquetando nuestras entregas alrededor de temas estamos insuflando a nuestro producto una vocación de propósito y foco muy valiosa.

El roadmap no debe ser muy detallado en la descripción de cada release (especialmente las más alejadas en el tiempo del momento actual) y específicamente en cuanto a la UX, funciones y características que cada una debe poseer. Todo eso se irá concretando -incluyendo las necesarias actividades de descubrimiento y validación de producto– cuando se vaya acercando el momento de entregar cada una de ellas. Lo que sí es importante es que explicite cualquier precedencia y dependencia entre funciones y características del producto en sus diferentes releases.

El roadmap debe revisarse y actualizarse con mayor frecuencia que la misión (y obviamente, siempre cuando ésta ha sido modificada). Períodos entre dos y seis meses (incluso menores) son habituales.

Release

En este nivel el objetivo es especificar las funciones y características que poseerá cada release definida en el roadmap. El backlog de release es un artefacto táctico que lista los trabajos necesarios para cumplir el plan estratégico de producto y su audiencia la constituyen principalmente los equipos de proyecto y desarrollo.

Al contrario que en el roadmap, que no debería entrar en excesivo detalle sobre funciones y características, el backlog de release se compone de épicas e historias de usuario, diagramas de flujo, bocetos de diseño y mockups de experiencia de usuario.

En general, el backlog de release se deriva del roadmap. Pero la influencia contraria también es posible: el feedback sobre la release que recibimos de los clientes puede servir para reajustar el roadmap. En conclusión, roadmap y backlog deben estar sincronizados.

El backlog de release se debe actualizar con cada actualización del roadmap y con cada liberación de release.

El problema con el ”backlog de producto”

A veces se usa un artefacto que está a caballo entre el roadmap y el backlog de release, llamado “backlog de producto”, y que puede recoger un backlog que abarca varias releases. Este concepto está heredado del mundo de los proyectos de desarrollo a medida, donde no existe una estrategia de producto con diferentes releases. A mi modo de ver éste es un artefacto confuso porque mezcla el enfoque multirelease del roadmap con la concreción del backlog y hace que la idea de propósito de cada release de producto se diluya y se pierda en una mezcla sin orden ni concierto de funciones y características. En muchas ocasiones, ese backlog de producto no es más que un aluvión de desarrollos, impuestos por diversos stakeholders, pero sin una integridad y consistencia. Personalmente prefiero enfocar el backlog de producto en la próxima release. Esto crea un backlog conciso, con un propósito y un significado claros, y más fácil de gestionar.

De modo que si lo más cercano a la planificación que tienes es un backlog de producto siento decirte que no tienes un roadmap (y probablemente, tampoco una estrategia de producto).

Iteración/Sprint

En una filosofía de desarrollo ágil, en el nivel de iteración el equipo selecciona los elementos individuales del backlog que comprende el siguiente ciclo y crean un plan para entregar cada historia.

Si la metodología que se sigue es  en concreto Scrum (donde las iteraciones se conocen como sprints) probablemente se reconozca este nivel como la sesión de planificación del sprint. En cualquier caso, incluso los equipos que no aplican una metodología Scrum tienden a realizar una forma de planificación de nivel de iteración al seleccionar y planificar sus próximos trabajos en pequeños lotes.

La planificación de iteración se realiza al principio de cada ciclo, en períodos típicamente de entre dos y seis semanas.

Diario

En este nivel de planificación el equipo evalúa el status al principio del día actual y colabora para elaborar un plan para avanzar hasta el siguiente día.

Muchos equipos consiguen esto mediante un “standup” diario, una reunión en la que discuten:

  • El progreso conseguido en el día anterior
  • El progreso que esperan conseguir en el día actual
  • Los obstáculos que pueden impedir dicho progreso y qué se puede hacer para contrarrestarlos.

Si bien este ritual matutino comienza con lo que se ha conseguido en el día anterior, los equipos más eficaces reconocen que el standup es una reunión de planificación, no de status. Por lo tanto, debería centrarse en crear un plan para avanzar al nivel diario.


En conjunto, estos niveles de planificación proporcionan el compromiso entre flexibilidad y detalle necesario para gestionar productos en este mundo Agile.

El post “Niveles de planificación de producto en Agile” 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 construcción ágil de productos necesita un “cerebro” que le dé una dirección y un propósito. La planificación de producto puede contribuir a ello, pero en escenarios ágiles la planificación tradicional (fija, predictiva) no sirve. Es necesaria una planificación más ágil, que incorpore componentes de flexibilidad, aprendizaje y adaptación.

“Nosotros somos ágiles. No planificamos.” ¿Os suena esta excusa? Vamos a hablar de algunas consecuencias indeseables de esta absurda interpretación en el campo de la planificación de producto y de cómo evitarlas.

Importante: en este post nos vamos a referir al uso de Agile en el desarrollo de productos para un mercado, no proyectos de desarrollo a medida de un cliente (donde se suele denominar “producto” al resultado del proyecto).

Agile necesita un cerebro

En muchos equipos Agile hay una gran frustración. Tienen la sensación de que lo único que hacen es entregar funciones y características a toda velocidad y sin orden ni concierto, sin que los responsables de producto tengan claro hacia dónde van o qué quieren conseguir realmente. Unas características que al final no añaden valor al cliente. Estos equipos han desplegado un “Agile sin cerebro”.

Agile necesita cerebroAgile proporciona un método optimizado e iterativo de implementar, pero seguimos alimentándolo con productos que están destinados al fracaso porque no han pasado por las fases críticas de eliminación de riesgos del proceso: comprobar la deseabilidad de los clientes y la viabilidad del negocio. Como dicen los americanos, hay una diferencia entre “build the features right” y “build the right features”.

Agile es una manera de construir, pero no nos va a servir para averiguar qué construir y cómo capturar valor de nuestras iniciativas de innovación. Nos da velocidad y cumplimiento pero si lo que le suministramos son malas ideas vamos a conseguir peores resultados… con la máxima velocidad y eficacia.  Por poner una analogía, si queremos cocinar un pato laqueado estilo Pekín, más vale que utilicemos  una buena receta con sus ingredientes y proceso en lugar de algo como “cada diez minutos abre la cazuela y pruébalo. Si está soso, añade sal. Si no sabe a nada, añade más comida”.

Uno de los problemas de Agile es que -si no se refuerzan los mecanismos que animan a los equipos a considerar si las características que están incluyendo son las más adecuadas- esos comportamientos perversos van a proliferar. Por eso en Agile es importante, al igual que en el personaje del Espantapájaros del Mago de Oz, darle un cerebro.

Un cerebro para Agile

¿Y cómo podemos darle un cerebro a Agile? Hay varias herramientas para este objetivo:

  • Feedback de los clientes: tenemos que priorizarlo y operacionalizarlo, de modo que no sea un trámite. La esencia de Agile no es entregar lo más rápidamente posible desarrollos sin errores, sino aportar valor al cliente. Las revisiones del sprint no deben servir sólo para comprobar si se han implementado los elementos del backlog comprometidos, sino si estos son valiosos. No cambiemos velocidad por resultados.
  • Diseño de producto (y de modelo de negocio): Agile nos puede hacer olvidar que la experiencia del usuario debe tener sentido para ese usuario en cada release. Si renunciamos a descubrir y validar con antelación lo que se va a implementar podemos acabar con un producto fiable y bien construido pero que carezca de un significado, un valor y una interacción coherente. Es necesario combinar Agile con un diseño holístico y deliberado, enfocado en conseguir la mejor experiencia de cliente.
  • Planificación: Agile no es contrario a la planificación. Agile necesita planificación, pero de otro tipo. A este punto dedicaremos éste y el siguiente post.

Agile y planificación

La estrategia de producto ha podido ser una “baja colateral” en la transición a métodos ágiles. Muchos responsables de Agile se apegan a la noción errónea de que la idea de esta filosofía es mantenerse flexibles y que no hay que preocuparse o atarse a una dirección a largo plazo.

Siguiendo esta “no planificación” y respondiendo a las demandas instantáneas de cualquier stakeholder se pueden crear productos momentáneamente valiosos para alguien. Y se puede seguir así durante cierto tiempo, hasta que nos damos cuenta de que en realidad hemos ido “como pollos sin cabeza” y que alrededor del producto ha crecido toda una organización y esta falta de planificación ha provocado impactos que se extienden a varios grupos.

Los equipos ágiles necesitan un enfoque disciplinado para la planificación. Las organizaciones que invierten en una planificación adecuada tienen una mejor comprensión de los objetivos a largo plazo para el producto, y estrategias más realistas para alcanzar esos objetivos. Pero en escenarios cambiantes eso no se consigue con una planificación “tradicional”.

El problema con la planificación tradicional

Para entender mejor las ventajas de la planificación ágil, recordemos cómo funciona la planificación tradicional. Ésta sigue una serie de ciclos fijos y es esencialmente predictiva. Por ejemplo, en una sesión de planificación a principios de año se pueden fijar los objetivos para ese año, una estrategia y un plan detallado para alcanzarlos. Y, habitualmente, este plan tiene el mismo nivel de detalle para todos los períodos del año.

Pero -a pesar de las mejores intenciones y la confianza en esos planes- tarde o temprano la realidad golpea. Circunstancias imprevistas tales como las demandas de los clientes, los movimientos competitivos o desarrollos en el mercado global van a hacer que algunas partes de esos planes sean inalcanzables o incluso irrelevantes.

Pero, en lugar de intentar reconciliar el plan con esa nueva realidad, el equipo redobla sus esfuerzos para alcanzar sus aspiraciones anteriores. Finalmente esto da como resultado que el equipo tiene permanentes dificultades para alcanzar las expectativas de un plan inalcanzable y la organización está permanentemente decepcionada con su incapacidad para conseguirlo. En muchos casos, ésta es la realidad de la planificación tradicional.

¿Qué es la planificación ágil?

Una de las características de los enfoques de planificación ágil es que el equipo puede planificar con diferentes niveles de detalle dependiendo del alcance temporal para el cual están planificando. Por ejemplo, puede planificar sus objetivos para el año a alto nivel, su estrategia para alcanzar esos objetivos durante los próximos meses con un poco más de detalle y los pasos necesarios para implementar esa estrategia durante las próximas semanas con el máximo detalle. Este enfoque evita la necesidad de predecir en detalle el futuro lejano (con los riesgos que apareja) y proporciona al equipo claridad en cuanto a sus responsabilidades en el corto plazo, a la vez que les ayuda a entender cómo esa responsabilidad contribuye a los objetivos a largo plazo.

Pero la principal característica de los planes ágiles es que a medida que avanzamos en el tiempo, es posible que el equipo adapte y reelabore sus planes basándose en lo que ha ido aprendiendo durante el período. Los planes ágiles no son sólo planes para ejecutar sino también planes para aprender. Por tanto, Agile no significa que no tengamos un plan. Significa que tenemos un plan que es suficientemente flexible como para acomodar cambios valiosos e importantes en las asunciones subyacentes a dicho plan.

En lugar de operar al nivel de funcionalidad o característica, la planificación ágil necesita funcionar al nivel de visión o temática: establecer objetivos basados en áreas de mercado, necesidades de clientes o temas funcionales, y no en entregables funcionales o características definidos específicamente. Esto proporciona al negocio una base para saber hacia dónde ir pero mantiene la flexibilidad para cambiar el plan, bien en cuanto al entregable específico dentro del tema o bien cambiando el propio objetivo temático.

¿Y cómo alcanzamos ese equilibrio entre planificación a corto y largo plazo? Muchos equipos ágiles utilizan un enfoque de planificación multicapa, también conocido como la “Cebolla de la Planificación”, y que describiremos en el siguiente post.

El post “Planificación de producto y Agile: ¿son incompatibles?” 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

¿Cómo acotar el espacio del problema a la hora de definir un producto? Después de entender las necesidades de los clientes hay que expresarlas como un conjunto de requisitos priorizados.

En las anteriores entregas de este post hablamos de la importancia de acotar el espacio del problema para desarrollar un producto y de cómo entender las necesidades de los clientes. En esta entrada analizamos diversas formas de articular esas necesidades en forma de requisitos que sirvan de base al diseño y la implementación de la solución.

Requisitos: expresando problemas de mercado

RequisitosEn definitiva, la comprensión de los problemas de los clientes tiene por objetivo identificar un conjunto de necesidades de dichos clientes lo más completo posible, estructurado (en una jerarquía o similar) y priorizado. A esta colección de expresiones de problemas es lo que se conoce como requisitos (de mercado) y constituye el componente principal del Market Requirements Document (un artefacto tradicional usado en desarrollo de productos).

Los requisitos no son especificaciones

Es importante resaltar que los requisitos son expresiones de problemas, no de soluciones. Las referencias a posibles formas de resolver el problema corrompen los requisitos, que deben ser siempre agnósticos respecto a la implementación. Sólo cuando entramos en fase de Diseño generamos un concepto de solución, una experiencia de usuario deseada y una descripción funcional que reflejan la manera en que esa solución resuelve el problema. Esa descripción se traduce en especificaciones de producto. En definitiva un requisito expresa el PARA QUÉ, una especificación expresa el CÓMO.

Artefactos para expresar requisitos

Existen muchos enfoques para expresar requisitos, a continuación os resumo los que han ido apareciendo por este blog. Es importante tener en cuenta que para cada una de ellos existen métodos y procesos para destilar las necesidades y convertirlas en requisitos, que iremos describiendo en futuros posts.

  • Expresiones literales (verbatims) de los clientes. Ésta es la forma preferida por los enfoques tradicionales de análisis VoC (Voz del Cliente). Según ellos, las citas literales dan idea del mundo del cliente, de cómo él percibe y vive sus problemas. Por eso según estas técnicas no sólo hay que utilizar las expresiones de los clientes, sino que la estructuración y priorización de estas expresiones también deben realizarlas los propios clientes, para evitar que los proveedores contaminen el análisis con sus ideas y soluciones.
  • Trabajos y Job Stories. Provenientes de la filosofía Jobs-To-Be-Done, las job stories tienen la forma
    Cuando <SITUACIÓN> quiero <MOTIVACIÓN> de manera que <RESULTADO>
    (por ejemplo: “Cuando un nuevo cliente importante se registra quiero que se me notifique, de modo que pueda iniciar una conversación con él”) y tratan de explicitar el contexto y el problema específico que hay que resolver en esa situación.
  • Resultados deseados. También relacionados con la filosofía Jobs-To-Be-Done y en las antípodas de las expresiones literales de los clientes, Tony Ulwick de Strategyn propone unas expresiones de necesidad que él denomina resultados deseados que siguen una sintaxis precisa:
    <DIRECCIÓN DE LA MEJORA> <UNIDAD DE MEDIDA> <OBJETO DE CONTROL> <CONTEXTO>
    (por ejemplo, “Minimizar la probabilidad de hacer cambios inadvertidos en la configuración cuando manipulo el dispositivo”). Estos resultados deseados son métricas que el cliente usa para medir el éxito cuando está realizando un trabajo.
  • Mi formato favorito para expresión de requisitos está muy influido por las enseñanzas de Pragmatic Marketing y tiene la forma:
    <PERSONA> cuando <ESCENARIO> necesita resolver <PROBLEMA>
    (por ejemplo, “el Gerente de Ventas, cuando una vez a la semana lleva a cabo una revisión de su territorio con el Director Comercial, necesita conocer el estado de todas las cuentas de los miembros de su equipo”).
    Este formato tiene la ventaja de que, además de explicitar el contexto y el problema a resolver, identifica a la persona (arquetipo) que lo padece. Esto es útil en productos de compra compleja, con varios usuarios diferentes y con varios roles involucrados en la compra y uso del producto, cada uno con sus objetivos y necesidades.
  • NOTA: diferencias con las user stories. Las historias de usuario son un artefacto de las metodologías ágiles que se utilizan para la especificación funcional de un producto. Tienen la forma
    Como <PERSONA> quiero/necesito <HACER ALGO> para conseguir <BENEFICIO>
    y se utilizan en la fase de Implementación de producto, para definir las funcionalidades que se van a construir en un sprint. Por lo tanto las user stories tienen sentido cuando ya se ha diseñado (al menos parcialmente) el producto y no residen en el espacio del problema sino en el de la solución.

El marco importancia / satisfacción

El proceso de recogida de requisitos suele finalizar con una estructuración de dichos requisitos en una jerarquía de temas y con su valoración según dos ejes: la importancia que para los clientes tiene ese requisito y el grado de satisfacción de dicho requisito mediante las soluciones actuales. Tanto la estructuración de los requisitos como su valoración según esos dos criterios deben ser realizadas por los clientes, para definir el espacio de problema desde su punto de vista. Obviamente las mayores oportunidades para el desarrollo de nuevos productos radican en requisitos que son muy importantes para los clientes pero que no están adecuadamente satisfechos por las soluciones actuales.

En conclusión, los requisitos son “requisitos del mercado”, no (especificaciones) del producto. La principal responsabilidad del equipo de producto para con sus colegas de diseño y desarrollo es proporcionarles requisitos que expresen problemas de mercado que valga la pena resolver. Sólo eso facilita el desarrollo de productos que los clientes quieran comprar.

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

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

Deja un comentario

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

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

Cómo entender el problema del cliente

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

Lo que los clientes dicen

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

Lo que los clientes hacen

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

Lo que los clientes construyen

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

La actividad cerebral de los clientes

El neuromarketing mide señales neurológicas y fisiológicas (principalmente, estados físicos del cerebro) para conseguir insights sobre las motivaciones, preferencias y decisiones de los consumidores. Con este acceso más directo a los procesos cognitivos y comportamentales se intenta soslayar las limitaciones de las técnicas tradicionales de investigación basadas en la expresión directa y conseguir información que los investigados no desean o no son capaces de manifestar.

La interpretación del mercado

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

La experimentación y aprendizaje en el mercado

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

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

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

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

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

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

Deja un comentario

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

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

Espacios de problema y solución

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

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

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

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

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

No saltes demasiado pronto al espacio de solución

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

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

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

El problema define el mercado

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

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

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

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

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

Deja un comentario

La transición desde un modelo de negocio basado en proyectos a medida hacia otro basado en producto estándar es difícil. Seguimos repasando los escollos de origen interno que nos impiden convertirnos en una empresa de producto.

En esta segunda parte del post vamos a seguir desgranando algunas de las barreras que nosotros mismos nos ponemos en el camino hacia un negocio basado en producto. Estas barreras provienen de ideas como las siguientes:

Producto sin Mercado

“Ya le hemos vendido esto a dos clientes: ya tenemos un producto”

Es una versión ampliada y corregida del caso anterior: si ya hemos conseguido vender algo a varios clientes, con mayor motivo deberíamos poder explotarlo como un producto. Y lo que dijimos para aquel caso sigue siendo válido aquí: convertir ese “producto” en un negocio escalable puede ser difícil debido a la carencia de la propiedad intelectual, a un diseño funcional, experiencial y técnico deficiente que hace imposible su evolución y mantenimiento, y a la inexistencia de un mercado real para el potencial producto.

Pero además puede darse una circunstancia adicional, y es que lo que la empresa proveedora considera un producto no es percibido como tal por el mercado. Como todo, es cuestión de perspectiva y aquí vale la pena recordar esa famosa frase de Drucker de que “el comprador raramente compra lo que el vendedor cree que está vendiendo”). Y en general el cliente compra una solución, no ve el producto que va dentro.

Me explico. Muchas veces ocurre que las empresas tecnológicas comienzan desarrollando tecnologías que en el mejor de los casos llegan a cristalizar en “herramientas” o componentes reutilizables en varios de sus clientes. Estas herramientas les sirven para optimizar y abaratar la entrega de soluciones a medida para sus clientes en un cierto ámbito, por ejemplo, en el campo del software suelen tomar la forma de “motores” o bibliotecas de programas.

En esta etapa algunas empresas consideran que han desarrollado un “producto” porque lo han instalado en varios clientes e, incluso, le han dado una identidad y unas especificaciones que lo hacen más tangible, fiable y creíble.

Pero ¿una herramienta para desarrollar soluciones a medida es un producto? En muchos casos, en realidad no se trata más que de una pieza reutilizable en sus desarrollos que dista mucho de la solución completa que necesita el cliente y carece de la estandarización, documentación y soporte que caracterizan a un producto real.

Y para estos proveedores, no invertir lo suficiente para lograr un producto “completo” y estandarizado crea barreras para escalar. Hasta cierto punto, continúa siendo un negocio de desarrollos a medida camuflado como negocio de producto, pero sustancialmente menos escalable y rentable. Un negocio que no escala bien porque sigue siendo muy intensivo en actividades a medida del cliente y en la utilización de personal especializado (encargado de desarrollar las soluciones).

(Nota: sin embargo, los servicios alrededor de un producto estándar pueden constituir un negocio muy lucrativo, especialmente si se trata de servicios especializados basados en tecnologías más o menos propietarias.)

Este comportamiento puede ser una trampa para algunas empresas tecnológicas que, por no apostar e invertir en estandarizar y replicar, siguen estancadas en un negocio en el que se renuncia a las posibilidades de diferenciación (y rentabilidad) que proporciona un producto.

La clave para que un producto “incompleto” pueda constituir la base de un negocio escalable y rentable está en estos factores:

  • Qué proporción de la solución al problema de los clientes es “producto” directamente disponible y estándar, frente a la proporción que consiste en configuración/ adaptación/ desarrollo complementario sobre él
  • El nivel de madurez, estandarización, documentación y soporte de la parte de “producto reutilizable” y, como consecuencia, quién puede realizar la adaptación/ desarrollo sobre él: la empresa proveedora del producto, sus partners, los clientes finales.

Si lo que ofrece el producto está muy lejos de la solución que necesitan los clientes y el nivel de estabilidad y documentación de ese producto hace difícil que otros puedan desarrollar la parte que falta, la empresa proveedora estará obligada a realizar ese trabajo siempre y su negocio -aunque pueda ser rentable en ese ámbito- no va a escalar bien.

Y en mi experiencia, sólo si se tiene un producto base líder es posible construir un ecosistema escalable en el que tanto la empresa como sus partners (revendedores de valor añadido, integradores) ganen dinero con el desarrollo de soluciones alrededor de dicho producto.

“Alguien nos ha pedido esta funcionalidad adicional: vamos a añadírsela al producto”

Un negocio basado en producto conlleva tensiones, especialmente entre los objetivos del corto plazo (sobrevivir) y el largo (desarrollar nuestra visión), y eso es fuente de conflicto y fricciones dentro de la empresa.

Una de las más típicas es que se produce ante peticiones de nuevas features & functions  por parte de potenciales clientes (y otros stakeholders tanto internos como externos). Con frecuencia, la decisión suele consistir en acceder a la petición sin mayor análisis, lo que inevitablemente lleva a convertir el producto en una especie de monstruo de Frankenstein, un popurrí de atributos y experiencias de uso inconexas.

Estos productos se caracterizan por resolver el 50% del problema del 100% del mercado, pero no llegan a resolver el 100% del problema de nadie, y suelen incorporar múltiples atributos que luego no tienen demanda del mercado (y que invariablemente acaban resultando más caros de implementar de lo previsto).

Además, un  crecimiento desordenado  de features distrae nuestros escasos recursos, nos impide concentrarnos en aquéllas que son verdaderos drivers de valor para el cliente y nos aleja de nuestra visión de producto. Como hemos dicho en otras ocasiones la “featuritis” conlleva una baja usabilidad y como consecuencia una baja satisfacción a largo plazo del cliente que perjudique la vida del producto. Sin olvidar que constituye la principal causa de deuda técnica.

Tener una estrategia y una visión de producto significa decir “no” muchas veces… Sin embargo a veces decir “no” también puede ser señal de una carencia de estrategia. Por ejemplo, a veces nos negamos a desarrollar una nueva feature no porque no encaje en nuestra visión, sino porque no hemos encontrado un cliente que costee completamente dicho desarrollo. Pero muy pocos clientes potenciales van a pagarnos ese desarrollo o a comprometerse con nosotros si ya hay otros proveedores que les ofrecen esos atributos como parte de un producto estándar y a un precio razonable hoy. Para el que no tiene un roadmap, todas las solicitudes de features son como proyectos a medida que deben ser rentables de manera inmediata

Pero si esa nueva feature nos acerca a nuestra visión, aporta valor a nuestros clientes objetivo y va a generar negocio en el largo plazo, el no tener a alguien que pague el desarrollo completo no debe ser un obstáculo: deberíamos captar los recursos necesarios para desarrollarla.

Y por eso en una empresa basada en productos son tan importantes la visión, la estrategia y el roadmap, temas sobre los que volveremos pronto por aquí.

¿Cuál es vuestra experiencia en la transición de una empresa de un modelo basado en proyectos a otro basado en productos?

El post “Los escollos que nosotros mismos nos ponemos para convertirnos en una empresa de producto (2)” se publicó primero en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

Deja un comentario
A %d blogueros les gusta esto: