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

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

Requisitos: expresando problemas de mercado

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

Los requisitos no son especificaciones

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

Artefactos para expresar requisitos

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

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

El marco Importancia / Satisfacción

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

En esta serie de posts analizamos en detalle el marco Importancia – Satisfacción y otros métodos para evaluar y priorizar problemas a resolver.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Embarcarse en el desarrollo de un producto para un mercado es difícil. No todas las empresas tienen la visión, el liderazgo y los recursos necesarios. Pero en muchas ocasiones los escollos que nos impiden convertirnos en una empresa de producto salen de nosotros mismos en forma de falta de visión a largo plazo y malas decisiones.

En muchas empresas de base tecnológica el paso de un modelo de negocio basado en desarrollos a medida a otro basado en producto es un paso natural y obligado, forzado por la propia evolución del mercado. Aún así, en la mayoría de los casos cuesta cambiar a un “pensamiento basado en producto”, sobre todo si la empresa ha disfrutado de una existencia rentable vendiendo proyectos a medida.

El nuevo modelo de negocio exige invertir recursos de todo tipo y desarrollar el producto (al menos parcialmente o en una versión “mínima”) antes de tener clientes. Para ello, los requisitos en cuanto a conocimiento del mercado y necesidades de financiación son más exigentes. Y aunque existen ciertos tipos de productos donde estos requisitos son menos severos que en otros (p.ej., los productos basados en contenidos digitales pueden necesitar una menor inversión y adaptarse bien a un desarrollo iterativo) el paso a un modelo de producto exige un “salto de fe” -y de financiación- que para muchos es insalvable.

Pero no todos los escollos para pasar a una filosofía de producto provienen del exterior. Muchos de ellos nos los creamos nosotros mismos con ideas preconcebidas, una visión a largo plazo miope y juicios optimistas. En este post (al que seguirá una segunda parte) vamos a desgranar algunos de esas barreras que nosotros mismos nos ponemos en el camino hacia un negocio basado en producto.

Estas barreras provienen de ideas como las siguientes:

“Los clientes van a seguir comprando nuestros desarrollos a medida: no necesitamos desarrollar un producto”

Muchas empresas piensan que su negocio de proyectos a medida todavía tiene futuro y postergan la decisión de desarrollar un producto. Y eso puede ser cierto… hasta que en nuestro mercado empiezan a aparecer productos estándar que resuelven razonablemente bien el problema del cliente.

Si existen productos estándar aceptables, la mayoría de las ocasiones los clientes pueden conseguir un encaje entre sus necesidades y un producto (adecuadamente personalizado), con los beneficios que eso conlleva en cuanto a funcionalidad, prestaciones, rendimiento, fiabilidad, evolución, soporte… y, sobre todo, precio.

Ciertamente, los clientes suelen preferir la credibilidad, estabilidad, referencias y (en muchos casos) menor coste total de propiedad de un producto frente a un desarrollo a medida. ¿Te comprarías un equipo/dispositivo/software/instrumento desarrollado a medida cundo tienes un producto que se ajusta tus necesidades, avalado por cientos o miles de clientes como tú y que además tiene más funcionalidad y es más evolucionable y más barato?

En este escenario, los proveedores de soluciones a medida tienen más difícil justificar su valor aportado y su (habitualmente) mayor precio. Eso lleva en el corto plazo a una erosión de la rentabilidad del negocio y a largo a una posible expulsión del mercado.

Por este motivo, muchas empresas basadas en modelo orientado a proyectos se ven forzadas a dar el paso a un negocio de producto: basta con que aparezcan en su sector proveedores de producto fiables en una categoría.

¿Es posible que en tu mercado no aparezcan productos estándar? Eso depende de diversas características estructurales (empezando por el tipo de clientes y sus necesidades), pero ten presente algo: si en tu mercado hay potencial de rentabilidad siempre va a haber un inversor dispuesto a poner el dinero para crear un negocio escalable y capturar ese valor, de modo que ese producto va a aparecer tarde o temprano.

“Este desarrollo para un cliente nos va a servir como producto”

¿Quién no ha pensado alguna vez que ese desarrollo que tenemos que realizar para un cliente se va a poder vender sin más a muchos otros clientes similares? La realidad es menos favorable por varios motivos.

En primer lugar, es posible que en virtud del contrato del proyecto toda la propiedad intelectual de los desarrollos recaiga en el cliente y por lo tanto no podamos (legalmente) vender esos resultados a otros posibles compradores.

Pero además, cuando se desarrolla a medida no se tienen en cuenta aspectos de “productibilidad” (es decir de poder convertir el en futuro ese desarrollo en un producto replicable para un mercado). Un proyecto para un cliente tiene su propia agenda y sus propios requisitos, especialmente en cuanto a plazos y rentabilidad. Se trata de resolver el problema de ese cliente lo más rápido y con los menores costes posibles, y cualquier otro condicionante pasa a un segundo plano.

Facetas como la arquitectura, la modularidad, la adaptabilidad, la evolucionabilidad, la posibilidad de crear de manera eficiente productos derivados… en definitiva, lo que constituiría una buena plataforma de producto se deja de lado y corremos el riesgo de empezar a generar una deuda técnica difícil de pagar en el largo plazo.

Y finalmente -pero no por ello son menos importantes- están los aspectos comerciales y de negocio: ¿Hay un mercado detrás de esto? ¿Cuántos clientes existen con la misma necesidad? ¿Cómo de urgente e importante es la necesidad en esos casos? ¿Puedo llegar desde el punto de vista de marketing y ventas a todos esos potenciales clientes? ¿Cuánto me puede costar esa replicación y comercialización? ¿Puedo construir un negocio rentable con ello?

A veces un cliente no es síntoma de un mercado y el presunto producto puede no llegar a convertirse nunca en un negocio escalable.

En la segunda parte de este post seguiremos desglosando los escollos que nosotros mismos nos ponemos al convertirnos en una empresa de producto.

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

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