Crecimiento de productos tecnológicos

Entradas de Antonio Matarranz

Construye tu máquina de generar ingresos

por en 6 abril 2013

El Revenue Performance Management es una estrategia que persigue conseguir un crecimiento predecible de los ingresos, integrando las actividades y la organización comercial alrededor de un ciclo unificado y midiendo y optimizando todo el proceso.

En un post anterior hablamos de cómo la descoordinación entre Marketing y Ventas es fuente de ineficiencias y los intentos de “alinear” los dos departamentos no son suficiente. Al final, seguimos con organizaciones y prácticas que son reliquias del pasado (en el peor de los casos datan de hace varios siglos y, en el mejor, de la época previa a la Web Social) y mientras tanto nuestros clientes y las tecnologías en nuestras manos han experimentado una revolución.

Marketing integrado con Ventas

En el caso de productos de compra compleja estos cambios están muy ligados a la evolución de Internet:

  • El nuevo Cliente 2.0 está al mando. Hoy día, la mayoría de las compras comienzan con una búsqueda online o una conversación en medios sociales. Con proliferación de contenidos  disponibles en la web los compradores pueden realizar solos la mayor parte de la investigación y evaluación de productos. Las tornas han cambiado y ahora la asimetría informativa favorece a los clientes: cada vez más, en el momento en que entablan el diálogo con un suministrador ya han tomado su decisión.
  • Las actividades de generación de ingresos son más medibles. Las nuevas tácticas y canales digitales de relación con el mercado y las tecnologías de automatización y analíticas hacen posible medir y evaluar las diferentes iniciativas comerciales. Hoy día, las empresas que implementen la infraestructura adecuada (analítica web, scoring de leads…) pueden medir el impacto de todos sus esfuerzos comerciales sobre los ingresos inmediatos y futuros.

Revenue Performance Management

La solución está en integrar Marketing y Ventas (y otras organizaciones implicadas) en un proceso unificado con el objetivo común de la generación de ingresos. El Revenue Performance Management (RPM, también conocido como Lead-to-Revenue Management, L2RM) se ha definido como una estrategia que optimiza las interacciones con los compradores a través de todo el ciclo de ingresos para producir un crecimiento predecible de los ingresos.

Éstas son algunas características de las empresas que implantan el RPM:

  • Eliminan los tradicionales silos organizacionales internos. No definen su organización y sus procesos comerciales en función de criterios egocéntricos o de “cómo se han hecho las cosas siempre”.
  • No hay un funnel de ventas que exista separadamente de un funnel de marketing: todo es parte de un único Ciclo de Ingresos y -dependiendo del proceso de compra del cliente- es posible que tanto Marketing como Ventas tengan que intervenir en todas las fases del ciclo.
  • Crean ofertas que sean fáciles de comprar y adaptan sus procesos comerciales a los clientes, con el objetivo último de ayudarles a comprar. En productos innovadores eso significa en ocasiones contribuir a crear un proceso de compra en los clientes o “enseñarles” a comprar, pero no tratar de imponerles un proceso externo y artificial.
  • Para ello, desarrollan una profunda comprensión de sus clientes, sus perfiles, motivaciones y comportamientos.
  • Implementan un proceso integrado de generación de ingresos optimizado para facilitar a cada potencial cliente el “viaje” hasta el final de su proceso de compra, eliminando bloqueos y acelerando el tránsito mediante el suministro de la información y la interacción más adecuadas en cada momento.
  • Son capaces de medir y gestionar cada fase de su ciclo de generación de ingresos: eso incluye el potencial de ingresos de los clientes a través de cada etapa del ciclo.
  • Como consecuencia, conocen con precisión cómo los cambios en sus actividades comerciales influyen en sus ingresos y llegan a ser capaces de prever su generación de ingresos a medio y largo plazo.
  • Fomentan el feedback y la optimización del proceso.

De este modo el Revenue Performance Management nos permite construir una “máquina” de generar ingresos mucho más fiable y escalable.

Aunque el RPM suele estar sustentado por una infraestructura tecnológica (típicamente, sistemas de Marketing Automation y similares) no es una tecnología, sino una estrategia de negocio enfocada en un ciclo unificado de generación de ingresos y en la organización y procesos más adecuados para conseguirla.

En un próximo post trataremos de responder a una pregunta importante: ¿sirve para algo el funnel comercial?.

El post «Construye tu máquina de generar ingresos» se publicó primero en “Marketing & Innovación”.

[Conceptualizar nuestros problemas de marketing y ventas desde un punto de vista interno puede confundirnos. Descubre en este documento cómo definir tus verdaderos problemas de marketing desde la perspectiva del cliente.]

8 comentarios

Olvídate de alinear Marketing y Ventas

por en 31 marzo 2013

La descoordinación entre Marketing y Ventas es fuente de ineficiencias. Y los intentos de “alinear” los dos departamentos no son suficiente. La solución está en integrar ambas organizaciones en un proceso unificado con el objetivo común de generar ingresos.

En empresas con productos de compra compleja es habitual que Marketing y Ventas constituyan departamentos separados, incluso cada uno con su propio director que reporta directamente al CEO. Esta división proviene de una época en la que los suministradores eran prácticamente la única fuente de información sobre soluciones / productos y aspiraban a ejercer el control sobre el proceso de compra. Sobre el papel, Marketing construye preferencia y genera demanda en el mercado y Ventas desarrolla relaciones con los potenciales clientes y cierra las operaciones.

