Cómo pasar de una Cultura de Proyecto a una Cultura de Producto

Hay conceptos que se explican mejor poniéndolos frente a otros, y eso es lo que ocurre con la cultura de producto.

En Thiga, hablamos mucho de cultura de producto porque sembrarla en las empresas donde colaboramos forma parte de nuestra misión. Pero también por una cuestión de convicción: realizar los cambios (mentales, organizacionales y estructurales) que implican pasar de una cultura de proyecto a una cultura de producto nos confiere mayores probabilidades de lanzar e iterar productos que tienen cabida en el mercado.

Y para ello es necesario saber identificar cuándo estamos trabajando bajo las actividades que definen un proyecto y cuándo lo hacemos bajo la mentalidad de producto. Vamos a lío.

De dónde venimos: la cultura de proyecto

Tradicionalmente, se creaba producto sin prácticamente research y atendiendo a una serie de requisitos previos que eran desarrollados por proveedores o partners. En la mayoría de los casos, bastaba el conocimiento y la reputación de la entidad en quien se delegaba el proyecto para decantarse por ella, ¿era la idónea? No se sabía hasta que llegaban los entregables, momento en el que salía a la luz el contraste entre las expectativas y la realidad.

El tiempo de desarrollo se podía alargar por rectificaciones, así como se disparaban las estimaciones de presupuesto.

Por entonces, las metodologías dominantes (waterfall, V-model...) conllevaban una serie de riesgos como por ejemplo:

• Desconocimiento sobre si el producto que estamos desarrollando es el producto que nuestros usuarios necesitan.
• El efecto túnel: en el tiempo que hemos pasado realizando cada una de las fases para desarrollar el producto, el mercado ha cambiado y nosotros sin darnos cuenta hasta que lo lanzamos.
• Apuntar a un segmento de usuarios equivocado. Cuántas veces ha pasado: crear un producto útil pero que nadie quiere.

Cuando sabes cuál es el problema, es más fácil ver la solución, y en este caso, está claro que estos riesgos nos exigieron más rapidez o menos tiempo entre la creación del producto y su puesta a prueba por el mercado, al igual que una mejora continua para adaptarse a lo que nuestros usuarios/clientes necesitan.

Por suerte, en la última década hemos experimentado un cambio en la manera de crear software y ha sido gracias a las metodologías ágiles.

Dónde estamos: la agilidad y el paso a la cultura de producto

Agile Software Development es el enfoque en el que los requisitos y las soluciones evolucionan porque los esfuerzos de los equipos, con múltiples competencias, están centrados en la colaboración entre ellos, a la vez que se sitúan cerca de sus usuarios/clientes finales. Con los métodos ágiles:

• La planificación es adaptable
• El desarrollo escalable
• La entrega es rápida
• Y la mejora continua.

Un marco que permite una respuesta rápida y flexible a los cambios que se producen en un mercado cada vez más complejo. Por supuesto, los Product Owner y Product Managers han de conocer estos métodos, así como saber cuál escoger (si tienen esta posibilidad) dependiendo del producto que tienen entre manos. De esto último hablamos en este post sobre Agile, Scrum y Kanban.

A dónde deberíamos ir: la cultura de producto

La aventura comienza cuando lanzamos el producto y no tanto durante su desarrollo. Es en ese momento cuando empezamos a hablar de “iterar”, e incluso de “pivotar” si tenemos el oído bien puesto (estar cerquita del usuario).

La cuestión es poner énfasis en reducir los riesgos que mencionábamos al principio, o como decimos en Thiga: desarriesgar, identificar las hipótesis más arriesgadas vinculadas a una idea de producto y lanzar experimentos rápidos y económicos para validarlos o invalidarlos.

Fácil de decir, complejo de implantar. De ahí que se abra el melón: ¿cómo sabemos que hemos dejado atrás la tradicional cultura de proyecto y hemos adoptado una cultura de producto? Veamos.

Diferencias entre cultura de proyecto y cultura de producto

• Un proyecto es un conjunto de actividades que tienen como objetivo definir una necesidad dentro de plazos fijos y dentro de un presupuesto asignado.
• Un producto es un bien o servicio que satisface la necesidad de un usuario.

Como ves, cuando hablamos de producto no hay limitaciones temporales y tampoco se acota a nivel de recursos. ¿Quiere decir esto que los recursos de un producto son ilimitados? No, lo que quiere decir es que un proyecto tiene un final definido, pero de un producto debemos buscar su constante mejora para crear valor para el usuario.

La temporalidad es una de la diferencia más destacable entre la cultura de proyecto y la cultura de producto, pero como decíamos, en la práctica no son actividades antagónicas sino complementarias. El ejemplo más descriptivo es iOS10, la versión del sistema operativo de Apple (proyecto) e iOS, el sistema operativo en sí (producto).

Cuando se creó iOS no se pensó en un sistema operativo con una fecha fin, pero sus versiones (con sus mejoras y añadiduras) sí que lo tienen y todos los usuarios sabemos cuándo llega ese fin: cuando toca actualizar y pasamos a otra versión del producto: iOS11, por ejemplo.

Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy

El producto se debe alimentar de proyectos

Seguimos tirando del hilo de la temporalidad.

El lanzamiento de un proyecto (output) es el momento de celebración del equipo cuando sabe que es momento de poner el foco en otro proyecto.

Eso no ocurre con el producto, cuyo momento de celebración del equipo es cuando se alcanzan las métricas que ayudan a conseguir los outcomes.

Como muchos sabéis, los KPIs están pensados para la mejora continua del producto y aquí entra una de las principales implicaciones de la cultura de producto: entender la fase de discovery como una actividad recurrente que permita seguir construyendo y optimizando el producto, y no como una sola fase, que es más propio de la cultura de proyecto.

Llegados a este punto, tenemos la certeza de la complementariedad, es decir de que desarrollamos producto a través de múltiples proyectos que obedecen a un calendario, un presupuesto y un alcance previamente definido por el Project Manager.

¿Y qué ocurre cuando el proyecto se queda sin recursos antes de su lanzamiento? Ahí decide la persona o equipo que manda sobre el proyecto, una responsabilidad más difusa, pero que normalmente recae en Negocio.

Por supuesto, la gestión de recursos y el foco del impacto en clientes y negocio es responsabilidad el Product Manager, así como de lo que entendamos como el éxito o fracaso del producto.

En definitiva, que un equipo haga producto no significa que tenga cultura de producto. Son muchos los que se lanzan al mercado sin una visión definida (que se necesita) y sin las buenas prácticas del product management que sostengan su evolución en el tiempo y por lo tanto, determinen su éxito.

Ahora que sabemos cómo pasar de cultura de proyecto a cultura de producto, ¿qué tal si nos cuentas los retos a los que se enfrentan tu equipo de producto?

Para saber más: descarga nuestro libro Las Claves del Product Management

Foto de XPS en Unsplash