Crecimiento de productos tecnológicos

Posts from the ‘desarrollo de producto’ category

Necesitamos un nuevo Product Management (1)

por en 30 diciembre 2013

La gestión de producto debe adaptarse a estos nuevos tiempos dominados por el poder de los clientes, la innovación y la volatilidad. Las filosofías basadas en el descubrimiento de mercados, la agilidad, el diseño de experiencias y la validación de clientes y productos pueden contribuir a renovar el Product Management.

El Product Management no tiene últimamente muy buena prensa. De un tiempo a esta parte muchos gurús vienen desacreditando la (“antigua”) actividad de gestión de productos:

Combinando Agile, Design Thinking, Customer Development, LeanLlevamos algunos años anunciando la muerte del Product Management… por lo menos tal y como se concebía hasta ahora. Pero algunos de los consultores y autores que venden estas ideas esencialmente gestionan negocios cuyo éxito se basa en gran medida en que estas predicciones lleguen a hacerse realidad.  Es importante tener en cuenta posibles conflictos de interés a la hora de valorar ciertas opiniones.

Por centrar el debate, dejemos claras un par de cosas:

  • La gestión de producto tradicional (y no olvidemos que esta función empezó a definirse hace menos de 80 años) ha estado influida -igual que otras funciones de la empresa- por filosofías basadas en la planificación rígida, en organizaciones jerárquicas, en procesos secuenciales, en burocracia… Este enfoque ha podido resultar eficaz en épocas de cambio lento y de innovación limitada, cuando las empresas controlaban sus mercados, pero no lo es en esta era en que las nuevas tecnologías aparecen cada día, habilitando modelos de negocio radicalmente nuevos y en que unos clientes cada vez más conectados e informados están al mando. Necesitamos adaptar el Product Management a esta nueva era.
  • La gestión de producto se puede mejorar. Si la ingeniería de software se ha podido beneficiar de las metodologías iterativas y evolutivas o del prototipado rápido (sin que por ello tengamos de cambiar de nombre a esta actividad) el Product Management puede adoptar principios de Agile o Design Thinking para hacerse más flexible y adaptarse a esta era cambios e incertidumbre. Pero no pensemos que el nuevo Product Management equivale a Customer Development o que el nuevo Product Manager es el Product Owner. Como hemos visto, ninguna de estas metodologías/roles abarca todo el espectro de funciones  que exige la gestión de producto.

En realidad, la función/rol de Product Management nunca ha sido más importante que ahora, especialmente en productos tecnológicos. Más que nunca, las empresas seguirán necesitando 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 (recordemos que la gestión de productos es mucho más que el desarrollo de nuevos productos).

Bien sea un Jefe de Producto experimentado o bien el propio CEO quien desempeñe esa función necesitamos una persona (y no un comité) que se responsabilice de gestionar el producto como un negocio.  Por eso los rumores sobre la muerte del Product Management han sido enormemente exagerados, como lo demuestra el hecho de que incluso las empresas tecnológicas más avanzadas siguen contratando Product Managers expertos.

Pero eso requiere que el Product Management se adapte a la extrema volatilidad y velocidad de los mercados, clientes y tecnologías actuales.

Necesitamos un Product Management más Agile / Lean / ….. (escribe tu buzzword favorita)

Hacer un Product Management más moderno significa incorporar de manera crítica lo mejor de las nuevas filosofías de una forma no dogmática y sin caer en prescripciones “religiosas” ni en liturgias innecesarias… a la vez que se preserva lo que sigue funcionando.

Creo que es estéril definir si el nuevo Product Management debe estar más basado en Agile o en Design Thinking, Customer Development, o Generación de Modelos de Negocio (no me gusta participar en guerras de religión). Como hemos visto por aquí, todas estas filosofías tienen muchos puntos en común -aunque también algunas contradicciones, que se van superando paulatinamente. Pero lo más importante es que en conjunto renuevan y aportan una nueva dimensión a la gestión de producto.

Este nuevo enfoque para el Product Management se debe caracterizar 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 Product Manager debe ser el experto en el mercado y la voz más autorizada en el equipo. No se conforma con recibir de una manera reactiva los requisitos que le envían todos los interesados (clientes, vendedores, desarrolladores, directivos) sino que de una manera activa genera customer insights e información de mercado. Para ello aplica un conjunto ecléctico de técnicas para entender lo que el mercado necesita y cómo crear valor para los clientes (y no limitarse a escuchar lo que algunos usuarios dicen que quieren).

El Product Manager destila esos inputs para descubrir problemas y necesidades que vale la pena resolver (en términos de su importancia, urgencia y extensión) y mantiene una lista priorizada de problemas abiertos y de la oportunidad de mercado asociada con cada uno. Para cada oportunidad de mercado prioritaria el Jefe de Producto elabora y valida una visión del producto que sirva para alinear a todo el equipo y mantenerlo enfocado en los segmentos de mercado, personas (de comprador y usuario) y problema a resolver.

El uso de datos de mercado en lugar de opiniones y convenciones, la iteración y la colaboración en equipos multidisciplinares son la clave de todas las actividades: no sólo en desarrollo, también en la comercialización, la evolución y el control del producto.

En conjunto, este movimiento implica cambios en las filosofías, los procesos y los artefactos del Product Management, que iremos detallando en la segunda parte de este post.

El post “Necesitamos un nuevo Product Management (1)” 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.]

9 comentarios

Agile: ¿necesitamos Product Managers, Product Owners o ambos? (2)

por en 3 noviembre 2013

Hacer que una misma persona desempeñe las funciones de Product Manager y Product Owner puede ser una opción válida si las circunstancias nos obligan, pero entraña un gran riesgo de fallo. Si es posible, lo mejor es dedicar recursos exclusivos para ambas funciones, que trabajen en estrecha colaboración.