Marketing vs Sales

Sin embargo, la difícil coordinación entre los dos departamentos se ha traducido en una serie de consecuencias no deseadas:

  • Existe un funnel de Marketing y otro de Ventas, independientes y conectados por un traspaso de leads de uno a otro departamento.
  • Cada departamento tiene sus propios objetivos y métricas. Esta dicotomía ha favorecido a Ventas -que proporciona los resultados más tangibles- en detrimento de Marketing -que típicamente es visto como un centro de costes difícil de controlar y cuya aportación es discutible.
  • La falta de coordinación produce fricciones: Ventas se queja de la baja calidad de los leads que Marketing les proporciona y Marketing critica que Ventas no persigue sus leads adecuadamente. Los leads generados por Marketing son minoría en el pipeline de Ventas y este departamento debe realizar su propia generación de demanda, utilizando para ello contenidos que no son los que produce Marketing.
  • En conjunto la gestión de los procesos comerciales es altamente ineficiente, con un gasto en Marketing+Ventas que representa el porcentaje sobre ingresos más alto de la empresa (un 40% en promedio).
  • Y no olvidemos las consecuencias hacia el exterior de nuestra organización. A nuestro potencial cliente le da igual si está hablando con Marketing o con Ventas: necesita tener una experiencia impecable de investigación, evaluación y compra de nuestro producto. No podemos defraudar sus expectativas desde el primer momento, dándole una imagen de dispersión, inconsistencia o, lo que es peor, rivalidad entre departamentos.

Por eso durante los últimos años ha surgido un interés creciente por mejorar la coordinación y alinear Marketing y Ventas. Se han creado funciones y organizaciones que sirven de puente (p.ej.: gestión de leads, inside sales/sales development) y reglas de colaboración entre ambos (p.ej.: vocabulario común, reglas de traspaso de sales-ready leads).

Alinear Marketing y Ventas no es suficiente

Pero aunque son pasos en la dirección correcta, no son suficientes. Cuando el alineamiento Marketing / Ventas se reduce a poco más que consensuar una “definición universal” de lo que constituye un lead listo para su traspaso a Ventas nos estamos conformando con un enfoque de mínimos, de evitar fricciones en lugar de fomentar la colaboración y optimizar el proceso conjunto.

Porque en definitiva Marketing y Ventas tienen un solo fin: maximizar los ingresos de la empresa. Por eso, en lugar de intentar alinear dos procesos separados, para una organización es más útil ver el ciclo comercial completo como un proceso continuo de Generación de Ingresos. Como analogía, pensemos en la generación de ingresos como un proceso de fabricación -cuyas actividades se realizaran todas internamente- que tiene por objetivo producir clientes satisfechos que paguen por nuestros productos, repitan y nos recomienden. Las oportunidades de optimización se multiplican cuando se trata de un proceso integrado, en lugar de dividido artificialmente por una organización con silos estancos que no está pensada para ser más productiva.

Este enfoque, con los departamentos de Marketing y Ventas integrados y trabajando hacia el objetivo común de generar ingresos, ha dado origen al concepto de Revenue Performance Management. Entre otros aspectos, se caracteriza por utilizar un proceso comercial extremo a extremo pensado para favorecer el avance de cada potencial cliente en su ciclo de compra y un funnel único de principio a fin para medir y controlar todas las fases.

Del concepto de Revenue Performance Management nos ocuparemos en próximas entradas.

Este post en “Marketing & Innovación”.

[Conceptualizar nuestros problemas de marketing y ventas desde un punto de vista interno puede confundirnos. Descubre en este documento cómo definir tus verdaderos problemas de marketing desde la perspectiva del cliente.]

7 comentarios

Libro Iniciador: Consejos de Marketing para Iniciadores

por en 16 marzo 2013

Los amigos de Iniciador me invitaron a escribir un capítulo para su último libro: «Consejos de Marketing para Iniciadores».

Finalmente han sido veinticinco los emprendedores y marketers  que se han animado a participar en este proyecto, ofreciendo sus consejos en el campo del Marketing a todos aquellos que se están iniciando en la aventura de emprender. Y viendo el historial de mis coautores no puedo menos que pensar que estoy en una compañía inmejorable.

Os invito a participar en el proyecto de edición del libro a través de la plataforma de crowdfunding Lanzanos. Sinceramente creo que vale la pena.

Y por si os apetece saber de qué va mi capítulo, aquí va la introducción:

Consejos de marketing para iniciadores

Emprendedor: no dejes el Marketing para el final

“Cuando acabemos de desarrollar este producto NOS LO VAN A QUITAR DE LAS MANOS.” ¿A alguien le suena esta frase? Yo mismo la he pronunciado en más de una ocasión. Historias como las de Facebook han creado la ilusión de que si construyes el “producto correcto” la adquisición de clientes será fácil. Lo triste es que después de haber invertido mucho tiempo y dinero en desarrollar una oferta (producto/servicio) la mayoría de las veces los clientes no llegan. Y pasada esa primera sorpresa muchos emprendedores se ven abocados a embarcarse en un mal necesario que ellos llaman “marketing”.

