Crecimiento de productos tecnológicos

Entradas de Antonio Matarranz

Las metodologías de «desarrollo ágil» hacen muchas cosas mejor, pero también pueden llegar a hacer otras cosas (algunas muy importantes) peor. En este post pasamos revista a las bajas colaterales que puede provocar en entornos de desarrollo de productos una agilización mal entendida.

En la primera parte de este post hablábamos de que las que se suelen vender como metodologías de “desarrollo ágil” tienen grandes ventajas pero no se pueden considerar una solución completa para el desarrollo de nuevos productos para un mercado (algo muy diferente al desarrollo a medida para un cliente específico).

En esta segunda parte abundamos en la opinión -que puede resultar herética para algunos- de que Agile no es la nueva panacea universal y que, si bien hace muchas cosas mejor (fiabilidad, velocidad, calidad…), implementado “según el manual” puede llegar a hacer otras cosas (algunas muy importantes) peor. Aquí tenéis algunas de las bajas colaterales provocadas por una agilización mal entendida:

Beatings Will Continue

  • Análisis de la oportunidad de mercado y conocimiento profundo de los clientes. El feedback de los clientes durante la implementación es muy valioso, pero no puede sustituir a un conocimiento del mercado y a unos customer insights previos -y continuos- que nos van a permitir detectar y definir oportunidades rompedoras. Por ejemplo, el Product Owner típico de Scrum debe estar continuamente disponible para el equipo de implementación y por ello puede no disponer del suficiente tiempo de contacto con los clientes o de análisis de los competidores como para entender el mercado. Frecuentemente el resultado es un producto que satisface literalmente las solicitudes de mejora expresadas por uno o dos clientes particulares (los últimos que hablaron con el Product Owner), pero lamentablemente el cliente voluntarioso/colaborador no representa al cliente típico.
  • Estrategia de producto, visión a largo plazo y roadmap. Un excesivo énfasis en ciclos de desarrollo cortos y en la priorización continua de las features puede hacernos perder de vista dónde querríamos estar a medio y largo plazo -en términos de mercados y oferta- y qué camino debemos seguir para llegar allí. Por no hablar de cierta afición a priorizar features por ROI (desde mi punto de vista, algo en general ilusorio y contraproducente). Agile no debe ser una excusa para carecer de estrategia de producto y para cambiar constantemente de visión y vagar sin rumbo fijo.
  • Feedback temprano y frecuente. Agile promueve el feedback de los clientes durante todas las iteraciones de la implementación. Sin embargo, confiar la validación inicial de la solución a esas primeras iteraciones es un error ya que para entonces puede ser demasiado tarde. Este feedback se debería haber recogido durante las fases previas a la implementación -definición y diseño-  y no mediante un producto real (aunque incompleto) sino utilizando prototipos rápidos y desechables. Los prototipos pre-implementación son los únicos que nos permiten recoger la opinión de los clientes con la rapidez, velocidad de iteración, fidelidad y bajo coste necesarios para asegurarnos de que no empezamos a construir algo que el mercado no quiere.
  • Diseño de la solución (especialmente en lo relacionado con la experiencia de usuario). Una experiencia integrada y consistente no “emerge a trozos” de una construcción incremental sino que debe ser fruto de una concepción holística y -al menos en sus grandes líneas- de un diseño deliberado previo. Este diseño integral (siempre iterativo) es el que realmente permite descubrir modelos innovadores de interacción con el usuario, que elevan el nivel de la experiencia de uso. Por su parte, el refinamiento iterativo durante la implementación puede optimizar interfaces e interacciones, pero se trata a menudo de una mejora incremental. Las metodologías ágiles se están extendiendo para conjugar un diseño holístico con una implementación incremental, hasta el punto de que el “Agile UX” es uno de los temas de actividad en la comunidad (al que dedicaremos un próximo post).
  • Arquitectura. Un excesivo foco en las features puede llevar a postergar a un segundo plano la especificación técnica. Y, sin embargo, la arquitectura es primordial para garantizar que durante la construcción vamos a poder iterarlo y “pivotarlo” fácilmente y que el producto final va a ser replicable, fiable, escalable, evolucionable y adaptable a varios segmentos de clientes (a través de “productos derivados”). La arquitectura es otro de los aspectos del producto que requieren un enfoque holístico y en implementaciones desafortunadas de Agile puede acarrear una gran «deuda técnica».
  • Puestos con funciones claras y no redundantes. Las metodologías Agile van evolucionando y extendiéndose más allá de la implementación, entrando en los terrenos de la estrategia, la visión y la definición del producto. Sin embargo, en las empresas ya existen puestos que tienen la responsabilidad sobre esos temas (llámense estos Chief Product Officer, Product Manager, Business Analyst o Technical Product Manager) lo que puede crear conflicto con alguno de los puestos o roles propios de Agile, especialmente el del Product Owner. Incluso ha habido intentos de describir un “Agile Product Manager” como una especie de Súper-Product Owner aunque en mi opinión las responsabilidades y actividades que le asignan son incompletas y las técnicas que les recomiendan son demasiado rudimentarias. También hablaremos de ello en otro post.