Tanto el rol de Product Manager como el de Product Owner son funciones muy exigentes, que demandan una dedicación exclusiva. A eso se añaden las diferencias de foco, relación, etc. de ambos roles, que exigen perfiles muy diferentes:

  • El rol de Product Management tiene un foco más estratégico y centrado en el negocio y el mercado (éxito del producto), está más volcado hacia el exterior de la empresa y hacia los departamentos internos que deben colaborar para alcanzar ese éxito y su interacción con los clientes gira alrededor de sus necesidades presentes y futuras.
  • El rol de Product Owner tiene un foco más táctico y técnico, está más volcado hacia el interior de la empresa (equipo de implementación) y su interacción con los clientes se centra en las features a entregarles de manera inmediata.

Sin embargo, las circunstancias mandan y a veces resulta imposible cubrir ambas funciones con puestos (y personas) dedicados en exclusiva a cada una de ellas. En las empresas reales es muy habitual que un Product Manager deba asumir también el rol de Product Owner y viceversa.

Product Manager and Product Owner

¿Puede un Product Manager asumir el rol de Product Owner?

Mi opinión es que un Product Manager experimentado puede asumir también con garantías la función de Product Owner en un producto de una complejidad moderada. Sin embargo, también puede ocurrir que ese Product Manager fracase a la hora de sacar todo el partido de Agile y entre en alguno de los siguientes “modos de fallo”.

Dónde puede fallar un Product Manager que asume también funciones de Product Owner

Los problemas suelen venir cuando el Product Manager carece del tiempo, los recursos o la experiencia para desarrollar ambas funciones y acaba dando prioridad a una de ellas, que suele ser la suya original como Jefe de Producto. Como consecuencia:

  • Tiene una integración “a tiempo parcial” con el equipo técnico y nunca llega a sacar partido de la capacidad de éste para cambiar de dirección.
  • Prefiere enfocarse en los aspectos más globales -descuidando las labores del día a día del Product Owner- y acaba obligando a Ingeniería a asignar sus propios Product Owners… que tienen que adivinar lo que quiere ese Product Manager remoto.
  • Ocasiona que historias de usuario y pruebas de aceptación adolezcan de falta de detalle y actualización.

Eso se traduce en una insuficiente presencia de la voz del mercado durante la construcción del producto y, como consecuencia, en la implementación de features que no son aceptadas, reelaboraciones costosas, frustración en el equipo e incapacidad para entregar valor para el cliente.

¿Puede un Product Owner asumir el rol de Product Manager?

La realidad nos muestra que incluso un Product Owner experimentado tiene dificultades para asumir todas las funciones de Product Manager. Ello se debe a que las actividades más estratégicas y de relación con el mercado, la visión de negocio y la coordinación con los departamentos no técnicos de la empresa no figuran entre sus habilidades y experiencia.

Dónde puede fallar un Product Owner que asume también funciones de Product Manager

Aunque los veremos con más detalle en otro post, estos son los modos de fallo más habituales:

  • Foco en entregar features, no en la estrategia de producto a largo plazo: visión, roadmap.
  • Asunción de que los clientes que participan en las revisiones de producto representan al conjunto del mercado.
  • Desconocimiento de aquellas facetas del producto que condicionan su éxito en el mercado: precios, packaging/bundling, ofertas complementarias, valor para el cliente, diferenciadores competitivos.
  • Desconexión respecto a los departamentos internos (Marketing, Ventas, Dirección…) que deben colaborar para convertir el producto en un negocio.

La consecuencia de todo ello es un equipo de desarrollo muy productivo… pero que entrega un producto que no responde a un target claro, se lanza en el momento equivocado, con un precio inadecuado, con unos departamentos de Comercial y Soporte insuficientemente habilitados y, consecuentemente, incapaz de alcanzar su mercado objetivo y de aportar el beneficio esperado.

Si es posible, separar las funciones de Product Manager y Product Owner

En empresas de producto que aplican metodologías ágiles de implementación basadas en Scrum, las figuras del Product Manager y Product Owner (cada una con su alcance y funciones) son imprescindibles. Pero para desarrollarlas con el grado de profundidad y dedicación que requieren y evitar los modos de fallo enumerados anteriormente es conveniente que cada una esté desarrollada por personas especializadas y con dedicación completa:

  • Product Manager – el «CEO del producto», enfocado en los aspectos de negocio y en el mercado desde una perspectiva estratégica, encargado de “construir las features correctas” para crear y comercializar un producto que tenga éxito en el mercado.
  • Product Owner – integrado en el equipo de ingeniería ágil, enfocado en proporcionar funcionalidad a los clientes, encargado de “construir correctamente (y rápidamente) las features”.

La ingeniería ágil puede mejorar la calidad y la flexibilidad en la construcción de nuestros productos. Y un enfoque ágil aplicado a toda la gestión de producto -y en general al conjunto de las funciones de la empresa- puede conseguir que seamos más adaptables, centrados en el mercado y rápidos. Pero eso no se consigue optando por la figura del Product Owner en lugar del Product Manager (o viceversa), sino desarrollando ambas funciones de la manera más coordinada y eficaz posible.

El post “Agile: ¿necesitamos Product Managers, Product Owners o ambos? (2)” se publicó primero en “Marketing & Innovación”.

[Una buena función de «product management» es imprescindible para gestionar cada producto como un negocio. Descubra en este taller práctico cómo implementar una gestión de productos realmente enfocada en el mercado.]

7 comentarios

Agile: ¿necesitamos Product Managers, Product Owners o ambos? (1)

por en 26 octubre 2013

Entre el Product Manager y el nuevo Product Owner de Agile existe un cierto solapamiento que hace que muchos se pregunten si son necesarios los dos. Pero en realidad el problema no es de personas o de puestos, sino de cuál es la mejor manera de desempeñar ambas funciones.

Algunas metodologías de Agile introducen un nuevo rol relacionado con la gestión de «producto»: el Product Owner. Su principal responsabilidad es representar al negocio ante el equipo de implementación, actuando como la voz del cliente, gestionando el backlog y priorizando historias de usuario. La función de Product Owner, originalmente muy táctica y ligada al equipo de proyecto, es una exigencia de las metodologías basadas en Scrum.