¿En qué consiste el marketing para muchos emprendedores? Pues en una serie de actividades dudosas que tenemos que hacer cuando nuestro producto no “se vende solo”: comprar publicidad, enviar emails no solicitados, hacer visitas “a puerta fría”… El marketing es esa actividad perversa que consiste básicamente en engañar a los clientes para que compren productos que claramente no necesitan.

Ahora sabemos que las startups no suelen fracasar por falta de ideas o de tecnología, sino de clientes. Y sin embargo, muchas viven concentradas en sus ideas o su tecnología y no dan ese paso esencial de intentar conocer su mercado hasta que ya es demasiado tarde. Las historias de productos que se venden solos son la excepción y no cuentan el enorme esfuerzo que les supuso descubrir un mercado y sembrar y cultivar su base de clientes.

¿Cómo debería ser el Marketing para una startup?

En este artículo vamos a desarrollar una idea: el Marketing no es algo que se añade a posteriori y que solo se necesita con productos tan patéticos que no cuentan con una masa enfervorecida (y voluntaria) de apóstoles y recomendadores. El Primer Principio del Marketing dice que la mejor manera de vender un producto es hacer productos que los clientes vayan a comprar. El Marketing es una actividad estratégica que busca poner en el mercado productos que los clientes necesitan y desean. Como dijo Peter Drucker hace muchos años: “El objetivo del Marketing es conocer y entender al cliente tan bien que el producto o servicio se ajuste a él y se venda solo”.

La mayoría de los productos que parecen venderse solos es porque han incorporado el Marketing más esencial o estratégico desde el principio -desde antes siquiera de definir su oferta- y han salido al mercado para encontrar respuestas reales a preguntas como estas: ¿qué problema vamos a resolver? ¿a quién? ¿qué producto sería el más adecuado? ¿cómo conseguir que el mercado lo adopte? ¿están los clientes dispuestos a pagar?

…

No dejéis de colaborar en el lanzamiento de «Consejos de Marketing para Iniciadores».

Este post en «Marketing & Innovación».

2 comentarios

¿De verdad estás preparado para el Marketing de Datos?

por en 3 marzo 2013

El marketing está en plena burbuja de analítica y datos. Pero ¿estamos los profesionales preparados para esta nueva etapa? Descúbrelo con un sencillo test.

(NOTA: aunque estoy convencido de que a los lectores de este blog les resultará obvio, cuando hablo de Marketing de Datos no me refiero al marketing de bases de datos.)

El marketing siempre ha sido pionero en la aplicación del análisis de datos pero hasta hace unos pocos años éste era territorio exclusivo de las grandes empresas de consumo. Las técnicas de segmentación y minería de datos y el uso de paquetes de software estadístico constituían el día a día de equipos de matemáticos dedicados a detectar los “mensajes ocultos” detrás de las grandes cantidades de datos que generaban el uso de cuentas bancarias, el consumo de servicios de telecomunicaciones o los tickets de supermercados. Pero para la mayoría de empresas el marketing ha sido tradicionalmente una disciplina fundamentalmente creativa (a veces, en el mal sentido de la palabra) y difícil de medir y optimizar.

Overwhelmed by Data

Unos negocios cada vez más digitales y un marketing más automatizado y online han alterado esta situación: el marketing esta forzado a sacar partido a todo ese ingente “rastro digital” que dejan las interacciones de nuestros clientes (reales y potenciales) con nuestros productos, marcas y campañas tanto en nuestras propias plataformas como en canales externos. Impactos, clics, visitas, shares, likes, comentarios, posts, uso de features de nuestro producto, consumo de servicios, solicitudes de soporte por diversos canales … todo contribuye a la explosión de ese Big Data que está en el epicentro de la enésima revolución de marketing. Analítica web, monitorización de medios sociales y análisis de la conversión y la velocidad en el funnel han pasado a ser técnicas imprescindibles.

Tanto es así que el año pasado la gente de Gartner armó un gran revuelo cuando predijo que en 2017 el CMO gastaría más en tecnologías de la información que el propio CIO. Y recientemente IDC anunció sus predicciones 2013 para los directores de marketing con el subtítulo “Today’s CMO Becomes Master of Data”. Cuatro de esas diez predicciones giran alrededor de los datos.

Soy un convencido de que el marketing necesita recorrer ese camino y pasar a ser una disciplina que  requiera de los dos hemisferios cerebrales y que conjugue la creatividad con el análisis. Las decisiones del marketing no pueden estar fundamentadas en “intuiciones” mal informadas, es hora de que sus directivos apliquen la famosa frase (atribuida a W. Edwards Deming) de “in God we trust, all others bring data”.

Pero todo esto me despierta una gran duda: ¿realmente los profesionales del marketing estamos preparados no ya para protagonizar, sino para entender y practicar en el día a día esta nueva manera de hacer las cosas? ¿Para medir, analizar y optimizar nuestro marketing usando números?

Y aunque lo que sigue no es más que una opinión, mi impresión es que no. Para la mayoría de los marketers que me he encontrado en mi vida profesional los números no eran el terreno donde más cómodos se encontraban. En cuanto a la estadística… entre el colectivo era mayoritario el apoyo a esa ingeniosa frase (pero obtuso concepto) de que «la estadística nos enseña que si Pedro se come un pollo y Juan ninguno, esto equivale a que cada uno de ellos se coma medio pollo «.