Con todo esto no quiero decir que cualquier implementación del desarrollo ágil vaya necesariamente a acarrear estos problemas, sino identificar áreas de posible disfuncionalidad donde hay que poner un especial cuidado.

La decisión de aplicar o no Agile no puede tomarse por modas, sino que depende del tipo de producto, mercado, tecnología y organización. Si los riesgos de cliente/mercado/tecnológicos son bajos, los costes de iteración son altos, y  el equipo de implantación muestra buen rendimiento, coordinación y comunicación puede no ser necesario migrar a Agile ya que los costes incrementales del cambio pueden ser superiores a los beneficios. La realidad en las empresas más avanzadas es que controlan un repertorio de metodologías de implantación, desde el ágil más radical a la cascada más ortodoxa, pasando por enfoques mixtos “Agile Waterfall”, y aplican una u otra según lo que más convenga en cada escenario.

Este post 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.]

3 comentarios

La Federación Española de Centros Tecnológicos (Fedit) me ha invitado a impartir un nuevo taller. En esta ocasión hablaremos sobre el desarrollo y gestión de productos/servicios basados en nuevas tecnologías y tendrá lugar en su sede de Madrid el próximo 22 de noviembre.

Intentaremos sentar las bases de una función de Product Management “de fuera adentro” (del mercado a la empresa) y no al revés, que sirva para definir y diseñar ofertas que el mercado necesita y sean fáciles de vender.

Resumen de contenidos:

  • Valor para el Cliente. Modelos para conceptualizar y medir el valor
  • Cómo descubrir y evaluar oportunidades de mercado basadas en la tecnología
  • Cómo entender lo que necesitan los clientes
  • Cómo diseñar y validar modelos de negocio basados en la tecnología
  • Cómo elaborar propuestas de valor ganadoras
  • Cómo definir y diseñar productos/servicios tecnológicos
  • Cómo posicionar la oferta en el mercado
  • Gestión estratégica de la oferta: el papel del Product Manager
  • Para qué sirven (de verdad) Business Model Canvas, Customer Development, Minimum Viable Product, User/Buyer Personas, Design Thinking, Agile Development y otras prácticas de moda… a menudo no bien entendidas ni aplicadas.

El título es «Creación y gestión de ofertas de productos y servicios tecnológicos» y en está página tenéis más información sobre contenidos a inscripción. Está abierto a todo el mundo (con un precio especial a sus Centros asociados) y quedan unas pocas plazas.

Gracias a Marta Muñoz (@MartaMunozFerna) y a su equipo por contar nuevamente conmigo y a vosotros, si estáis por Madrid ese día, os animo a que os inscribáis y a que nos conozcamos personalmente.

Este post en “Marketing & Innovación”.

1 comentario

Las metodologías ágiles se vienen presentando como la solución a los problemas del desarrollo de productos. Pero aunque sin duda pueden aportar mejoras en las actividades de construcción y conseguir que las características del producto se implementen adecuadamente, por sí solas no son suficiente para asegurar que esas características son las adecuadas para conquistar el mercado.

La filosofía y las metodologías ágiles se están proponiendo como solución a los retos del desarrollo de productos en escenarios de alta incertidumbre y velocidad. Por ejemplo, Steve Blank y Eric Ries incorporan el Agile Development como una de los pilares de su Startup Stack, junto a Customer Development y Business Model Canvas. En este blog hemos hablado de desarrollo ágil en varias ocasiones y tal vez vale la pena recordar algunas ideas:

Proceso Scrum

Pero las diferencias entre ambos escenarios son enormes: desarrollar un producto que satisfaga a un mercado va mucho más allá del desarrollo de un proyecto a la medida de un cliente específico. La gestión y desarrollo de productos consiste fundamentalmente en entregar productos repetibles a un mercado de clientes y ello requiere inicialmente de una identificación de las necesidades de dicho mercado, una validación de la oportunidad que representa y una comprensión profunda de los requisitos esenciales de los clientes. Las metodologías de “desarrollo ágil” cubren las actividades de implementación o construcción de la “unidad 0” de un nuevo producto y por tanto entran en acción cuando ya se ha decidió que se va a construir algo, pero no fueron pensadas para evaluar una oportunidad de mercado o para definir el tipo de solución a proporcionar. No podemos confundir una parte (la construcción del producto) con todo el proceso de desarrollo y mucho menos con la gestión estratégica de productos.