Por otra parte, 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 la concepción y construcción a su explotación comercial y ulterior retirada: ese es el rol que se suele conocer como Product Manager.

Equilibrio Product Manager Product Owner

Así definidos, los papeles de Product Manager y Product Owner son muy diferentes, aunque tienen zonas comunes. Sin embargo, en empresas de producto se está produciendo una tendencia del Product Owner a abarcar actividades más estratégicas -que tradicionalmente forman parte de la responsabilidad del Product Manager- y es habitual que surja la controversia ¿es necesario dotarse de uno u otro, de los dos… o basta con una persona para desempeñar ambas funciones?

Para poner las cosas en contexto, recordemos algo: aunque las ventajas de Agile son indudables, simplemente adoptar una metodología de implementación ágil no es la solución al desarrollo de productos. Agile ayuda a entregar algo antes y bien, pero sin un conocimiento del mercado, una visión y un diseño aquello que se entrega puede que realmente no nos ayude a vender más productos. Sin la función de Product Manager en un entorno ágil corremos el riesgo de construir el producto equivocado. Podríamos terminar deleitando al cliente que ha participado en nuestro proceso ágil, pero no siendo capaces de vender al producto a nadie más.

En realidad, aunque todas las empresas de producto necesitan Product Managers, no todas necesitan Product Owners. Antes de empezar a analizar el problema vale la pena recordar que hay varios contextos donde esta polémica no existe:

  • En empresas de producto para un mercado que no aplican Agile la figura del Product Owner no es estrictamente imprescindible. Si las necesidades de gestión de producto lo requieren es habitual crear el rol de Technical Product Manager encargado de la coordinación con el equipo de Tecnología y de suministrarle el input del mercado.
  • En empresas de proyectos a medida de clientes singulares -no de productos repetibles para un mercado- en general no se necesitan Product Managers. Si para esa gestión de proyectos se aplica alguna metodología basada en Scrum, el Product Owner sí es obligatorio.

Para el resto de casos –empresas de producto que aplican metodologías ágiles– la primera tentación es “aplicar el manual” de descripción de los roles y dar una respuesta obvia: si el Product Manager es responsable de gestionar su producto como un negocio durante todo su ciclo de vida y el Product Owner es el representante del negocio ante el equipo de implementación, entonces el Product Owner es el representante del Product Manager ante el equipo de implementación (lo cual no deja de ser una buena referencia).

Los nombres de los puestos importan menos que las funciones y las actividades

Sin embargo, esta respuesta tiene una carencia fundamental: asume que Product Manager y Product Owner son puestos o personas, cuando en realidad son roles o funciones. El “conflicto” entre Product Manager y Product Owner en empresas de producto no consiste tanto en decidir qué puestos crear como en asegurar que ambas funciones se realizan de la manera más armónica y eficaz.

Y la manera óptima de implementar y orquestar las funciones de Product Manager y Product Owner depende de muchos factores, entre ellos:

La fase en el ciclo de vida en la que se encuentra el producto. Veamos por ejemplo lo que ocurre al principio y al final del ciclo:

  • Cuando el producto está en desarrollo, la intensidad necesaria en las funciones de Product Manager y Product Owner hacen que sea conveniente cubrirlas con sendas personas con dedicación completa.
  • Cuando el producto pasa a la etapa de evolución/mantenimiento las exigencias son menores y puede ser suficiente con que una misma persona desempeñe ambas funciones.

La estructura organizativa de la empresa. Veamos un par de ejemplos extremos:

  • En la típica start-up formada por “dos amigos en un garaje” es muy habitual que uno de ellos asuma las funciones más relacionadas con el exterior (mercado, socios, inversores) y el otro las funciones más internas (ingeniería, tecnología). Eso se traduce en que el primero desempeña el papel de CEO + Product Manager + Product Owner y el segundo el de CTO + Jefe de Proyecto (Scrum Master).
  • En una empresa multiproducto con productos complejos (cuya construcción puede involucrar a varios equipos dispersos) lo habitual es que por cada producto exista un Product Manager que se ocupa de las actividades más estratégicas y de relación con el mercado, y que interactúa con varios Product Owners (uno por cada equipo de implementación).

Dependiendo del escenario, hay casos en los que un Product Manager asume la función de Product Owner, un Product Owner asume la función de Product Manager o ambas funciones son desempeñadas por diferentes personas… casos de los que hablaremos en la segunda parte de este post.

El post “Agile: ¿necesitamos Product Managers, Product Owners o ambos? (1)” 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.]

9 comentarios

Agile y el papel del Product Owner en empresas de producto

por en 28 septiembre 2013

La imparable adopción de filosofías Agile en el desarrollo de productos viene suscitando una cierta polémica sobre el papel del Product Owner y su intersección (en algunos casos, colisión) con el del Product Manager.

En este post introductorio no pretendo hacer una descripción detallada de la función del Product Owner (no soy un experto y podéis encontrar miles de mejores referencias), sino centrarme en algunas de sus peculiaridades en empresas orientadas a producto y en la evolución que está experimentando para adaptarse a estos entornos.

Pero antes de empezar tal vez convenga recordar un par de características de Agile que influyen en este tema (y que hemos tratado anteriormente aquí y aquí). Aunque originalmente las metodologías Agile provienen del campo de los proyectos a medida de un cliente, es en los últimos años cuando se han incorporado al desarrollo de productos repetibles para un mercado. Sin embargo, por su propia naturaleza, Agile se aplica principalmente a las actividades de construcción / implementación del producto, es decir, entra en juego cuando se ha analizado la oportunidad de mercado y se ha decidido que se va a construir “algo” (la “unidad 0” de un producto replicable).

Product Owner y gestión de proyectos

El rol o función de Product Owner proviene de Scrum, una metodología Agile de gestión de proyectos en la que el equipo colabora unido e integrando continuamente el feedback del cliente a través de un proceso iterativo dividido en sprints.