¿Estás preparado para un futuro de datos? Descúbrelo con este test

Por eso he diseñado este pequeño test que nos permitirá autoevaluarnos. Basta con responder a las siguientes preguntas o decidir si el enunciado es verdadero o falso:

  1. Una raqueta y una pelota de juguete cuestan en conjunto 1,10 €. La raqueta cuesta un euro más que la pelota. ¿Cuánto cuesta la pelota?
  2. En una ciudad hay dos hospitales. Uno es muy grande y el otro es pequeño. En un determinado día, el 80% de bebés que nacieron en uno de los hospitales resultó ser varón. ¿Para cuál de los dos hospitales resulta más verosímil este hecho?
  3. Es inútil jugar al número 11111 en la lotería porque es imposible que salgan cinco dígitos iguales. (Otra variante: si un año sale premiado el 58653, al año siguiente es imposible que salga ese mismo número).
  4. Si un sitio web recibe en media 10.000 visitas al día eso quiere decir que la mitad de los días tiene más de 10.000 visitas y la otra mitad, menos de esa cantidad. (O, mejor aún: nuestro SEO es tan bueno que todos los días tenemos un número de visitas superior a la media de nuestro sitio).
  5. La mayoría de los vendedores de éxito en venta compleja tienen un perfil Challenger. Por lo tanto, un vendedor tipo Challenger tiene más probabilidad de conseguir el éxito.
  6. En una guerra, todos los aviones que regresan de sus misiones muestran daños por bala en las mismas áreas del fuselaje. Así pues, lo óptimo es reforzar dichas áreas.
  7. En cierto país con 20 millones de trabajadores activos el desempleo aumenta en un trimestre en 100.000 personas; al siguiente trimestre el paro sólo aumenta en 99.800, luego el crecimiento del desempleo  se está frenando. (Ésta es la que en Estadística se conoce como “Paradoja de Montoro” y sí, ya sé que no estoy teniendo en cuenta los efectos de la estacionalidad ;- )
  8. Entre los varones de una población se aprecia una gran correlación entre el porcentaje de grasa corporal y la talla de pantalón, luego… si se usan pantalones grandes, se engorda.

Estoy seguro de que las cuestiones van a resultar muy sencillas para los lectores de este blog (y hoy tampoco tengo muchas ganas de trabajar) así que no voy a explicar las respuestas, que en todo caso son: 1) 5 céntimos. 2) Hospital pequeño. 3-8) Falso.

Si no has acertado la mayoría de las preguntas (o si alguna de ellas –especialmente la 3– te ha provocado cierto desasosiego intelectual) tal vez no estás preparado para la nueva era del Marketing de Datos.

Mi impresión es que un CMO del siglo XXI no puede conformarse con seguir las antiguas prácticas de Estrategia-Planificación-Ejecución y delegar o subcontratar el análisis y la optimización de su marketing. El CMO debe arremangarse e involucrarse activamente en ciclos de Experimentación-Medida-Análisis-Optimización para implantar un marketing más ágil y más eficaz. A ello dedicaremos algunos próximos posts en este blog.

Este post en “Marketing & Innovación”.

[Conceptualizar nuestros problemas de marketing y ventas desde un punto de vista interno puede confundirnos. Descubre en este documento cómo definir tus verdaderos problemas de marketing desde la perspectiva del cliente.]

3 comentarios

Diseño ágil de experiencias de usuario

por en 23 febrero 2013

La velocidad y la colaboración de Agile imponen nuevas condiciones a la práctica del Diseño. Por otra parte, en el desarrollo de productos es imprescindible que un buen diseño de experiencias pueda abrirse paso a través de la ingeniería ágil. ¿Cómo deberían integrarse las prácticas del Diseño y Agile?

Ya vimos en un post anterior que, aunque la ingeniería Ágil y el Diseño de experiencias de usuario implican enfoques originalmente diferentes, la adopción cada vez mayor de ambas filosofías para el desarrollo de nuevos productos está forzando a una convergencia y a una integración de las dos.

Dual track agile design

Una mala integración entre el Diseño y Agile produce problemas como estos:

  • Ineficaz planificación de las iteraciones porque falta una visión del producto y los elementos del backlog están mal definidos
  • Baja velocidad del proceso global porque muchos detalles se están elaborando durante la iteración
  • Despilfarro de recursos y reproceso elevados porque los elementos del backlog no han sido validados con los clientes y otros afectados
  • Productos con funcionalidades correctamente implementadas pero que no coinciden con las que necesita el mercado ni proporcionan una experiencia de usuario adecuada.

Integrando Diseño y Agile