Build the features right vs. build the right features

Personalmente soy un convencido de los beneficios de las filosofías flexibles/ágiles de desarrollo de nuevos productos, especialmente en escenarios de alta incertidumbre. Y sin duda la flexibilidad y la iteración centrada en el usuario que aportan las metodologías Agile benefician enormemente al proceso de desarrollo. Pero una aplicación “de manual” de algunas metodologías a escenarios para los que no fueron creadas puede traer efectos secundarios indeseables.

Por su enfoque principalmente táctico y orientado al proyecto, Agile puede aportar grandes mejoras en el propio proyecto (o proyectos) de construcción de un nuevo producto: programación predecible de releases, menos features incompletas, mayor usabilidad… pero puede relegar la visión más estratégica del producto a un segundo plano. Agile puede acelerar el desarrollo y mejorar la calidad de las features individuales, pero lo hace a menudo a expensas de otros trabajos más importantes y costosos que aportan un valor para el cliente y una diferenciación competitiva reales, p.ej., una comprensión profunda y una priorización de los problemas a resolver o un diseño holístico (al menos en sus líneas generales) de la funcionalidad y la experiencia de usuario.

Desde luego que una  implementación ágil puede mejorar muchos aspectos del producto, pero esas mejoras son a menudo incrementales. Esencialmente, Agile asegura que se va a poder “entregar algo aceptable rápidamente”, pero ¿ese “algo” nos va a servir para vender más en un mercado? Mi opinión es que las metodologías ágiles por sí solas son insuficientes para asegurar que se construyen las features adecuadas para satisfacer a unos clientes heterogéneos y desconocidos.

Cuando Agile se implanta “a ciegas” su cadencia y sus prácticas llegan a apropiarse del proceso de desarrollo de producto y la vorágine de la implementación absorbe a toda la organización. Resulta difícil pensar estratégicamente cuando se está sometido a las demandas constantes del corto plazo. La urgencia por “alimentar a la bestia” de los procesos de Agile nos puede impedir prestar atención a algunas otras cosas realmente importantes. Para evitarlo, estas metodologías han tenido que ir adaptándose y extendiéndose de modo que fueran más adecuadas a un escenario de desarrollo de productos y no de proyectos a medida.

En la segunda parte de este post pasaremos revista a algunas “bajas colaterales” de un agilismo mal entendido. Mientras tanto ¿cuál ha sido vuestra experiencia en el desarrollo de productos aplicando metodologías ágiles?

Este post 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.]

12 comentarios

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

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

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

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

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

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

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

Antes de la entrevista

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

Durante la entrevista

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

Después de la entrevista

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

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

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

Este post en “Marketing & Innovación”.

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

5 comentarios

Una entrada muy breve para agradecer la medalla de plata en los recientes Premios Blogosfera de Marketing 2012 que ha recibido este blog. Muchas gracias a todos los que lo han hecho posible. Sin duda, una de las mejores cosas del premio es pasar a estar en la compañía de los otros premiados en esta y anteriores ediciones, verdaderas referencias en la profesión.

Medalla Plata Blogosfera Marketing 2012

También quería anunciar que -como parte de las actividades asociadas a estos premios- durante el próximo Congreso Nacional de Marketing y Ventas que tendrá lugar el día 24 de octubre en Madrid participaré en una mesa redonda con el resto de galardonados. Será una buena oportunidad para “desvirtualizar” y charlar personalmente con los que podáis asistir.

De nuevo muchas gracias.

Deja un comentario

La función de Diseño de Producto sirve de engranaje entre las de Definición e Implementación. Pero la clave para un buen funcionamiento está en cómo organizar y coordinar las actividades y en un enfoque iterativo y dinámico que involucre al cliente/usuario desde el primer momento.

En la primera parte de este post comenzamos a hablar de cómo resulta imprescindible crear una función de Diseño de Producto que se encargue de conceptualizar la solución a los problemas de mercado y de especificar el producto desde el punto de vista funcional y de experiencia de usuario. Esa función de Diseño debería servir de engranaje entre los roles de Definición e Implementación a lo largo de las actividades de desarrollo del producto:

  1. Identificar problemas de mercado y evaluar oportunidades
  2. Definir requisitos y validar soluciones
  3. Diseñar la solución y elaborar la especificación
  4. Implementar y probar la solución

En esa primera entrega cubrimos las actividades iniciales; ahora pasamos revista a las dos últimas.

Lineal Iterativo