En sus orígenes, el Product Owner de Scrum era un rol táctico, orientado al proyecto e integrado en el equipo técnico que lo ejecuta. Su misión era representar al “negocio” en el proyecto y asegurar que las decisiones de implementación estaban alineadas con las necesidades del cliente y que cualquier problema o duda se resolvía lo antes posible. Para ello actúa como interfaz entre el cliente y el equipo técnico, recabando el feedback del primero al final de cada sprint y adaptándose a los cambios en sus necesidades.

El Product Owner está en contacto permanente con equipo de proyecto (jefe y desarrolladores) gestionando el backlog de la release, elaborando y priorizando historias de usuario, expandiendo especificaciones y tomando decisiones inmediatas sobre funcionalidad y prioridades. Originalmente, en escenarios de proyectos a medida, era incluso habitual que el propio Product Owner fuera un miembro de la organización cliente. En estas circunstancias el Product Owner era literalmente el dueño del “producto” (entendido éste como el resultado del proyecto).

Product Owner y construcción de productos

La gestión de productos replicables para un mercado difiere de la gestión de un proyecto para un cliente en muchos aspectos fundamentales. Empezando por el hecho de que en el escenario de producto repetible no hay un cliente predefinido, sino una mezcla de clientes más o menos heterogéneos y desconocidos (y que en el mejor de los casos podremos segmentar y representar mediante uno o varios arquetipos significativos de clientes). Por eso uno de los primeros pasos en el desarrollo de un producto es acotar el espacio de problemas de mercado y definir el problema a resolver.

Como consecuencia, resulta prácticamente imposible que el Product Owner sea una persona proveniente de la (o, mejor, una) organización cliente: tiene que tratarse de un miembro de la empresa desarrolladora, encargado de representar al mercado en las actividades de construcción del producto. Unas actividades que se enmarcan en un ciclo de vida de producto mucho más amplio y que abarca desde el análisis de la oportunidad de mercado hasta la comercialización del producto.

Aplicado al desarrollo de productos para un mercado, el rol del Product Owner es muy exigente: antes de planificar los sprints, debe escribir historias de usuario y colaborar con el equipo de testing para definir los criterios de aceptación. Durante la planificación de los sprints debe explicar al equipo de implementación las historias sobre las que van a trabajar a lo largo de las siguientes semanas. Durante el sprint (típicamente 1-4 semanas) supervisa el avance, toma decisiones sobre alternativas de implementación,  responde a preguntas, valida las historias terminadas y prepara las historias para el siguiente sprint.

Del Product Owner se espera que esté disponible para el equipo cuando aparecen dudas y que mantenga actualizado el backlog del producto, reorientando las prioridades en función del feedback de los clientes y otros afectados, unas responsabilidades que exigen una presencia casi continua en la war room. El del Product Owner es un trabajo a jornada completa.

Por poner este rol en el contexto de empresas de producto, podemos compararlo con las funciones típicas del Product Manager. En este post Rich Mironov toma el Framework de Pragmatic Marketing al que nos hemos referido otras veces y superpone las actividades del Product Owner.

Agile Product Manager - Product Owner

Así obtenemos una perspectiva de las funciones del Product Owner y de su intersección con las actividades globales de Product Management: ocupan un área a caballo entre la zona estratégica y la táctica y muy centrada en el hemisferio más “técnico” del plano. De hecho, el alcance del rol de Product Owner guarda un gran paralelismo con el del clásico Technical Product Manager, si bien algunas de las actividades que desempeñan, la cadencia con que las realizan (y, desde luego, el nombre que les dan ;- ) son muy diferentes.

Y en este contexto el nombre de Product Owner es menos afortunado: en general sigue estando más enfocado en el proyecto de construcción que en el resto de la vida del producto y la propiedad que ejerce no abarca mucho más que el backlog y las historias.

El Product Owner ideal… y el real

En aquellas empresas que aplicaron un Agile “de manual” al desarrollo de productos (lo que en muchos casos significa la exclusión de la figura del Product Manager) pronto se descubrió que el alcance original del Product Owner era insuficiente para asegurar el éxito del producto en el mercado. Como consecuencia, los defensores de Agile han ido reclamando para el Product Owner la responsabilidad sobre un rango más amplio de funciones que van desde la visión y el roadmap de producto hasta la asignación de recursos.

Se ha pretendido evolucionar hacia un Product Owner ideal (una especie de “Súper Product Owner”) más estratégico y centrado en el negocio, aunque ello ha llevado a una cierta explosión de sus atribuciones… y a una tendencia sospechosa a solaparse con el papel tradicional del Product Manager. En general, esta definición del papel del Product Owner responde a una concepción de la gestión de producto desde la óptica del departamento de Tecnología, que inevitablemente resulta incompleta (y, en ocasiones, sesgada).

Además, en la realidad el puesto de Product Owner es habitualmente cubierto con personal del departamento de Tecnología/Ingeniería con escasos conocimientos del mercado (clientes, competidores) y de otras áreas y funciones de la empresa. Y eso limita su capacidad para realizar eficazmente las tareas de interacción externa e interna necesarias para garantizar el éxito del producto.

Algunos autores y consultores que promueven este nuevo papel del Product Owner llegan a sostener que hasta ahora no había en las empresas una única persona responsable de cada producto y que el Product Owner viene a suplir esa carencia (y si queréis saber cómo, no tenéis más que leer su libro o cursar uno de sus seminarios ;- ). Pero como ya sabemos, la realidad es que en cualquier empresa de producto razonablemente gestionada ya existe esa figura de “CEO del producto” y que atiende al nombre de Product Manager.

Por eso hace unos años se suscitó la polémica de si las empresas de producto comercial necesitaban únicamente Product Managers o Product Owners (o los dos) y si ambas funciones podían ser desempeñadas por la misma persona, aspectos estos que iremos cubriendo en próximas entradas.

El post “Agile y el papel del Product Owner en empresas de producto” 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.]

11 comentarios

Haz que tu producto sea comprable

por en 14 septiembre 2013

No basta con hacer productos más usables, hay que hacerlos más comprables. Y eso exige enfocarnos en el comprador y hacer un esfuerzo de conceptualización y diseño de producto guiado por sus necesidades y objetivos.