Para evitar estos problemas han ido cristalizando algunas buenas prácticas que ayudan a integrar el desarrollo de experiencias de usuario en entornos de construcción ágil de productos. A continuación os resumo algunas, adaptadas de un muy referenciado post de Jeff Patton “Twelve emerging best practices for adding UX work to Agile development” (un poco antiguo pero de lectura obligada para todos los interesados en este tema):

  • Jefes de producto, diseñadores  e ingenieros deben trabajar integrados en equipos multidisciplinares de gestión y desarrollo de producto. Todos deben colaborar a través de las actividades de descubrimiento, validación y construcción de soluciones para el mercado.
  • Investigar, modelar y diseñar al principio… pero solo lo justo. La idea es realizar al inicio un diseño “suficiente” que proporcione un marco sobre el cual ir construyendo el diseño detallado a medida que el proyecto avanza. Resulta primordial identificar y comunicar las líneas generales de la funcionalidad y la experiencia de usuario para poder trabajar luego en sus partes manteniendo el contexto. Esta actividad debe estar totalmente integrada en nuestros esfuerzos para descubrir el producto: encontrar una solución a nuestro problema de mercado que sea útil, usable, deseable, factible y viable. A pesar de lo que algunos apóstoles agilistas proponían hace algunos años, las empresas que tienen éxito incorporando Diseño y Agile sí hacen un trabajo previo de investigación y modelado que genera personas, escenarios, modelos de flujo, etc. Sin embargo, han aprendido a comprimir la duración de su trabajo mediante las siguientes prácticas:
    • Priorizar el tipo de usuarios a investigar y reducir drásticamente el tiempo dedicado a usuarios de baja prioridad
    • Modelar rápidamente, aplicando métodos ligeros y colaborativos
    • Diferir los trabajos menos urgentes de investigación hasta la fase de implementación
    • Construir escenarios y artefactos (mockups, wireframes) de alto nivel que comuniquen la interacción y look-and-feel generales
    • Estas actividades se suelen realizar en una fase de planificación previa o una “Iteración 0”, junto con otros trabajos de prototipado de arquitectura, puesta en marcha de plataformas, etc.
  • Los diseñadores deben acostumbrarse a trabajar “por partes” y a una cadencia más rápida. En Agile la construcción se realiza por elementos  de funcionalidad (usualmente expresados como “historias de usuario”) que tienen valor y son comprobables desde la perspectiva del cliente. Hay que aprender a dividir el trabajo de especificación y diseño en partes coherentes que puedan ser diseñadas, construidas y validadas independientemente. Asimismo, la velocidad de iteración de Agile puede requerir que los diseñadores trabajen a un ritmo más rápido que el que les podría resultar cómodo. Algunos diseñadores y algunas metodologías de diseño son más compatibles con la filosofía ágil que otros.
  • Utilizar tracks paralelos de diseño e implementación. Los equipos en contacto con el cliente deben trabajar con uno o dos períodos de antelación para definir y diseñar lo que será construido en los futuros períodos. Esto permite validar las features más complejas con tiempo suficiente para mejorarlas. Es primordial evitar que el trabajo de diseño se realice durante el mismo sprint en que está teniendo lugar la implementación. Sin embargo, alguien del equipo de ingeniería debe revisar las ideas y prototipos en cada etapa para aportar feedback sobre factibilidad y costes y proponer mejores soluciones. Cuando el equipo de implementación está trabajando en la iteración T, el equipo de diseño está:
    • Investigando a los clientes sobre lo que se implementará en T+2
    • Validando con clientes prototipos de diseño que se implementarán en T+1
    • Colaborando con el equipo de ingeniería en las implementaciones actuales (T)
    • Validando con clientes lo construido en la iteración anterior (T-1)
  • Utilizar prototipos como especificaciones. En lugar del documento tradicional de especificaciones utilizar prototipos, habitualmente anotados “sobre la marcha” en una discusión con el equipo de implementación.

La adopción de una ingeniería ágil en la construcción de productos puede tener un impacto muy notable sobre cómo se practica el diseño en nuestra empresa:

  • Si la práctica de Diseño en nuestra empresa era débil antes de adoptar Agile, este cambio no le va a favorecer
  • Si la práctica de Diseño en nuestra empresa era fuerte antes de adoptar Agile seguirá siendo fuerte después, pero tendrá que evolucionar y adaptarse.

Aunque la convergencia de Agile y Diseño no está exenta de fricciones, crea muchas oportunidades y mejoras: haciendo que diseñadores e ingenieros trabajen juntos les permite enfocarse en objetivos más claros a corto plazo y eso puede beneficiar a la calidad de nuestros productos y al tiempo de salida  al mercado.

Este post en “Marketing & Innovación”.

[El diseño de producto es mucho más que un barniz estético a posteriori y especialmente en áreas como la experiencia de usuario constituye un gran eje de diferenciación. Descubre en este documento el papel del diseño en el desarrollo de productos.]

6 comentarios

Taller sobre técnicas y habilidades de venta para profesionales tecnológicos

por en 16 febrero 2013

En algunas empresas y centros tecnológicos la venta es considerada un mal necesario y una actividad poco honorable. Muchos científicos e ingenieros (yo también he estado en esa situación) creen que su tecnología es tan buena que se vende sola y no consideran necesario hacer el esfuerzo de traducir las características de su oferta en valor para el cliente.

Pero los que piensen así van a descubrir una dura realidad: los compradores no tienen dinero para gastar (y menos en experimentos con nuevas tecnologías) y toda inversión es sometida al escrutinio más severo. En los tiempos que corren, las empresas y centros tienen que conseguir que los profesionales tecnológicos que se encuentran en contacto con el cliente ayuden a detectar oportunidades de venta, a comunicar el valor de su oferta y a colaborar en un equipo comercial multifuncional.

