Productos fallidos

Nota: Este artículo es la versión escrita de una charla que di para desarrolladores en la Craft Conference y para product managers y diseñadores en Mind The Product.

En este artículo quiero hablar sobre las causas por las que tantos productos fracasan.

¿Por qué fracasan los productos y los lanzamientos de productos?

En la mayoría de las empresas veo la misma forma de trabajar básica, y no se compara en absoluto con la forma de trabajar de empresas realmente buenas.

Permitan que les haga una advertencia, porque esta discusión puede ser deprimente, especialmente si están directamente afectados por este tema. Si ese es el caso, les pido un poco de perseverancia.

El proceso de desarrollo de productos

Primero veamos qué proceso utiliza la mayoría de las empresas para desarrollar sus productos. Intentaré no juzgar por ahora, sino simplemente describir el proceso:

Todo comienza con ideas. En la mayor parte de las empresas, estas ideas provienen de la dirección, los stakeholders clave, los dueños del negocio o grandes clientes (o clientes potenciales). En cualquier caso, hay toda una serie de cosas que debemos hacer para las diferentes áreas de una empresa.

A continuación, en la mayoría de las empresas, las ideas se priorizan en un Roadmap y esto tiene dos razones: primero, se quiere trabajar primero en las cosas más valiosas, y segundo, se quiere poder estimar cuándo estarán listas.

Para ello casi siempre hay una sesión de planificación trimestral o anual en la que los líderes revisan las ideas y negocian un Product Roadmap. Sin embargo, para poder priorizarlo todo, primero necesitan una especie de Business Case para cada ítem.

Algunas empresas elaboran Business Cases formales, otras más informales, pero en ambos casos se trata de averiguar dos cosas:

1) ¿Cuánto dinero podemos ganar con esto?

2) ¿Cuánto dinero o tiempo costará? A partir de esta información se crea el Roadmap, generalmente para el próximo trimestre, pero a veces incluso para un año entero.

En este punto llega la orden de marcha para el producto y la tecnología, y normalmente los trabajos se realizan por orden de prioridad.

Cuando una idea llega a la cima de la lista de prioridades, el product manager primero habla con los stakeholders para desarrollar la idea y formular "requisitos".

Estos pueden ser User Stories o alguna forma de especificación funcional; sin embargo, en cualquier caso, el propósito debería ser la comunicación con los diseñadores y desarrolladores que van a construir el producto.

Una vez que se tienen todos los requisitos, se le pide al equipo de User Experience Design (siempre que exista tal equipo en la empresa) que se encargue del diseño de interacción, diseño visual y, en el caso de hardware, del diseño de producto.

Finalmente, los requisitos y las especificaciones de diseño llegan a los desarrolladores. Este es normalmente el punto en el que Agile entra en juego.

El papel de los desarrolladores en el proceso de desarrollo

Los desarrolladores dividen el trabajo en iteraciones, que en Scrum se llaman "Sprints". Normalmente se necesitan entre 1 y 3 Sprints para implementar la idea.

En el mejor de los casos, las pruebas de QA están integradas en el Sprint. Si no, el equipo de QA realizará algunas pruebas posteriores para determinar si la idea funciona como se desea y si no surgen otros problemas (también llamado regresión).

Una vez que se obtiene luz verde del equipo de QA, la idea finalmente se despliega y llega al usuario.

Casi todas las empresas a las que voy, ya sean grandes o pequeñas, llevan muchos años trabajando de esta manera. Y sin embargo, todas estas empresas se quejan constantemente de la falta de innovación y del largo tiempo que pasa hasta que una idea finalmente llega a manos de los clientes.

Agile vs. Cascada

Quizás hayas notado que, aunque mencioné Agile y hoy en día casi todos supuestamente trabajan de forma ágil, el proceso que acabo de describir es básicamente un proceso de cascada. Para ser justos, debo decir que los desarrolladores a menudo sacan de Agile tanto como les es posible dentro de este proceso de cascada.

Bien, quizás esta sea la forma de trabajar de la mayoría de los equipos, pero ¿por qué es necesariamente la causa de tantos problemas?

¿Por qué fracasan tantos productos por esto?

Intentaré mostrarles la conexión de por qué esta forma de trabajar tan extendida es generalmente responsable del fracaso de los productos.