Decíamos en un post anterior que en productos de compra compleja compradores y usuarios no son las mismas personas y si a la hora de diseñar el producto nos enfocamos exclusivamente en la funcionalidad de los usuarios podemos dejar de lado los objetivos del comprador y no proporcionarle una razón suficientemente poderosa como para abrir la chequera.

Por eso en productos de compra compleja debemos enfocarnos explícitamente en el comprador, hacer las cosas desde su punto de vista y ponérselo fácil. Porque la “comprabilidad” no surge por azar: es fruto entre otras cosas de una concepción y diseño explícito del producto.

Como crear un producto “comprable por diseño”

Para asegurar que el producto resulta comprable son necesarios una conceptualización global y un diseño deliberado que tenga en cuenta al comprador. El diseño centrado en el usuario es importante, pero es necesario un diseño centrado además en otra persona: el comprador.

Objetivos Comprador Experiencia Usuario Características Producto

Y para hacer productos más comprables debemos proporcionar al comprador una propuesta de valor atractiva y ofrecerle (en lo que toca al producto) una excelente experiencia de compra. Pero antes tenemos que empezar por entenderlo.

Entiende a tus compradores

Captura customer insights para entender sus necesidades, objetivos y motivaciones (tanto racionales como emocionales). Modela cada tipo de comprador mediante una representación arquetípica (persona de comprador) fundamentada en evidencias de mercado, no en especulaciones de despacho. Incorpora su contexto de negocio, los resultados que quiere obtener, su previsible “viaje de comprador” y sus escenarios de compra, todo ello ligado en una historia (no sólo como datos desconectados). Dedica especial atención a la persona del “dueño del problema” pero no olvides que cada comprador es diferente y tiene su propia percepción del valor de tu producto.

Construye propuestas de valor que den a cada uno razones para comprar

En realidad un producto no tiene una única propuesta de valor sino varias, específicas de cada persona de comprador, y en general constan de dos componentes principales (definidos en relación a las alternativas disponibles en el mercado):

  • Los beneficios y resultados de toda índole que el producto aporta al comprador, diferenciados respecto a otros productos y sustentados en razones para creer.
  • A eso hay que restarle unos costes totales de adquisición y uso del producto: inversión, costes de explotación… incluyendo los riesgos que pueden impedir que el comprador obtenga los beneficios buscados. Para contrarrestar esos riesgos es aconsejable, por ejemplo, que el producto sea sencillo de usar y compatible con los usos, procesos e infraestructuras existentes.

Un diseño holístico, que parta de los objetivos de negocio, es imprescindible para definir quiénes deben usar el producto, en qué escenarios, para realizar qué tareas y qué experiencias de uso debe proporcionarles, de modo que -implementadas y orquestadas adecuadamente- en conjunto entreguen los resultados que espera el comprador.

No podemos perder de vista que las funcionalidades y experiencias de usuario deben ser el vehículo para alcanzar los resultados que busca el comprador: para ello, hay que empezar con los objetivos del comprador y seguir con las experiencias del usuario, para llegar finalmente a las features & functions del producto.

La razón para comprar no emerge de una serie de historias de usuario inconexas. Si no tenemos los objetivos del comprador como guía podríamos terminar proporcionando experiencias excelentes a usuarios innecesarios, olvidándonos de usuarios clave, o no integrando esas experiencias bajo un propósito común.

De hecho, este enfoque debe aplicarse más allá del producto “desnudo”: en el High-Tech Marketing clásico siempre se ha hablado de la necesidad de no quedarse ahí y de proporcionar al cliente soluciones o productos “completos” (que incorporan productos complementarios y servicios auxiliares para suministrar una experiencia óptima) y que satisfagan su razón para comprar.

Optimiza sus experiencias de compra

La experiencia de compra no se limita a algo que la gente de Marketing y Ventas construye a posteriori y de manera independiente del producto: aunque tiene muchos elementos off-product (mensajes, canales de marketing, contenidos, relaciones personales…) me quiero referir ahora a los componentes on-product de la experiencia de compra.

En el producto hay muchos atributos que pueden influir para que la experiencia del comprador sea favorable a nuestra opción. Para ello, por ejemplo, el producto debe ser fácil de probar antes de comprar, la adopción del producto debe ser visible y los resultados de su uso deben ser observables, los beneficios del producto deben ser fácilmente comprensibles y comunicables…

Otras características del producto deseables en relación a la experiencia de compra se han puesto de manifiesto más recientemente, como consecuencia de unas nuevas tecnologías que hacen que nuestros mercados y clientes estén cada vez más conectados. Por ejemplo, es muy valioso incorporar al producto elementos de viralidad (Hotmail es el caso clásico) y efectos de red.

Una técnica que puede ser útil a la hora de diseñar experiencias de compra e incorporar atributos de comprabilidad al producto son las “historias de comprador” (análogas a las historias de usuario que se emplean en la especificación funcional de productos).

Alguien podría pensar que estas características no son propiamente features & functions del producto porque no son las que se aplican a resolver el problema del cliente (y éste no estaría dispuesto a pagar por ellas). Sin embargo, sí lo son desde una perspectiva de comprabilidad del producto y –si queremos vender– más nos vale hacer todo lo posible por incorporarlas.

Al final, tanto las experiencias de compra como las de uso son parte de la experiencia global del cliente con nuestro producto.

Haciendo un producto más comprable: un ejemplo

