Construyendo lo que los clientes necesitan: la receta definitiva

Según Clayton Christensen, profesor de la Escuela de Negocios de Harvard, cada año se introducen casi 30 000 productos nuevos y el 95 % falla. Aunque este número está más relacionado con los productos físicos, solo se necesita un poco de esfuerzo para darse cuenta de que esto es cierto para los productos digitales. Y este es un pensamiento aterrador e inquietante porque las nuevas empresas y los emprendedores invierten toneladas de dinero para construir estos productos. Esto nos lleva a una pregunta importante que todos los gerentes de producto y los equipos de tecnología asociados se hacen cada vez que sumergen sus pies en el río de la creación de productos digitales. ¿Por qué fallan los productos y qué pueden hacer los equipos para crear los productos que necesitan los clientes?

Hace unos días, estaba conversando con un gerente de producto en una de las compañías de software más grandes de nuestro tiempo. Ha estado al frente de varios equipos durante más de dos años. La parte más emocionante de su experiencia es que ha realizado más de 50 experimentos en estos dos años. Y esto ha ayudado a su equipo a comprender qué construir y, lo que es más importante, qué no construir para los clientes. Mientras conversaba con él, entendí que estos experimentos eran costosos en términos de capital y tiempo. Entonces, incluso decidir qué experimentos realizar fue complicado ya que el equipo necesitaba justificar el capital que necesitaban para realizar los experimentos.

Desafortunadamente, solo unas pocas empresas tienen tanto ancho de banda y capital para experimentar. Y, por lo tanto, es extremadamente importante comprender lo que necesitan los clientes y construir los productos en consecuencia. Pero antes de sumergirnos en cómo crear productos que los clientes necesitan, es esencial comprender por qué las empresas no lo hacen.

Razones por las que las empresas no logran crear los productos que los clientes necesitan

• Resolviendo el problema equivocado

Tras la investigación, resultó que la automatización era posible simplemente modificando los sistemas. Y el problema no era usar "ML" para automatizar ciertas tareas, sino automatizar ciertas tareas principalmente porque consumían mucho tiempo. De hecho, tras una investigación más profunda, resultó que esta automatización no era necesaria en absoluto. Esto fue posible porque el gerente de producto invirtió tiempo en comprender y definir el problema. Y es por eso que es imperativo comprender el problema a niveles más profundos para que el equipo/la empresa pueda encontrar el problema correcto para resolver. Este es el primer paso y el más importante, y la mayoría de los productos fallan en este paso.

• Apuntando a la solución perfecta

Algo similar pasó con el jefe de producto con el que tuve una charla. Participó en la creación de un producto que reemplazaría por completo el sistema de administración de contenido actual para alrededor de 600 usuarios internos. El período inicial para construir este sistema fue de 12 meses. Pero a medida que el equipo de ingeniería comenzó a trabajar en la solución, se encontraron con múltiples casos de esquina. Esto aumentó el plazo de 12 meses a 18 meses. Cuando los usuarios se enteraron de esto, comenzaron a cuestionar todo el sistema de administración de contenido. Su punto era que si tomaba tanto tiempo construir todo el sistema, se necesitarían períodos similares y más prolongados para construir nuevas funciones en el futuro. Por lo tanto, siguieron presionando para que se agregaran más funciones al alcance.

Todo esto sucedió porque los equipos de tecnología estaban esperando para construir y lanzar la mejor solución. El gerente de producto compartió que, en lugar de esto, deberían haber dividido el sistema de administración de contenido en funciones menores más prioritarias y lanzarlas iterativamente en lugar de una versión de sistema de gran éxito. Afortunadamente, el riesgo de lanzar de esta manera era menor ya que el sistema estaba destinado a usuarios internos, pero esto podría haber sido un problema mayor si los usuarios fueran externos.

• No recibir retroalimentación temprana

El 30 de junio de 1970, AT&T reveló su servicio Picturephone comercial en la ciudad de Pittsburgh, Pensilvania. Cegados por su propia visión, los ejecutivos de la empresa ignoraron los comentarios negativos que recibió en la fase de prueba. Creían que un millón de unidades estarían en uso dentro de los diez años posteriores al lanzamiento. Para su sorpresa, lo sacaron del mercado en solo tres años debido a la falta de interés de los consumidores. ¿Por qué?

Durante la fase de prueba, los usuarios compartieron sus comentarios. Encontraron el equipo demasiado voluminoso, la pantalla demasiado pequeña y costosa. Pero todo esto fue ignorado, lo que llevó a la falla total del producto.

Obtener comentarios desde el principio y trabajar en ellos lo ayudará a construir la solución adecuada para los problemas de sus clientes.

Productos de construcción que los clientes necesitan

• Enfoque de trabajo hacia atrás

• Encabezado : idealmente, este debería ser el nombre del producto y esencialmente decir de qué se trata el producto.
• Subtítulo : El beneficio principal del producto
• Resumen : resuma lo que hace el producto junto con su principal beneficio
• Problema — Problema específico que resuelve este producto
• Solución : de qué manera el producto resuelve el problema
• Cita tuya : crea un portavoz ficticio y pide una frase que explique por qué este producto es imprescindible.
• Cómo comenzar : explique cómo usar el producto de la manera más fácil posible.
• Cierre y llamado a la acción : finalice el comunicado de prensa informando al lector cómo obtener más información o comenzar a usar el producto.

• Sprint de diseño

Uno de los ejemplos que compartió el gerente de producto fue cómo un sprint de diseño ayudó a su equipo a decidir entre construir y comprar. Su equipo se encargó de cambiar el flujo de producción de contenido que admitía 400 usuarios internos. Las tareas de estos usuarios eran crear contenido (imágenes, videos, gifs, etc.) diariamente que aparecía en el sitio web para 50 millones de usuarios activos diarios. Se dijo que el nuevo flujo de producción de contenido ahorró 2 millones de euros por año en 2020. El gerente de producto reunió un equipo de sprint compuesto por un par de usuarios, su líder, un gerente de ingeniería y un líder de diseño. El sprint se prolongó durante una semana. Al final del sprint, el equipo técnico no solo entendió el problema en cuestión, sino que también ideó una solución de bajo costo que convirtieron en un producto completo en un período de 2 meses.

• Retroalimentación cuantitativa y cualitativa

• Los comentarios cuantitativos incluyen experimentos como pruebas A/B, encuestas con preguntas cerradas y análisis de productos. Esto requiere aptitud analítica ya que los datos son grandes y están expresados ​​en gráficos y números.
• La retroalimentación cualitativa incluye investigación mediante cuestionarios con preguntas abiertas, entrevistas 1:1, observación directa, investigación contextual, grupos focales y recopilación de datos personalizados. En comparación con la retroalimentación cuantitativa, esto se expresa en palabras.

Como tal, existen múltiples formas de comprender lo que los clientes necesitan y crear soluciones en consecuencia, y depende exclusivamente de la empresa y el equipo el uso de cualquiera de los métodos. Pero, lo que es más importante es no construir productos que los clientes no necesiten. La historia dice que cuanto antes se reciban los comentarios de los clientes, más fácil será crear las soluciones correctas y ahorrar recursos.

¿Qué método utiliza en su equipo/empresa para crear el producto/solución correcto? ¿A qué problemas te enfrentas al usar este método? Comenta abajo; Amaría saber.