Diseñar la solución y elaborar la especificación

Desde los primeros momentos del proceso, Diseño colabora con Gestión de Producto en el análisis del mercado y los competidores y realiza estudios de clientes (entrevistas, encuestas, observaciones contextuales) para entender los problemas de negocio y definir enfoques para la interacción del usuario. A continuación, Diseño conceptualiza una solución a los problemas identificados en los requisitos que conjugue la respuesta a dichos problemas/necesidades con una experiencia de usuario satisfactoria. Diseño elabora storyboards, diagramas de flujo, wireframes, prototipos y otros artefactos que se van iterando y validando con los clientes para asegurar que la solución es aceptable desde los puntos de vista funcional y experiencial.

Como beneficio añadido de este proceso, el conocimiento generado durante el análisis y el diseño puede provocar refinamientos y revisiones de los requisitos iniciales. El equipo de Implementación también puede intervenir en esta actividad, proponiendo soluciones y verificando que las propuestas que aparecen serán técnicamente realizables. El objetivo es llegar a una solución útil, usable, deseable, factible y viable.

Diseño de Producto elabora las especificaciones a partir de las cuales el equipo de Implementación construirá la solución real. Se trata de especificaciones funcionales y de experiencia de usuario, no de especificaciones técnicas. La especificación elaborada por Diseño describe cómo funciona el producto desde la perspectiva de comprador y usuario. No entra en cómo se implementan las cosas sino que describe el propósito del producto, su funcionalidad, features, prestaciones, interfaces e interacciones.

Esta especificación puede tomar diversas formas: desde el tradicional Documento de Especificaciones de Producto hasta un prototipo “de alta fidelidad” anotado con historias de uso. Lo importante, sin embargo, no es tanto el formato como su aplicación como artefacto de comunicación y coordinación.

Implementar y probar la solución

El equipo de Implementación construye la solución a partir de los requisitos y las especificaciones generadas durante la Definición y Diseño de producto. Con anterioridad, representantes del equipo han tenido la oportunidad de involucrarse en las actividades previas con vistas a entender de primera mano las necesidades de los clientes, sugerir orientaciones de diseño y en general asegurar la factibilidad de la solución.

Como paso fundamental de esta actividad el equipo crea una especificación técnica que describe la arquitectura y la construcción interna de la solución. El objetivo es llegar a una “unidad cero” del producto que garantice la replicabilidad/fabricabilidad, la calidad, la escalabilidad en las prestaciones, la posibilidad de evolución y la adaptabilidad (en su caso) del producto a diferentes segmentos de clientes.

La implementación del producto se suele instrumentar como uno -o varios- proyectos que se gestionan y ejecutan, dependiendo del escenario, usando métodos faseados/cascada o iterativos/ágiles.

Como parte de esta actividad la función de Aseguramiento de la Calidad realiza pruebas de producto y los errores que se detectan son corregidos.

Conclusiones

Diseño de Producto colabora con las funciones de Definición e Implementación a lo largo de todo el ciclo de desarrollo. Diseño trabaja inicialmente con Definición de Producto para analizar problemas/necesidades y diseñar y validar soluciones; después, Diseño colabora con Implementación para especificar, construir y probar la solución. De este modo Diseño de Producto desempeña el papel de puente entre esas dos funciones.

En cuanto al secuenciamiento de actividades en el desarrollo de productos, hasta hace unos años se consideraba que los enfoques lineales y faseados (como, por ejemplo, Stage-Gate) eran los más indicados para reducir riesgos y aumentar las probabilidades de éxito. Sin embargo, algunas tendencias recientes han ido desplazando el enfoque hacia una mayor iteración y solapamiento entre fases:

  • La posibilidad de construir prototipos de alta fidelidad y de realizar experimentos desde las fases iniciales del desarrollo y las metodologías ágiles de implementación permiten el feedback continuo de los usuarios y la iteración sea cual sea el mercado o la naturaleza del producto.
  • Un desarrollo de producto protagonizado por equipos multidisciplinares y transversales, que se autoorganizan, colaboran y recorren juntos las etapas del proceso “como un equipo de rugby”, en lugar de silos organizativos que se van traspasando el proceso como en una carrera de relevos.

Estos enfoques son tanto más útiles cuanto mayor sea el grado de innovación del producto y sus riegos asociados. No obstante, esta evolución crea nuevas incógnitas sobre cuál puede ser el grado de iteración y solapamiento más adecuado en cada caso (p. ej.: simultanear requisitos con diseño, o diseño con implementación), unos interrogantes de los que nos ocuparemos en futuros posts.

Este post 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.]

5 comentarios

«Marketing & Innovación»Medalla Plata Blogosfera Marketing 2012