Volviendo al ejemplo del producto software para Automatización de Fuerza de Ventas -SFA- que veíamos en el pasado post, vale la pena hacer un par de reflexiones:

  • La funcionalidad y experiencia ofrecidas por el SFA a Vendedores  y otros usuarios deben ser tales que garanticen los objetivos de eficacia y eficiencia comercial que persigue el Director Comercial (comprador). Por ejemplo, si los comerciales no tienen una manera fácil y permanentemente disponible de actualizar sus actividades, no va a haber posibilidad de supervisarlas.
  • El esfuerzo comercial (collateral, demos) dedicado a comunicar y demostrar la funcionalidad disponible para los usuarios es mucho menos eficaz que el que dedicamos a conectar el producto con los objetivos de negocio que los compradores quieren alcanzar. Las exhaustivas demos funcionales son inútiles si los compradores no perciben cómo el producto les va a proporcionar sus resultados deseados. Por no mencionar que muchos Vendedores, potenciales usuarios del SFA, son contrarios a que la empresa compre el producto por causas que nada tienen que ver con los beneficios que aporte a ésta (sino con su deseo de eludir un control más exhaustivo de sus actividades).
  • El mercado de herramientas SFA fue hace unos años el primer campo de batalla de la revolución que ha supuesto el SaaS (Software as a Service), con Salesforce.com como líder. Por supuesto que el SaaS ha significado antes que nada un cambio en el modelo de negocio del software. Pero no podemos olvidar que su éxito ha venido dado, en gran medida, por haber propuesto un producto mucho más comprable: una propuesta de valor atractiva (sencillez, modelo freemium, pago por uso), menores riesgos (posibilidad de probar antes de comprar, sin contratos a largo plazo ni inversiones iniciales), un proceso de compra más sencillo (se limita el papel del departamento de Informática), etc.

Como conclusión, además de que los productos sean útiles, usables, deseables… también deben ser comprables en el sentido de que deben concebirse y diseñarse explícitamente para proporcionar una poderosa razón para comprar y contribuir a una gran experiencia de compra.

Deleitar a los usuarios es importante, pero dar una razón para que los que tienen el dinero compren lo es más. Del mismo modo que en otros ámbitos se aplica la idea de diseñar productos para su “fabricabilidad”, debemos empezar a diseñarlos para su “comprabilidad”.

El post “Haz que tu producto sea comprable” 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.]

4 comentarios

¡Es el comprador, estúpido!

por en 7 septiembre 2013

“Enfócate en la experiencia del usuario” parece ser el nuevo mantra. Y es una gran idea… excepto cuando el usuario no es el comprador del producto. Porque si no vendemos en primer lugar, no habrá ocasión para que el usuario se beneficie de esa gran experiencia.

Últimamente hablamos mucho de que nuestros productos tienen que ser usables y deseables…Personalmente soy un convencido y no dejo de encomiar la importancia del diseño de experiencias de usuario. Pero eso significa que a veces nos centramos en el usuario y nos olvidamos del comprador. En este post vamos a hacer un pequeño alegato sobre la importancia del comprador y a favor de que los productos sean, además, comprables.

En muchos productos, comprador y usuario son la misma persona, de modo que centrarse en los problemas y objetivos del usuario, su escenario y sus tareas, y proporcionarle una gran experiencia de uso es la clave para la decisión de compra. Por eso en mercados B2C son tan importantes aspectos como la deseabilidad y la usabilidad del producto.

Por el contrario, en mercados tecnológicos o para el cliente empresarial muchos productos son de compra compleja: diversas personas participan en el proceso de compra, en diversos roles y con diferentes niveles de involucración e influencia. Y esas personas que participan en el proceso de compra no son en general los mismos que van a terminar usando el producto (aunque en algunos casos esos compradores sean también usuarios). Si recordáis la famosa frase “la gente no quiere un taladro de un centímetro, quiere agujeros de un centímetro”, esta diferencia es más importante aún en productos de compra compleja porque la persona que necesita el agujero y la que va a usar el taladro no son la misma.

Si aspiramos a tener éxito en un mercado B2B es importante identificar un problema de negocio grave, a ser posible con un “dueño” claro, y enfocar ahí nuestro producto. Ese dueño del problema siempre va a tener un rol clave en el proceso de compra, sea como decisor final, como evaluador de negocio, etc. Y aunque en muchas categorías de producto sea típico incorporar a los usuarios finales en la compra, habitualmente se trata de un rol de validación o de una involucración “de oficio”. Quienes deciden (y firman los cheques) son los responsables de negocio que tienen un problema por resolver, y una vez tomada la decisión a un nivel ejecutivo o gerencial a los usuarios no les queda sino acatarla y empezar a usar el producto.

Importante: por supuesto que en un proceso de compra compleja puede haber otros implicados (influenciadores, prescriptores, inversores…) pero en aras de la claridad vamos a restringirnos a los dos grandes grupos mencionados.

Compradores y usuarios: un ejemplo

Por ejemplo, consideremos el caso de un producto de Automatización de Fuerza de Ventas (SFA), un tipo de software corporativo que suele formar parte de las soluciones CRM y que muchos de vosotros conoceréis como usuarios y compradores (si es que no también como vendedores, como es mi caso).

Usuarios y Compradores

La iniciativa para proveerse de un sistema corporativo de SFA suele partir del Director Comercial (o del CEO) de la empresa y tiene por objetivo conseguir una mayor eficacia y control en el equipo comercial con el fin de vender más y mejor. En el proceso de compra suele haber además otros participantes, como por ejemplo el Director de Sistemas (en un papel de validador técnico principalmente) o algún Gerente/Jefe de Equipo de Ventas (como evaluador de negocio). De todos ellos, probablemente sólo este último perfil sería un usuario intensivo del producto y lo utilizaría para una gestión más proactiva de su equipo y su negocio y para elaborar informes periódicos y previsiones de venta.

En cuanto a los usuarios, los principales serían los propios Vendedores y el personal de apoyo administrativo a Ventas. Los vendedores utilizarán el producto para registrar sus contactos y oportunidades, programar y coordinar sus actividades, reflejar el progreso, estimar volumen, plazo y probabilidad de las operaciones, etc. Posiblemente durante la fase de evaluación de productos se involucrará a algunos vendedores para validar la funcionalidad y usabilidad del producto. En este ejemplo se da la circunstancia de que el grupo mayoritario de usuarios (vendedores) en general es reacio a la adopción de productos SFA en la empresa, por la amenaza implícita que para ellos supone una mayor visibilidad de sus actividades y una rendición de cuentas más detallada.