Podría hablar una eternidad sobre los problemas con este proceso, pero simplemente enumeraré el Top 10 de los problemas más graves con esta forma de trabajar. Aunque cada uno de estos diez problemas es realmente grave y podría derribar a un equipo, la mayoría de las empresas tienen muchos o incluso todos estos problemas a la vez.

1) Comencemos por arriba: la fuente de las ideas. Este modelo lleva a ofertas especiales orientadas a los ingresos y productos orientados a los stakeholders. Hay mucho que decir sobre este tema, pero por ahora solo diré que estas no son las mejores fuentes de ideas para productos. Otra consecuencia de este enfoque es la falta de empoderamiento del equipo, ya que con este enfoque solo son responsables de la ejecución: mercenarios.

2) Hablemos de la debilidad de los Business Cases. Para que no me malinterpreten, en principio me parecen bien los Business Cases, al menos para ideas que representan una inversión mayor. Pero la forma en que la mayoría de las empresas los crean en este momento para obtener un Roadmap priorizado es realmente ridícula. ¿Recuerdan las dos cosas en las que se basa todo Business Case? Cuánto se va a ganar y cuánto va a costar. En este momento simplemente no podemos saberlo, porque no tenemos idea de ninguno de estos dos factores.

Simplemente no podemos saber cuánto vamos a ganar, porque eso depende principalmente de lo buenas que sean nuestras soluciones. Si el equipo hace un trabajo fantástico y tiene un éxito extraordinario, puede cambiar todo el rumbo de la empresa. Por otro lado, la triste realidad es que la mayoría de las ideas de producto no aportan absolutamente nada. Y no exagero. Me refiero a realmente nada. En cualquier caso, una de las lecciones más importantes del desarrollo de productos es saber lo que no podemos saber. Y en este punto simplemente no podemos saber cuánto dinero vamos a ganar.

De la misma manera, no tenemos idea de cuánto costará el desarrollo del producto. Sin una solución concreta, eso también es bastante difícil de estimar. Muchos desarrolladores experimentados se negarán a dar una estimación tan temprana, aunque algunos aceptarán el viejo compromiso de las "camisetas": ¡al menos digan si es Small, Medium, Large o Extra Large!

Las empresas quieren Roadmaps priorizados y para eso necesitan un sistema para evaluar las ideas. Así que la gente juega al juego del Business Case.

3) A continuación viene un problema aún mayor. Las empresas están obsesionadas con los Roadmaps. He visto muchos Roadmaps y la mayoría son básicamente solo listas de features priorizadas. Marketing necesita este feature para una campaña. Ventas necesita este feature para un nuevo cliente. Alguien quiere integrar PayPal. Creo que entienden lo que quiero decir.

Sin embargo, hay un problema y es quizás el mayor de todos. Lo llamo las "dos verdades incómodas sobre los productos".

La primera verdad es que al menos la mitad de nuestras ideas simplemente no funcionarán. Hay tantas razones por las que una idea no funciona. Lo más frecuente es que los clientes simplemente no estén tan entusiasmados con la idea como nosotros. Así que no usan el producto. A veces quieren usarlo, pero es tan complicado que causa más frustración que beneficio. El resultado es el mismo: los clientes no lo usan. A veces a los clientes les encantaría el producto, pero resulta que implica mucho más esfuerzo del que pensábamos y simplemente no tenemos el dinero ni el tiempo para desarrollarlo.

Les aseguro que al menos la mitad de las ideas en su Roadmap no entregará lo que esperaban. Y por cierto, los equipos realmente buenos asumen que al menos tres cuartas partes de las ideas no funcionarán como pensaban.

Como si eso no fuera suficientemente malo, la segunda verdad es que incluso con ideas que realmente tienen potencial, normalmente se necesitan varias iteraciones para implementarlas lo suficiente como para que realmente entreguen el valor de negocio necesario. Lo llamamos "Time To Money".

Lo más importante que he aprendido respecto al desarrollo de productos es que simplemente no se puede escapar de estas dos verdades, sin importar lo inteligente que seas. Tuve la gran suerte de trabajar con muchos equipos de producto verdaderamente excepcionales. La diferencia está en cómo se manejan estas verdades.