El blog de Antonio Matarranz

Medalla de Plata en Premios «Blogosfera de Marketing» 2012

Muchos productos tecnológicos fracasan porque no obedecen a un concepto claro y carecen de un diseño deliberado. Organizar una función de Diseño que sirva de puente entre la definición y la implementación del producto ayuda a conseguir el objetivo compartido de crear productos que los clientes quieran comprar.

La realidad de muchos productos es que los product managers elaboran listas de features deseadas y el equipo de implementación construye… pero nadie diseña nada. Recordemos que -tal como hemos expuesto en otras entradas- diseño significa conceptualizar y especificar la solución al problema de los clientes, no solo el aspecto externo del producto.

¿Contratarías a un carpintero para construir una casa? Probablemente sería más sensato contratar a un arquitecto. Pues en desarrollo de productos ocurre lo mismo: alguien tiene que ser responsable de su diseño. Es imprescindible crear una función de Diseño de Producto o un rol de Diseñador de Producto que colabore con las funciones de Definición e Implementación de producto para alcanzar el objetivo último del proceso: crear productos que la gente quiera comprar. Aclaremos que no tiene que tratarse necesariamente de una persona o equipo dedicados en exclusiva a la función, sino que esta puede simultanearse con otros roles.

Vamos a intentar describir cómo articular la función de Diseño de Producto aplicando un planteamiento muy influido por dos de mis referencias en product management de productos tecnológicos: Pragmatic Marketing y Silicon Valley Product Group.

Esencialmente el enfoque consiste en que los responsables de la Definición del producto describen el problema de mercado, Diseño elabora un enfoque recomendado para resolver dicho problema, e Implementación lo aplica para construir el producto. De este modo el Diseño sirve de engranaje entre la Definición y la Implementación del producto. Las responsabilidades principales se reparten como sigue:

Definición, Diseño e Implementación de Producto

  • La función de Definición de Producto descubre y cuantifica problemas de mercado, y los articula en forma de requisitos. Este rol suele estar desempeñado por los Product Managers.
  • La función de Diseño de Producto analiza los requisitos, conceptualiza la solución y elabora una especificación funcional que describe cómo el problema puede ser resuelto con el producto.
  • La función de Implementación de Producto elabora una especificación técnica que describe cómo se implementará dicha especificación funcional, construye la solución, realiza pruebas y corrige errores.

A continuación y en la segunda parte de este post vamos a describir las principales actividades del proceso de desarrollo de nuevos productos y el detalle de cómo se implican y colaboran en ellas las funciones/roles mencionados. Estas actividades son:

  1. Identificar problemas de mercado y evaluar oportunidades
  2. Definir requisitos y validar soluciones
  3. Diseñar la solución y elaborar la especificación
  4. Implementar y probar la solución

Hay que resaltar que estas actividades no son necesariamente secuenciales y faseadas sino que en general y dependiendo del escenario constituyen un proceso con más o menos iteraciones y solapamientos.

Identificar problemas de mercado y evaluar oportunidades

Gestión de Producto (Product Management) identifica problemas y necesidades de mercado, realiza análisis y evalúa y cuantifica las oportunidades que se abren para las posibles soluciones a dichos problemas. La evaluación de la oportunidad debe dar respuesta, entre otras, a estas cuestiones:

  • Problema/necesidad a resolver
  • Perfil del consumidor/empresa que lo padece
  • Extensión, importancia y urgencia del problema
  • Tamaño del mercado y su posible evolución
  • “Ventana temporal” del mercado
  • Soluciones alternativas existentes (incluyendo “no hacer nada”)
  • Valor diferencial que podemos aportar
  • Modelo de negocio que deberíamos utilizar para entregar y capturar ese valor
  • Elementos clave de nuestra solución
  • Enfoque go-to-market
  • Estimaciones financieras básicas
  • Recomendación final: Go / No Go

Gestión de Producto debe profundizar en su comprensión de los mercados y los clientes -y sus compradores y usuarios- para construir personas: buyer (o marketing) personas y user personas. Una persona es una representación figurada de un grupo de compradores/usuarios/otros involucrados que comparten objetivos, actitudes y comportamientos. Una vez desarrolladas las personas, se crean escenarios, que son descripciones de la interacción de los compradores y usuarios con la solución.

Tanto personas como escenarios son construcciones imprescindibles para entender a los clientes de cara a diseñar la solución, así que Diseño colabora en muchos casos desde el principio investigando clientes, desarrollando insights y aportándolos para la elaboración de ambos. Personas y escenarios son útiles para que Gestión de Producto elabore los casos de negocio y para que Diseño de Producto defina la experiencia de usuario.