Si un fabricante de SFA proporciona una experiencia de uso extraordinaria a vendedores y gerentes pero no es capaz de convertir todo eso en una mayor eficacia y eficiencia en la actividad comercial, un reporting más fácil y unas previsiones de venta más fiables para los ejecutivos de la empresa cliente, es difícil que tenga éxito en el mercado. Y eso es porque los que tienen la decisión y el dinero no van a ver claro qué resultados les permitiría alcanzar el producto.

Por supuesto que la división compradores/usuarios depende del tipo de producto (y del cliente particular) e identificar el proceso particular de compra en cada caso es trabajo del equipo comercial. Por ejemplo, en la compra de otro tipo de producto (digamos, una herramienta de desarrollo de software) el Director de Sistemas podría desempeñar un papel de decisor principal o evaluador de negocio.

¿Satisfacer a compradores o a usuarios?

Entonces ¿debemos anteponer la satisfacción de los compradores a la de los usuarios? En realidad ésta es una falsa dicotomía porque ambas están conectadas.

Por supuesto que resolver las necesidades y realizar las tareas de los usuarios es vital en sí mismo, pero además porque -si el producto está bien diseñado- en conjunto todo eso contribuirá también a alcanzar los objetivos de los responsables de negocio. En cierto modo, la funcionalidad y la experiencia del usuario es un fin en sí mismo y también un medio para que los compradores de negocio alcancen sus objetivos. Y esto último es el principal argumento de venta.

Tenemos que diseñar productos que conjuguen las tareas a realizar y la experiencia a proporcionar a los usuarios con los objetivos a alcanzar y los resultados a conseguir por los compradores, y que utilicen las primeras como un vehículo para alcanzar los segundos.

Durante el proceso de compra tenemos que ayudar a los compradores a entender cómo el producto va a crear esa conexión entre experiencias de uso y resultados de negocio. Porque, seamos claros: por definición, si los que tienen el poder y el dinero en la empresa cliente no están convencidos no nos van a comprar.

Eso implica que no podemos dejar la creación de una experiencia de compra excelente como responsabilidad únicamente de la función de marketing y ventas, como si esta experiencia fuera algo que se puede añadir a posteriori, con independencia del producto. Aunque la experiencia de compra tiene muchos componentes off-product, también son muchos sus elementos on-product, como veremos en el próximo post.

Eso en lo que se refiere al proceso antes de la compra. Con posterioridad a él, es evidente que una buena experiencia de usuario -que optimice la realización de sus tareas y la consecución de los objetivos de negocio- es vital también para la satisfacción a largo plazo del cliente (y las consiguientes renovaciones, ampliaciones y ventas adicionales del producto).

En el próximo post hablaremos de cómo diseñar productos que sean comprables, lo que implica proporcionar a los compradores tanto una buena razón para comprar como una excelente experiencia de compra.

Hasta entonces, trata de hacer este pequeño ejercicio: piensa en un producto que conozcas (si es uno que estás intentando vender, mejor) y piensa en quiénes son sus compradores y sus usuarios principales y en el protagonismo de cada uno antes y después de la compra.

El post “¡Es el comprador, estúpido!” 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.]

2 comentarios

Textalytics: descubriendo el mercado para las tecnologías semánticas

por en 28 julio 2013

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

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

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

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

Textalytics - Meaning as a Service

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

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

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

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

Deja un comentario

Community manager: olvídate de leer todos esos tweets/posts irrelevantes

por en 13 abril 2013

El primer paso de una estrategia en medios sociales es «escuchar» lo que dicen nuestros clientes sobre nuestra empresa, sus marcas/productos, sus competidores… en redes sociales, blogs, foros, etc. Si eres un community manager que no dispone de un amplio presupuesto para herramientas avanzadas de monitorización probablemente te pases unas cuantas horas al día con la vista puesta en las pantallas de Twitter, Facebook, HootSuite, TweetDeck… leyendo tweets/posts irrelevantes, a la espera de algo que merezca atención. Ahora la tecnología semántica te puede facilitar la vida. 

En Daedalus acabamos de publicar una nueva­­­­ versión de Sentimentalytics, un plug-in para navegador que analiza “al vuelo” y etiqueta semánticamente los timelines que aparecen en redes y herramientas sociales. En este post podéis leer sobre los orígenes del proyecto.

Nuestra idea con Sentimentalytics es liberar a community managers y agencias de la necesidad de leer miles de posts irrelevantes y permitirles concentrarse en aquellas conversaciones que merecen una atención especial en virtud de su significado.

Con solo hacer clic sobre el botón de Sentimentalytics, estas páginas, timelines, resultados de consultas, etc. aparecen anotados dinámicamente con etiquetas que indican las entidades que se mencionan, el idioma y el tema del documento, así como el sentimiento tanto general como asociado a cada entidad.

Screenshot Sentimentalytics

Sentimentalytics funciona integrado en las interfaces de las redes y herramientas sociales más habituales (Twitter, Facebook, Google+, TweetDeck, HootSuite y otras) y analiza textos en español, inglés y francés. De este modo, el plug-in facilita una “gestión por excepción” y en tiempo real de los medios sociales. El uso de la versión estándar de Sentimentalytics es completamente gratuito, tenéis más información en el blog de Daedalus y en esta presentación.

Me gustaría aprovechar la ocasión para agradecer a los amigos (community managers y usuarios avanzados) que con sus sugerencias han contribuido al desarrollo de la herramienta durante la anterior fase de beta privada.

No olvidéis registraros gratis en Sentimentalytics.com. ¡Que os sea útil!

El post «Community manager: olvídate de leer todos esos tweets/posts irrelevantes» se publicó primero en «Marketing&Innovación».

Deja un comentario

No priorices atributos de tu producto: prioriza soluciones para el cliente

por en 27 enero 2013

Priorizar los atributos del un producto implica un enfoque “de dentro afuera” y resulta una actividad difícil, cara y de resultados discutibles. Pero los clientes compran un producto en tanto que aporta soluciones a sus problemas. Priorizar soluciones nos ayuda a tener en cuenta el valor para el cliente, las ofertas alternativas y los factores internos a la empresa.

