¿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 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.]