El gran reto de las empresas con respecto a su estrategia de tecnología es evolucionar de un modelo de gestión de proyectos a la construcción de producto (Product Management). El Product Management es una mentalidad diferente que requiere de nuevas herramientas, reportes, usuarios, métricas… ¡analizamos cómo hacerlo!
Project Management, lo que hemos hecho siempre
Desde la era industrial, hemos buscado maneras diferentes de organizar las empresas. Para optimizar los resultados, muchas empresas apostaron por la construcción de departamentos. La idea era clara, si las personas eran recursos y optimizamos su trabajo, entonces conseguíamos mejores resultados. Esta idea funcionaba: el que era capaz de producir más cantidad, con menores costes, entonces dominaba el mercado.
Con el tiempo, apareció la globalización, nuestro mercado dejó de ser local y pasó a ser internacional. Además, estábamos en la era de la personalización, cada cliente quería un trato propio y esperaba productos y servicios que resolvieran sus problemas. Construir un producto digital requería de muchas habilidades: desarrollo software, customer experience, marketing, legal, sistemas… Optimizar cada parte no garantiza que entregamos rápido, lo que nos dejaba fuera del mercado.
En el mundo actual, necesitamos equipos con mentalidad de entregar, de crear productos y de ir aprendiendo del mercado lo más rápido posible. Hemos pasado de equipos eficientes (rápidos produciendo) a equipos efectivos (hacer el producto correcto que genera valor).
El Project Management es una disciplina que trataba de generar certidumbre en nuestra empresa, organizando el trabajo de los recursos (personas) y haciendo que se coordinasen. Sin embargo, que las personas trabajasen mucho no garantizaba que se creas valor, por eso, esta disciplina se ha quedado obsoleta en el mundo del digital y del conocimiento.
¿Qué es un Producto?
Hace años, me incorporé a una consultora de desarrollo software que trabajaba con la mayoría de bancos y aseguradoras de España. En esta empresa, existía un área de producto que desarrollaba software para estos bancos. Lo llamábamos producto porque el software era nuestro y de nosotros dependía dicho producto.
Sin embargo, la estrategia de construcción de producto era tramposa. El producto “base” era nuestro, pero se adaptaba a las necesidades de los clientes de manera excesiva. Los equipos acababan desarrollando un software tan a medida como cualquier proyecto de los que habíamos vivido en este tipo de empresas, es decir, el éxito era entregar un determinado alcance en fecha, sin mirar resultados.
Este “producto” no tenía métricas de valor como pueden ser la satisfacción de usuario, el ROI u cualquier métrica de negocio que demuestre que, gracias a este producto, los customers consiguen mejores resultados.
Un Producto es, bajo mi definición, un software que tiene foco en resultados, cuya función es prestar servicio a un customer para generar valor. Podemos definir valor como dinero, de manera directa o indirecta. Es decir, un producto debe ser rentable, dar buen servicio, ser útil, de alguna manera, y dar resultados para la empresa. Por tanto, el éxito de un producto no es un determinado alcance en una fecha.
Difícil escalar
En los últimos años, he podido trabajar para varias Startups y encuentro un patrón común. Cuando construimos un producto, el hacerlo rápido es clave para entregar valor rápidamente y validar nuestro modelo de negocio (cómo rentabilizar). Ahora bien, el crecimiento rápido dificulta nuestra capacidad de escalar el éxito. En las startups, el coste por usuario suele ser elevado hasta que nuestro producto se expande de manera exponencial.
El punto difícil es escalar cuando el producto está mal construído. Por un lado, queremos abrir nuevos mercados, nuevas features, más clientes… ¡pero el producto está fallando! Si lastramos una gran deuda técnica, es decir, si el número de bugs es elevado porque hemos construído el producto muy rápido, tenemos un tremendo problema para mantener el producto funcionando mientras lo hacemos crecer.
Si apostamos por seguir creciendo, sin pensar en calidad, acabaremos sufriendo por mantenerlo. Sin embargo, solo con mantenimiento nos estancamos a nivel de nuevos usuarios y funcionalidades, lo que dificulta nuestra capacidad de captar nuevos inversores o de ser rentables.
Por eso, los “productos” que dependen de desarrollos en fecha suelen ser poco rentables porque no buscan el escalado, sino rentabilizar a los programadores. Por eso, un verdadero producto necesita un constante input del mercado, tenemos que optimizar el desarrollo para que todo lo que hagamos tenga un reflejo en el valor que damos al producto.
Estimación based management
Cuando construimos un producto, buscamos acertar, ser efectivos. La efectividad se consigue con una conexión contínua entre las personas que construyen el producto y las personas que lo reciben. En 1986, en el artículo que motivó la creación de Scrum, The new new Product Development Game, se explica que los ingenieros iban a la “calle” a hablar con los usuarios para entender sus necesidades y acertar.
No obstante, seguimos viviendo en la cultura del “control” y de la desconfianza en las personas. He visto a muchos “Product Manager” centrarse en estimaciones y en control de personas (mal llamadas recursos) en vez de tener una estrategia de producto basada en las necesidades detectadas.
La gestión basada en estimaciones es herencia del mundo de los proyectos, donde el éxito es la fecha. En este tipo de gestión, estimamos el trabajo antes de arrancar y tomamos decisiones importantes con estos datos. Sin embargo, no son datos fiables ya que, por definición, una estimación es un invento. Si desarrollas un producto, no puedes pensar que el mundo se va a comportar como a ti te gustaría, sino… ¿Serás capaz de adaptarte cuando el mundo cambie?
Falta foco en clientes y en experimentos
En el desarrollo de producto digital, necesitamos un foco real en clientes. ¿Qué quiere mi cliente? ¿Qué le molesta? ¿Qué nos está solicitando? Necesitamos datos de nuestros clientes, no solo encuestas de satisfacción sino también de comportamiento ¿por qué los usuarios no utilizan esta feature?
Este tipo de preguntas es clave para entender el valor de lo que construimos. Sin embargo, distanciamos a los programadores de los usuarios porque es la cultura heredada de trabajar en silos estancos, que apenas se comunican unos con otros.
Si no tenemos la suficiente humildad para aceptar que no podemos controlar el futuro, que hay incertidumbre, pues, dado que no podemos controlar, tendremos que surfear en esa incertidumbre. Sí, sé lo que piensas: “qué frase tan bonita, pero, ¿cómo se hace?”. ¡Con la experimentación!
En el mundo latino, hemos crecido tratando de tener certidumbre. Los latinos no queremos invertir, queremos saber cuánto vamos a recibir y cuándo. Queremos control y la palabra experimento nos da pánico. Hace poco un equipo de producto me dijo: “pero Javi, ¿por qué tenemos que hacer un experimento si estamos hasta arriba?” Tuvimos un interesante debate sobre el hecho de que cualquier cambio que apliquemos al equipo es un experimento potencial: no sabemos el resultado que vamos a obtener.
Un experimento nos da la posibilidad de descubrir mejores resultados. Ahora bien, necesitamos tener muy claro nuestro propósito de producto y de equipo: ¿Por qué construimos este producto? ¿Cómo somos rentables? ¿Qué queremos demostrar? La respuesta a estas preguntas deben ser métricas que objetivicen las respuestas y nos digan lo antes posible el éxito o fracaso del experimento.
Y tú, ¿haces producto o te centras en controlar fechas?