Este es el tema del taller que voy a impartir en la Federación Española de Centros Tecnológicos (Fedit), titulado «Técnicas y habilidades de venta para profesionales tecnológicos», y que tendrá lugar en su sede de Madrid el próximo 27 de febrero.

Intentaremos ayudar a los profesionales técnicos de empresas y centros tecnológicos a ser conscientes de la importancia de la labor comercial y de la orientación al cliente y dotarles de los conocimientos y habilidades necesarios para participar activamente en procesos de venta compleja basada en el valor para el cliente. En definitiva, a convertir al personal tecnológico en protagonistas y colaboradores clave en los procesos de venta.

Éste es el resumen de contenidos:

¿Cómo se compran productos/servicios tecnológicos?

  • El nuevo equilibrio de poder: el comprador está al mando
  • Entendiendo al comprador: perfiles y sesgos psicológicos, motivaciones
  • Procesos de compra compleja: etapas, roles. Compras de alto escrutinio

¿Qué es realmente el Valor para el Cliente?

  • Cómo nuestra tecnología crea valor para el cliente
  • Modelos de valor para el cliente: cómo conceptualizar y medir el valor
  • Propuestas de valor ganadoras: cómo explicitar y comunicar eficazmente el valor
  • Cómo posicionar nuestra oferta

¿Cómo vender creando y capturando Valor para el Cliente?

  • El compromiso Valor de la vida del cliente / Costes de adquirir un cliente
  • Cómo debe cambiar la venta a lo largo de los ciclos de vida de la tecnología y el mercado
  • Venta basada en el Valor: principios y métodos
  • Técnicas: venta consultiva, venta provocativa
  • Soporte técnico a ventas: presentaciones, demos, prototipos
  • Nuevas técnicas para nuevos tiempos: Ventas 2.0

En está página tenéis más información sobre contenidos a inscripción. Si estáis por Madrid ese día, os animo a que os inscribáis y a que nos conozcamos personalmente. Por cortesía de Fedit, los lectores de este blog que no sean asociados a la Federación de Centros Tecnológicos pueden recibir un descuento del 20% sobre el precio de inscripción si ésta se realiza antes del 22 de febrero. Enviad un email a comunicación@fedit.com y os explicarán como acogeros a la promoción.

Gracias a Marta Muñoz (@MartaMunozFerna) y a su equipo por contar nuevamente conmigo.

Este post en “Marketing & Innovación”.

1 comentario

Agile y Diseño: ¿son incompatibles?

por en 10 febrero 2013

Agile y Diseño tienen orígenes y enfoques muy diferentes. Las prácticas ágiles minimizan el diseño previo y su velocidad de iteración deja poco tiempo para la investigación de clientes y la experimentación de nuevos modelos de interacción con el producto. Pero la necesaria confluencia entre ambos está imponiendo nuevas condiciones a los profesionales de uno y otro lado.

(IMPORTANTE: cuando en este post hablamos de Diseño nos referimos al diseño de experiencias de usuario o UX, no al diseño técnico.)

A primera vista, Agile y Diseño tienen muchos aspectos en común: aplicados al desarrollo de productos ambos ponen su foco en el usuario y aplican un proceso iterativo de refinamiento del producto guiado por el feedback del mercado, que se captura mediante artefactos “provisionales” (mockups, prototipos, versiones preliminares y limitadas del producto…). Los dos enfoques comparten el objetivo último de proporcionar productos dotados de significado y que aporten valor para sus clientes.

Fight Agile UX

Agile y Diseño son fundamentalmente diferentes

Pero esas similitudes no nos deben impedir ver las diferencias –en algunos puntos antagónicas– entre ambos enfoques. Especialmente en el desarrollo de productos para un mercado (no de proyectos a medida para un cliente) estamos hablando de filosofías, ámbitos de aplicación y resultados muy diferentes:

  • El diseño de experiencias de usuario consiste en realizar investigación de clientes y en conceptualizar o representar el comportamiento del producto que se va a construir. Y el diseño de experiencias no es algo que se pueda hacer completamente por piezas: hay que considerar la experiencia de usuario holísticamente (si no en profundidad al menos sí en sus líneas generales y su filosofía). Por eso sus partidarios defienden que, análogamente a los planos de un edificio, el diseño de un producto debe realizarse antes de empezar a construirlo.
  • Agile es principalmente implementación (es decir, entrega de versiones funcionales del producto) y generalmente entra en acción cuando hemos decidido que vamos a construir la “unidad 0” de algo. Agile hace énfasis en la entrega rápida e iterativa de productos operativos, lo que en el caso de algunos enfoques anticuados o extremos se consigue a costa de prescindir de una planificación y diseño elaborados.

No olvidemos que Agile proviene del mundo del desarrollo de proyectos a medida (y no tanto en desarrollo de productos replicables), un escenario donde tradicionalmente no se ha concedido una gran importancia a la experiencia de usuario. Cuando el objetivo prioritario es proporcionar una serie de features, la experiencia de usuario suele ser un “subproducto” no muy logrado. Por el contrario, en productos para un mercado la experiencia del usuario es primordial y el Diseño nació para esos escenarios.