La priorización de los desarrollos es un aspecto importante tanto en la creación de un nuevo producto como en la evolución de uno ya existente.

En algún momento -probablemente como consecuencia de unas actividades de definición y diseño del producto, al menos en sus líneas generales- llegamos a generar una lista de “cosas” que el producto debería incluir. (Por ejemplo, en entornos Agile, esta lista se denomina backlog.)

Pero, debido a múltiples razones, habitualmente es imposible (e incluso no recomendable)  implementar todas esos elementos. Resulta entonces inevitable el priorizarlos, para identificar cuáles  van a incluirse en la inmediata implementación del producto y cuáles tendrán que esperar a futuras versiones.

Full featured knife

Especialmente en empresas de base tecnológica, a la hora de implementar un producto solemos aplicar primordialmente un “pensamiento de ingeniería”. Cuando consideramos un producto, los ingenieros tendemos a ver arquitecturas, componentes, atributos… y nos enfocamos en “qué es” y en “cómo funciona” dicho producto (en lugar de en «qué hace» o  “para qué sirve”). Solemos caer así en una visión “de dentro afuera”, que nos lleva a convertir el problema de la priorización en uno exclusivamente de clasificación de atributos, características o features.

Pero en el fondo, el modo en que un producto resuelve un problema (“qué es”, “cómo funciona”, sus prestaciones…) no tiene un valor directo. Sí que tienen un valor indirecto, en cuanto que se trata de medios para resolver un fin: satisfacer la necesidad o el problema del CLIENTE.  Porque como hemos dicho aquí en más de una ocasión, el valor de un producto lo define el cliente, no nosotros.

Sin embargo, volviendo a la priorización por features, hay algunas opiniones extremas que abogan por asignar la prioridad en función del ROI de cada atributo o alguna medida similar de coste/beneficio (NPV, IIR, payback). Pero priorizar features por ROI o similar es una mala idea.

Y es que si ni siquiera somos capaces de estimar de modo fiable el ROI de un producto mínimamente nuevo, mucho menos lo vamos a conseguir cuando se trata de un atributo individual. ¿Qué ingresos incrementales nos puede aportar el hecho de solucionar al cliente una parte de un problema? ¿Y qué ocurre cuando existen dependencias entre atributos y se necesita uno para que el otro funcione?

En el mundo real la priorización de features en función del ROI acaba siendo un costoso ejercicio de “cocinado” de cifras, autoengaño y asignación arbitraria de prioridades. Una práctica difícil y cara que, además, no suele estar sujeta a los análisis retrospectivos de otros procesos. De este modo no se hace ningún énfasis en mejorarla y se perpetúa su mal funcionamiento. Podríamos decir que la priorización de atributos por ROI combina un objetivo equivocado con unos criterios y medios erróneos.

Pero como dice un amigo mío “la gente no tiene medios problemas, tiene problemas enteros”. Y por eso en lugar de priorizar atributos hay que priorizar soluciones, principalmente porque los clientes no compran features, compran soluciones a sus problemas.

A los efectos de este post (y sin adentrarnos en muchas profundidades) vamos a convenir que una solución es una especificación de la funcionalidad y la experiencia de usuario que se necesita para resolver un problema del cliente (NO es una implementación). Una solución se compone, entre otras cosas, de atributos/características/features que contribuyen a proporcionar esa funcionalidad y experiencia.

¿Y qué factores deberíamos tener en cuenta cuando se trata de priorizar soluciones?  Sin ánimo de ser exhaustivos aquí hay algunas pistas:

  • Valor para los clientes. ¿Cuál es el problema/necesidad de mercado que resuelve la solución? ¿Cuál es la importancia, urgencia y prevalencia de ese problema para los clientes? ¿Cómo resuelven actualmente el problema?
  • Beneficios para nuestra empresa. ¿De qué manera nos puede ayudar la solución a conseguir ingresos: ganar nuevos mercados, incrementar precios en mercados existentes…? ¿Cuál puede ser el volumen y evolución de las ventas?
  • Encaje estratégico con nuestra visión y roadmap de producto y con nuestros objetivos como empresa. ¿El desarrollo nos acerca al producto que queremos tener y a los mercados donde queremos estar en 1-2 años? ¿Cuáles son nuestros objetivos: entrar en nuevos segmentos, prevenir la erosión de nuestra base de clientes…?
  • Compromisos con clientes específicos, tanto actuales como potenciales. ¿Se trata de un desarrollo especial que nos ha solicitado nuestro principal cliente? ¿Una solución a medida que nuestros comerciales exigen para poder ganar una cuenta clave?
  • Costes (y riesgos) de la implementación. ¿Cuánto esfuerzo, recursos, tiempo… son necesarios para la construcción (y el eventual lanzamiento) de la solución? ¿Qué probabilidades hay de que no pueda desarrollarse y cuáles serían las consecuencias?
  • Y muchos otros: obligaciones legales que el producto debe cumplir, dependencias entre funcionalidades…

Cuando desarrollamos un producto es mejor proporcionar a nuestros clientes “el 100% de algo que el 70% de todo”. La priorización de soluciones nos permite conjugar de una manera natural el valor para los clientes con nuestra visión estratégica y los criterios de competitividad y factibilidad, y nos ayuda a mantenernos enfocados en el mercado. Pero, sobre todo, nos ayuda a no proporcionar productos que sean un amasijo de atributos inconexos.

¿Qué opináis? ¿Cómo priorizáis vuestros desarrollos de nuevos productos?

Este post en “Marketing & Innovación”.

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

4 comentarios

El descubrimiento y validación de tu producto es un proceso continuo

por en 20 enero 2013

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

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

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

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

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

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

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

Descubrir y Validar Producto

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

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

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

Descubre un producto que valga la pena construir

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

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

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

Valida un producto que valga la pena escalar

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

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

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

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

Prácticas y herramientas

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

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

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

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

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

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

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

Este post en «Marketing & Innovación».

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

4 comentarios