Definir requisitos y validar soluciones

Gestión de Producto escribe requisitos que identifican los problemas de mercado. Un requisito bien entendido es esencialmente una descripción del problema/necesidad (no una especificación de cómo resolverlo) y debe ser agnóstico respecto del diseño y la tecnología. Los requisitos que describen la necesidad/problema, junto con la evaluación de la oportunidad de mercado que representa, son los elementos principales del Documento de Requisitos de Mercado -o algún artefacto sustitutivo- que sirva para comunicar esa oportunidad y su valor a la organización.

Diseño ayuda a Gestión de Producto en esos procesos, llevando a cabo entrevistas, encuestas y observaciones y analizándolas. Los datos de esos estudios ayudan a detectar problemas y oportunidades de mercado que se plasman en requisitos.

Durante la actividad de especificación de la solución, Diseño desarrolla prototipos que Gestión de Producto utiliza para obtener feedback de los clientes y validar las posibles soluciones. La elaboración de requisitos y la validación de soluciones conforman un proceso iterativo. El nuevo conocimiento que se adquiere en la validación de la solución obliga a que se actualicen los requisitos, y las soluciones que se derivan de los requisitos actualizados requieren de validación adicional.

En la segunda parte de este post cubriremos las actividades de diseño e implementación de la solución.

Este post 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.]

13 comentarios

En muchas empresas tecnológicas el diseño (especialmente la experiencia del usuario) suele reducirse a un trabajo final de “embellecimiento” del producto, centrado puramente en sus elementos gráficos. En este post damos algunas ideas sobre cómo diseñar buenas experiencias de usuario.

Decíamos en un post anterior que muchos productos de consumo tienen un “alma” o una “personalidad” de la que carecen la mayoría de productos para el mercado empresarial y que esta alma suele provenir de su diseño.

Uno de los apóstoles del diseño, Alan Cooper, viene a decir en su clásico libro “The Inmates are Running the Asylum” que la mayoría de los productos tecnológicos no están diseñados para los usuarios, sino para los desarrolladores… o -lo que es peor- no parecen diseñados en absoluto.

El buen diseño empieza por las necesidades del nuestros usuarios. Enfoques como el Diseño Centrado en las Personas y el Diseño de Interacción se caracterizan por estar “orientados/dirigidos a objetivos”, es decir, se ocupan principalmente de satisfacer las necesidades y deseos de las personas que van a interactuar con un producto o servicio.

Para conseguirlo, los procesos de diseño suelen tomar como punto de partida los siguientes instrumentos:

  • Personas. Una persona (latín) es un personaje ficticio que representa a una clase de usuarios del producto que tienen los mismos objetivos, actividades y comportamientos. (Nota: en este caso estamos hablando de personas de usuario como representaciones arquetípicas de los participantes en un contexto de uso del producto. No confundir con las personas de comprador, que representan a los participantes en un contexto de compra del producto y que se usan en product management y marketing). Las personas se construyen después del proceso de investigación de usuarios, en el que típicamente se aplican técnicas de observación e inmersión en su contexto, entrevistas,  etc.
  • Objetivos. Lo que los usuarios desean conseguir utilizando el producto. Los usuarios tienen esencialmente dos tipos de objetivos: prácticos (qué resultados funcionales desean alcanzar) y emocionales (cómo desean sentirse).
  • Escenarios. Un escenario es una narración ficticia sobre “un día en la vida” de la persona o una secuencia de actividades que deben realizarse cuando se usa el producto.

En particular, el Diseño de Interacción (popularizado por A. Cooper) es un proceso que se enfoca en los usuarios más importantes. A diferencia de los procesos tradicionales de recogida de requisitos y diseño de la solución, el diseño de interacciones se centra en los objetivos de una clase específica de usuarios, que se representa mediante una persona prioritaria.

A partir de la combinación de objetivos y escenarios se trata de diseñar la experiencia de usuario y las especificaciones funcionales mediante un proceso iterativo de generación de ideas y artefactos de diseño (mockups, prototipos, simulaciones) y su validación con los usuarios reales. Sólo así podremos asegurarnos de que después vamos a construir un producto útil (resuelve el problema correcto), usable (los usuarios pueden utilizarlo) y deseable (los usuarios quieren usarlo).