A principios de la pasada década, cuando Agile y Diseño empezaron a pasar al primer plano, las diferencias entre ambos eran más patentes. En un debate clásico que tuvo lugar en 2002, Alan Cooper (pionero del diseño de interacción) y Kent Beck (creador de XP) no sólo fueron incapaces de ponerse de acuerdo, sino que ninguno de los dos parecía entender al otro. Reconozcamos que era la “prehistoria” y que desde entonces ambos metodologías han evolucionado, pero la conversación nos da idea de sus diferencias en origen.

Para reducir el riesgo y mejorar la calidad del producto, en Agile una release se divide en varias iteraciones, en cada una de las cuales se implementa un conjunto de “historias de usuario” (u otro artefacto para especificar funcionalidad). Este foco en las features nos puede hacer olvidar que la experiencia del usuario no se puede diseñar por partes: debe tener sentido para ese usuario en cada release. Si en Agile renunciamos a modelar con antelación lo que se va a implementar podemos acabar con un producto fiable y bien construido pero que carezca de un significado, una integridad y una interacción coherente. Y es que algunas cosas a las que se deja que “emerjan” terminan resultando criaturas muy feas.

Condenados a entenderse

Tal vez el principal beneficio del diseño de UX es la capacidad para imaginar y representar cómo un conjunto desordenado de funciones y significados se puede sintetizar armoniosamente. Por desgracia, algunas prácticas ágiles extremas relegan su papel al de esfuerzos a corto plazo para diseñar y rediseñar elementos pequeños y aislados. Y aunque en este campo Agile puede mejorar la usabilidad del producto, los resultados tienen a menudo un carácter incremental.

La velocidad de ciclo y la cadencia que impone Agile ha sido uno de los aspectos más difíciles de reconciliar con el Diseño. ¿Con unos ciclos tan cortos tenemos realmente tiempo para entender completamente las necesidades de nuestros usuarios? La respuesta corta es “no”. Pero la respuesta correcta es que si estamos descubriendo las necesidades de los usuarios durante la implementación estamos haciendo algo rematadamente mal. La urgencia por alimentar los ciclos de Agile y por dedicarnos a los “árboles” de la actual iteración nos puede impedir ver el “bosque” de la experiencia holística de usuario y descubrir nuevos y rompedores modelos de interacción que diferencien a nuestro producto de sus rivales.

Además, la falta de un diseño inicial validado con los usuarios puede llevar en fase de construcción a un rediseño o un refactoring excesivo que incremente los costes y retrase la salida al mercado; algo que, paradójicamente, impide alcanzar los objetivos de Agile. Hay que buscar un equilibrio: combinando un esfuerzo inicial con pasos pequeños y constantes que avanzan hacia un producto coherente, el Diseño tiene que abrirse paso. De lo contrario Agile se acaba convirtiendo en una serie de experimentos de diseño de muy alta fidelidad y coste.

Como no podía ser de otra forma, en los últimos años hemos asistido a un acercamiento entre UX y Agile, con prácticas de uno que pasan al otro (y, curiosamente, con primeras figuras de cada una de las corrientes participando en los eventos de la otra). Las prácticas del nuevo Agile Product Management recogen el uso de mockups y prototipos para generar lo que se conoce como “visión” del producto, y que recoge los resultados del análisis de la oportunidad de mercado y de la definición y especificación general del producto. Esta visión se traduce en “épicas” y “temas”, que son los artefactos con los que Agile especifica la funcionalidad a alto nivel. Aún así, queda mucho camino por recorrer en cuanto a la integración del Diseño en Agile.

La adopción de Agile está obligando a cambiar la forma de trabajar de los diseñadores, pero la combinación de Agile y UX abre nuevas oportunidades tanto para los profesionales como de proporcionar mejores productos a los clientes. Y al diseño ágil de experiencias de usuario (lo que se conoce como Agile UX) dedicaremos un próximo post.

Este post en “Marketing & Innovación”.

[El diseño de producto es mucho más que un barniz estético a posteriori y especialmente en áreas como la experiencia de usuario constituye un gran eje de diferenciación. Descubre en este documento el papel del diseño en el desarrollo de productos.]

5 comentarios

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

Descubre tu producto antes de construirlo

por en 16 diciembre 2012

La aplicación de una “ingeniería ágil” en el desarrollo de nuevos productos puede provocar que  la mayor parte del feedback del mercado se concentre durante las actividades de construcción del producto.  Pero esta realimentación puede ser tardía, cara e ineficaz.

Hace unos días, impartiendo un seminario sobre gestión de productos tecnológicos, alguien preguntó (con muy buen criterio) en qué se diferencian esos Productos Mínimos Viables de “baja fidelidad” ­-según la terminología de moda- que se utilizan para validar el encaje problema/solución y los tests de concepto del marketing tradicional. Y en mi opinión, la respuesta es: en nada… y en mucho:

Diseño Coche

  • Esencialmente, el objetivo es el mismo: validar el interés en un concepto o descripción preliminar del producto por parte de su mercado potencial antes de construirlo. El test de concepto empezó a aplicarse inicialmente en productos de consumo a principios del siglo XX y se ejecutaba presentando a potenciales compradores una descripción del (inexistente) producto con sus características y beneficios principales plasmados en una hoja de papel (o, más tarde, elaborados en forma de anuncio). Básicamente se trata de averiguar si el mercado podía percibir al potencial producto como algo que solucionara sus problemas, si estarían dispuestos a comprarlo frente a otras alternativas y cuánto podrían pagar por él. Tradicionalmente se han venido usando entrevistas en profundidad y focus groups para explorar y verificar cualitativamente ese encaje y cuestionarios sobre muestras significativas de compradores para validarlo cuantitativamente.
  • Lo que sí ha cambiado radicalmente son los medios. Herramientas audiovisuales de bajo coste (presentaciones, vídeos, animaciones) permiten presentar el concepto a los clientes de manera mucho más explícita, rica e interactiva. Y una simple página web que presente las bondades de nuestro futuro producto y dé opción a comprarlo, junto con un mínimo presupuesto de publicidad PPC que dirija tráfico hacia ella, han pasado a ser la forma más rápida y barata de validar un concepto.

Esto viene a colación de que las nuevas metodologías y herramientas para incorporar el feedback del mercado están afectando no sólo a la forma de realizar pruebas de concepto, sino a todas las actividades del desarrollo de nuevos productos. Especialmente en aquellos casos en que el producto a desarrollar es realmente nuevo (en cuanto a mercado, aplicación, tecnología, etc.) hemos aprendido que un proceso secuencial de requisitos-especificación-construcción (o cualquiera que sea el nombre que le demos) que no incorpore un input continuo de los clientes es ineficaz y suele conducir a productos que estos no quieren comprar.

Las filosofías lineales y secuenciales de desarrollo de nuevos productos, donde la opinión de los clientes permanece “desconectada” entre la prueba de concepto inicial y los tests alfa/beta (y los tests de mercado) con el producto ya terminado, hace mucho que dejaron de ser el único camino. Paulatinamente se han ido incorporando prácticas y técnicas provenientes de disciplinas como el marketing, el diseño y la ingeniería, que promueven un flujo continuo de feedback de los potenciales clientes a través de un proceso iterativo y concurrente de desarrollo del producto.

Una de esas técnicas es la implementación/ingeniería ágil de producto (un tema sobre el que últimamente hablamos mucho por aquí). Lamentablemente, la práctica actual en muchos equipos de desarrollo consiste en concentrar la mayor parte del esfuerzo de realimentación del mercado durante las iteraciones de Agile en fase de construcción del producto. Y posiblemente este comportamiento no es ajeno a una aplicación miope de la técnica del Producto Mínimo Viable (un concepto habitualmente mal entendido y con un nombre desastroso).

No dejes el feedback del mercado para la fase de construcción del producto

Pero la agilidad en la implementación no debe ocultar la necesidad de iterar, descubrir -y eventualmente «pivotar»- el producto antes de empezar a construirlo. Cuando en un post anterior hablábamos de las funciones de Definición, Diseño e Implementación del producto ya decíamos que en general no son actividades lineales y secuenciales, sino iterativas, solapadas y guiadas por el input del mercado. Concentrar el feedback de los clientes durante los sprints de la implementación puede ser tardío, lento, ineficiente… cuando no a veces imposible.

  • El feedback durante la construcción puede ser inútil si la iteración es imposible (o muy difícil) tal como ocurre en algunos sectores o tecnologías. Toda la flexibilidad y bajos costes de evolución en las industrias del software o los contenidos digitales se convierte en rigideces y dinero malgastado masivamente en sectores donde la tecnología, el consumo de materiales o el uso de equipamientos caros hacen prohibitiva la iteración.
  • El feedback durante la construcción puede serdemasiado tardío. Si entre las primeras pruebas de concepto (cualquiera que fuera su forma) y la primera iteración de la implementación no has tenido input de los clientes has estado volando a ciegas demasiado tiempo.
  • El feedback durante la construcción puede ser excesivamente lento y caro. Cuando estamos validando requisitos, funcionalidades, experiencias de usuario, etc. necesitamos realizar muchos experimentos de manera rápida y barata. Las semanas o meses del típico ciclo de sprint imponen unas latencias y unos costes excesivos sobre el proceso, comparado con las horas o días que se pueden conseguir con técnicas de prototipado y simulación.
  • El feedback durante la construcción puede ser ignorado. Aunque las metodologías de implementación ágil fomentan el aprendizaje y la adaptación, siempre es caro y difícil cambiar de dirección cuando se ha invertido un tiempo y un dinero considerables en un determinado enfoque o arquitectura.

Con esto no estoy ni mucho menos abogando por que en la fase de implementación no se aplique el feedback de los clientes ni la iteración (más bien al contrario). Lo que quiero decir es que ese input del mercado y esa iteración deben producirse desde antes, de manera más rápida y más barata y en un proceso continuo que abarque todas las actividades del desarrollo del producto. De todo ello hablaremos en el siguiente post, y especialmente de lo que significa “descubrir” un producto (una pista: no consiste en diseñarlo en detalle).

Este post en “Marketing & Innovación”.

[¿Estás interesado en identificar oportunidades de mercado, valorando y priorizando los riesgos? Este documento te enseña cómo descubrir y comprender mercados que todavía no existen.]

10 comentarios