La mayoría de las empresas no tiene un problema de ideas. Tiene un problema de decisiones.
Imaginemos una reunión en una empresa grande. Hay una idea nueva, un equipo disponible y muchas ganas de empezar. Alguien presenta una funcionalidad. Otra persona habla de la tecnología necesaria. Después aparecen las fechas, el presupuesto y el roadmap.
Todo parece avanzar.
Hasta que alguien hace una pregunta incómoda:
¿Qué problema del cliente estamos tratando de resolver?
Muchas empresas llegan a esa pregunta demasiado tarde. Cuando ya comprometieron recursos, anunciaron fechas y construyeron una solución que quizás nadie estaba esperando.
Amazon desarrolló una forma particular de evitar ese recorrido. Antes de asignar presupuesto, formar un equipo o escribir una línea de código, intenta definir cómo debería sentirse la experiencia para el cliente.
El proceso se conoce como Working Backwards: trabajar hacia atrás desde el resultado que se quiere generar. Amazon describe este método como parte central de su forma de desarrollar productos.
Antes del código, una promesa
Muchas iniciativas de Amazon empiezan con un comunicado de prensa ficticio. El producto todavía no existe, pero el equipo escribe como si ya hubiera sido lanzado.
El documento tiene que explicar quién es el cliente, qué problema tiene, cómo se resolvería y por qué debería elegir esa solución. Después aparece un FAQ con las preguntas difíciles: cuánto costaría, qué riesgos tendría, qué impacto generaría en otras áreas y qué tendría que cambiar dentro de la compañía para hacerlo posible.
No parece una gran innovación. Pero obliga a ordenar la conversación antes de que el entusiasmo se convierta en una estructura difícil de detener.
En muchas empresas, el recorrido es inverso. Primero aparece una tecnología. Después alguien busca dónde aplicarla. Luego se arma un equipo, se crea un roadmap y se empieza a trabajar. Recién varios meses más tarde alguien pregunta si el cliente realmente necesitaba eso.
Para ese momento, el proyecto ya tiene defensores, fechas comprometidas y demasiadas horas invertidas como para cancelarlo fácilmente.
Amazon intenta trasladar esa discusión al principio. Antes de construir, el equipo tiene que ser capaz de explicar por qué vale la pena hacerlo.
El PM no administra solamente tareas
En este modelo, el Product Manager no es la persona que actualiza un tablero o reparte tickets entre diseñadores e ingenieros.
Su trabajo es bastante más incómodo.
Tiene que representar la voz del cliente, entender sus problemas, construir una estrategia y hacerse responsable de los resultados del producto. AWS explica el rol del Product Manager dentro de Amazon en estos términos.
Eso cambia las preguntas que aparecen en una reunión. El PM no debería preguntar únicamente si una funcionalidad llega a tiempo. También debería preguntar si esa funcionalidad resuelve el problema correcto, qué comportamiento espera cambiar y cómo se va a saber si realmente produjo un resultado.
Una empresa puede entregar todo lo que prometió y, aun así, no haber construido nada importante. Puede cumplir el roadmap y alejarse del cliente. Puede trabajar más rápido y avanzar en la dirección equivocada.
El valor de decir que no
Hay otro aspecto relevante del modelo de Amazon: muchas ideas no llegan al mercado.
Los propios exejecutivos de la compañía explican que los equipos pueden invertir mucho tiempo en preparar documentos que finalmente no reciben aprobación. Eso no se considera necesariamente un fracaso. El proceso existe, entre otras cosas, para descubrir qué ideas no deberían recibir recursos.
La mayoría de las empresas no tiene problemas para generar ideas. Tiene problemas para descartarlas.
Como hay capacidad disponible, hay que llenarla. Como existe una herramienta nueva, hay que incorporarla. Como alguien tuvo una buena idea, hay que convertirla en proyecto.
Pero no todo lo que puede construirse merece ser construido.
La capacidad de decir que no antes de empezar puede ser una de las formas más concretas de proteger tiempo, dinero y foco.
Una promesa sencilla puede esconder una operación enorme
La entrega rápida ayuda a entender por qué el Product Management no se reduce a definir funcionalidades.
Para un cliente, recibir un pedido en dos días parece una promesa simple. Para Amazon, cumplirla exigió coordinar centros logísticos, inventario, transporte, software, datos, proveedores y una enorme cantidad de decisiones operativas.
La empresa presenta la entrega en dos días como uno de los ejemplos de innovación que transformó la experiencia de sus clientes y modificó las expectativas de toda la industria. AWS analiza ese caso dentro de su modelo de gestión de producto.
La promesa era sencilla. El sistema necesario para cumplirla no lo era.
Ahí aparece una de las funciones más valiosas de un PM: conectar lo que el cliente espera con lo que la organización realmente puede sostener.
Lo que Amazon entendió
El beneficio de tener Product Managers no está solamente en lanzar mejores productos.
Está en crear claridad antes de comprometer recursos. En ordenar conversaciones que normalmente aparecen demasiado tarde. En hacer visibles las restricciones. En traducir una necesidad del cliente en una decisión que diferentes equipos puedan ejecutar.
Amazon no tiene una fórmula mágica. Tiene mecanismos: documentos, revisiones, métricas, equipos pequeños y responsabilidades claras.
Y una expectativa exigente: antes de construir, hay que poder explicar por qué vale la pena hacerlo.
No todas las empresas necesitan copiar exactamente el PR/FAQ de Amazon. Pero todas deberían poder responder algunas preguntas antes de iniciar un proyecto:
- ¿Qué problema concreto estamos resolviendo?
- ¿Para quién?
- ¿Qué cambiaría si lo resolvemos?
- ¿Cómo vamos a medirlo?
- ¿Qué deberíamos dejar de hacer para liberar capacidad?
Cuando esas respuestas no existen, el proyecto suele empezar igual. Solo que empieza con más reuniones, más suposiciones y más riesgo.
La tecnología puede acelerar la ejecución.
Pero no puede decidir qué merece ser ejecutado.
Esa sigue siendo una responsabilidad de gestión.
Y, en una empresa compleja, alguien tiene que sostenerla.
Fuentes consultadas
Julieta Magan
Founder & Project Manager at POMO
Impulsando la cultura del trabajo flexible y la gestión de proyectos elástica a través de POMO.