Crear una buena experiencia de usuario (UX, User eXperience) requiere un conjunto de funciones o roles. Estos son las más esenciales:

  • Investigación de clientes. Su objetivo es proporcionar un aprendizaje rápido y continuo sobre los clientes, utilizando técnicas cualitativas y cuantitativas, y basadas tanto en lo que el cliente dice (ej.: entrevistas, encuestas) como en lo que hace (ej.: etnografía).
  • Diseño conceptual. Consiste en elaborar un concepto de producto que describa a alto nivel su naturaleza y los aspectos clave de su forma y su función. Un componente típico de la definición conceptual de un producto es si éste se ajusta a alguna metáfora o a algún paradigma de experiencia de usuario.
  • Arquitectura de información. Parte de la comprensión de los objetivos que los usuarios quieren alcanzar para definir qué funcionalidad e información debe contener el producto y cómo se estructuran y organizan éstas. La finalidad es llegar a disponer y presentar la funcionalidad e información del producto de un modo que sea fácil de entender y localizar. El layout y los componentes de navegación son elementos primordiales de la arquitectura de información, que tiene que ver, por tanto, con el contenido del producto.
  • Diseño de interacción. Su misión es entender los escenarios y actividades que el usuario desea realizar y plasmarlos en unas tareas, flujos y operaciones sobre el producto que sean satisfactorios y usables. El diseño de interacción expone y hace accesible la funcionalidad del producto. Habitualmente esta función mapea los requisitos de producto en un modelo de interacción desprovisto de detalles gráficos (p.ej.: wireframe)  que es tomado como input por la función de diseño visual. El diseño de interacción tiene que ver, por tanto, con el comportamiento del producto.
  • Diseño visual. Proporciona el look-and-feel de la interfaz: layout, colores… Muchos piensan que la misión del diseño visual es hacer el producto “bonito” o “sexy” pero es mucho más. El diseño visual comunica y evoca emociones y contribuye enormemente a la respuesta que los usuarios tienen ante nuestro producto: puede marcar la diferencia entre un producto que simplemente nos gusta y otro que nos encanta. Pero además de crear emociones para los usuarios el diseño visual aporta consistencia en la presentación y establece elementos de marca.

Además de estas funciones, y dependiendo del tipo de producto, hay otras no menos importantes (p.ej., testing). Todas estas funciones no son necesariamente secuenciales ni tienen que ser desempeñadas por personas/puestos diferentes.

Por último quería dar algunas ideas prácticas sobre cómo crear productos con buen diseño…o al menos crearlos con un diseño menos malo:

  • La funcionalidad y la experiencia de usuario están intrínsecamente entrelazadas. No es solo que “la forma sigue a la función”: podríamos decir que la forma ES función.
  • La experiencia de usuario es tan importante como la funcionalidad, pero habitualmente más difícil de conseguir. Los ingenieros que construyen el producto son (somos) habitualmente unos malos diseñadores de experiencias de usuario, ya que suelen pensar en términos de modelos de implementación mientras que los usuarios piensan utilizando modelos conceptuales.
  • Trabajar en la experiencia de usuario desde el principio: inmediatamente después de capturar y priorizar requisitos de alto nivel hay que empezar con el diseño de interfaz de usuario e interacción. No podemos caer en el típico error de añadir la experiencia al final o -peor aún- dejar que sea un subproducto de la implementación.
  • Los jefes de producto (product managers) deben trabajar en estrecha colaboración con los diseñadores de producto: la comunicación no puede reducirse al traspaso del típico Documento de Requisitos de Mercado/Producto de cien páginas.
  • Utilizar prototipos y experimentar. Presentar pronto y frecuentemente a los usuarios prototipos preliminares de diseño permite entender mejor el problema del cliente y elicitar requisitos. Posteriormente, el prototipo nos permite validar la utilidad, usabilidad  y deseabilidad del producto antes de pasar a su implementación. Finalmente, el prototipo es también la mejor manera de comunicar la experiencia de usuario y la funcionalidad a todo el equipo de producto.
  • Las metodologías ágiles (p.ej.: Scrum, XP) no tienen por qué ser enemigas del diseño, pero el diseño debe poder adaptarse a esa nueva forma de implementar los productos.
  • Lo más sencillo es mejor. Identificar el producto mínimo que cumple los objetivos y proporciona la experiencia de usuario deseada. Diseñar para el escenario del 80% de casos y no caer en la featuritis.
  • Prestar atención a los detalles. Como decía Steve Jobs el diseño consiste en “sudar todos los detalles”. No desdeñar los fallos de interfaz/interacción del producto como algo “cosmético” y no prioritario.
  • Ser valiente. Los buenos productos se diseñan diciendo “No”.

Muchas empresas siguen ancladas en unos procesos de desarrollo de productos que no ponen la experiencia de usuario en primer plano.  Antes o después sus clientes les harán saber que la vida es demasiado corta como para usar malos productos.

Este post 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.]

12 comentarios

Los productos tecnológicos para clientes empresariales son generalmente anodinos y difíciles de usar. El diseño bien entendido (no como un barniz estético a posteriori) puede aportar grandes posibilidades de diferenciación.