4) El rol del producto en este modelo: en realidad no hablaría del producto como un rol. Básicamente es más bien una forma de gestión de proyectos. En este modelo se trata más de recopilar requisitos y documentarlos para los desarrolladores. Créeme, esto no tiene nada que ver con la gestión moderna de productos.

5) Algo similar ocurre con el rol del diseño. En este punto ya es demasiado tarde para crear valor real a través del diseño. Entonces se recurre al modelo llamado "pintalabios en el cerdo". El daño ya está hecho y solo intentamos disimularlo. Los diseñadores UX saben que esto no es bueno, pero intentan que todo se vea lo mejor y más coherente posible.

6) Donde este modelo pierde la mayoría de las oportunidades es probablemente en el hecho de que el desarrollo se involucra demasiado tarde en el proceso. Se dice que si solo usas a tus desarrolladores para escribir código, pierdes la mitad del valor que podrían ofrecerte. Los desarrolladores suelen ser la mejor fuente de innovación y sin embargo ni siquiera se les incluye en el proceso.

7) No solo los desarrolladores, sino también los principios y principales beneficios de Agile entran en juego demasiado tarde aquí. Los equipos que usan Agile de esta manera obtienen solo alrededor del 20% del valor y potencial de las metodologías ágiles. Aquí Agile solo se refiere a la entrega, pero el resto de la organización y el contexto siguen siendo todo menos ágiles.

8) Todo el proceso está muy orientado a proyectos. Una empresa financia proyectos, contrata personal para los proyectos, impulsa los proyectos y los implementa. Lamentablemente, los proyectos son solo Output, pero en el desarrollo de productos se trata de Outcome. Este proceso lleva inevitablemente a proyectos huérfanos. Bien, algo se lanzó al final, pero no cumple el propósito real. ¿Para qué sirve entonces? Este es un gran problema y está muy cerca de cómo construimos nuestros productos.

9) La mayor debilidad del viejo proceso de cascada siempre ha sido el hecho de que todo el riesgo aparece al final. La validación por parte del cliente ocurre simplemente demasiado tarde.

Espero que ya hayan oído hablar de las metodologías Lean Startup, que representan prácticamente lo contrario. Su principio fundamental es minimizar el desperdicio, y el mayor desperdicio es diseñar, construir, probar y desplegar un feature o producto solo para descubrir que no se necesita. Irónicamente, muchos equipos creen que están aplicando los principios de Lean, pero en realidad solo siguen el proceso descrito anteriormente. Y entonces les explico que están probando sus ideas de la manera más cara y lenta que conocemos.

10) Y por último, mientras estamos ocupados con el proceso y desperdiciamos nuestro tiempo y dinero, los costos de oportunidad de las cosas que una organización podría y debería haber hecho en su lugar representan la mayor pérdida. Ese tiempo y todo ese dinero nunca los recuperaremos.

No me sorprende demasiado que tantas empresas inviertan tanto dinero y tiempo y obtengan tan poco a cambio. Ya les había advertido que esto podría ser deprimente.

La buena noticia es que puedo asegurarles que los mejores equipos no trabajan ni remotamente de la manera que he descrito.

Resumen

Ya he escrito muchos artículos sobre los diferentes aspectos de los mejores equipos. Product Discovery trata sobre cómo encontramos soluciones exitosas para nuestros problemas. Es una forma activa y continua de colaboración entre las áreas de producto, diseño de experiencia de usuario y desarrollo. Continuous Discovery y Continuous Delivery funcionan en paralelo. Los features en los Roadmaps (Output) se reemplazan por problemas de negocio que deben resolverse (Outcome). El objetivo es que el producto se ajuste lo mejor posible a la demanda del mercado (Product/Market Fit).

Si tu empresa aún se aferra a este viejo proceso obsoleto, esperamos que ahora puedas arrojar algo de luz y comenzar con frescura hacia el futuro. Y espero que lo logres antes de que una startup o competidor te adelante, siendo mucho más rápido y efectivo que tu empresa.

Este texto proviene del blog de Marty Cagan y fue traducido por nosotros al español.

Plantilla de tabla para el Product Backlog

=> Así puedes representar User Stories en el Product Backlog como tabla.

El Product Goal Canvas

=> Define tu objetivo de producto con el Product Goal Canvas.