Toda mi carrera ha estado ligada a empresas tecnológicas y durante estos años muchas veces me he preguntado por qué los productos tecnológicos para clientes corporativos son habitualmente tan anodinos e innecesariamente difíciles de usar (cuando no francamente horribles).

Evidentemente, esta característica de los mercados B2B se puede achacar en parte a que se trata de productos complejos (y en muchos casos, inmaduros) que implementan procesos o resuelven problemas de negocio inherentemente complicados, y esa complejidad se revela en su interacción con el usuario. Pero también tiene su parte de culpa el hecho de que en productos para empresas la experiencia de usuario generalmente no se considera como algo prioritario.

Raramente es un criterio en la evaluación de productos y una vez que la decisión de compra se ha tomado a un nivel gerencial o ejecutivo, la utilización del producto simplemente es impuesta a los usuarios finales. Y si la experiencia de usuario no es una prioridad para el cliente es normal que tampoco lo sea para el proveedor.

Aunque en mercados B2C la situación no es exactamente la contraria debemos reconocer que el éxito de muchos productos de consumo (incluso los de base tecnológica) se puede atribuir en parte a que ofrecen a sus compradores/usuarios una mayor facilidad de uso y una estética superior. Y es que en productos donde usuario y comprador son la misma persona, antes de comprar el usuario no solo tiene que decidir si la funcionalidad es la correcta (utilidad) o si podría/sabría usar el producto (usabilidad), sino si querría usarlo (deseabilidad).

Radio de bolsillo Braun T3 (1958, diseño Dieter Rams)

Ciertamente en productos intrínsecamente más “sencillos” y dirigidos a un público general, donde es difícil (o poco aconsejable) distinguirse por una funcionalidad superior o más amplia, atributos como la usabilidad o la deseabilidad ofrecen grandes oportunidades de diferenciación. La consecuencia es que muchos productos de consumo parecen poseer una “personalidad” o un “alma” de la que carecen los productos corporativos. De modo que ¿cómo podemos insuflar alma a los -habitualmente áridos y complejos- productos para empresa?

Sin duda, uno de los componentes de esa alma -entendida como el significado o la esencia del producto- es su propósito o el objetivo que aspira a cumplir. Pero me atrevería a afirmar que el otro gran ingrediente de la esencia de un producto lo constituye su experiencia de uso y eso es el resultado de su diseño. El ejemplo que inmediatamente nos viene a la cabeza -en este caso en el campo de la informática de consumo- es el de Apple… aunque alguien con más memoria histórica podría sugerir los trabajos de Dieter Rams para Braun en los años sesenta.

Obviamente por “diseño” no nos referimos a esa acepción popular de “hacer que las cosas sean bonitas” o a algo que afecta únicamente a la superficie de las cosas y al aspecto que tienen. El diseño es una actividad mucho más amplia, que va del tradicional diseño industrial (estética, usabilidad, ergonomía, fabricabilidad) a las versiones más evolucionadas del diseño de productos que se aplican en los mercados de electrónica/informática y que le han dado un nuevo significado a la experiencia de usuario.

En el proceso de desarrollo de nuevos productos –y una vez que hemos detectado un problema/necesidad de mercado, validado y cuantificado la oportunidad y definido los requisitos de alto nivel– el diseño de producto crea una especificación de cómo nuestro producto debe resolver dicho problema de mercado. Y lo hace no solo desde el punto de vista de la funcionalidad a aportar, sino también de la experiencia de usuario a proporcionar. En futuros posts analizaremos las relaciones entre las funciones de gestión, diseño y construcción de productos.

El diseño no significa únicamente “deseabilidad” para mercados de consumo. El diseño especifica, expone y hace utilizable la funcionalidad del producto. Respondiendo a la pregunta que da título a este post, Steve Jobs llegó a decir en esta entrevista en Fortune que el “diseño es el alma fundamental de toda creación humana, que termina expresándose en los sucesivos niveles/capas exteriores del producto”. Según Jobs, el gran diseño surge de “sudar todos los detalles” de modo que cuando los usuarios interactúen con el producto su experiencia sea fácil y placentera. Y por “sudar” quiere decir entre otras cosas que las decisiones de diseño funcional y experiencia de usuario pueden tener un impacto enorme en la arquitectura y construcción del producto.

Resumiendo, el diseño permite no solo dar cuerpo, sino también insuflar alma a los productos para empresas y ofrece un enorme potencial de diferenciación. En otro post hablaremos del diseño de experiencias de usuario en el desarrollo de nuevos productos.

Este post 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.]

8 comentarios