Ni chicha ni limonada

Hace unas semanas en Conversaciones de Producto Leandro Malandrini, ex Chief of Product & UX de Despegar y actual CPO de PedidosYa usó ésta frase -muy argentina- para describir que una de las peores cosas que una compañía puede hacer es quedarse a mitad de camino en su proceso de transformación hacia una organización de producto.

Photo by Sama Hosseini on Unsplash

Quienes abrazamos ésta disciplina defendemos un conjunto de ideas, principios y valores que creemos son el mejor camino para incrementar la valuación de las compañías y hacer felices a los usuarios:

Creemos así en algunos elementos fundacionales como lo son:

la alineación que debe existir entre todas las áreas y actores; la misión y visión corporativa bien divulgada y entendida, donde los mismos equipos de producto de no más de 5 integrantes son quienes construyen la estrategia del producto basados en los inputs del mercado y de la propia compañía; donde se toman las decisiones todos los días basadas en datos por sobre las opiniones o valoraciones; donde se escucha al usuario (con entrevistas, con encuestas, con A/B testings, con datos de comportamiento) para determinar los pains más importantes; donde equipos multidisciplinarios horizontales despojados de jerarquías y talentosos en cada uno de sus roles, trabajan de forma autónoma enfocados en alcanzar outcomes sobre outputs, experimentando, aprendiendo y mejorando en períodos de tiempo de 2 a 3 semanas. Y donde el éxito es medido en términos de métricas diseñadas en conjunto (llámese OKRs, North Star o cualquier otro modelo de objetivos).

Photo by Daria Nepriakhina on Unsplash

Claro que existen y han existido otras formas de organizar el desarrollo de productos, a lo largo de la historia de la administración hemos visto y estudiado varios de ellos.

La organización más tradicional que las empresas han adoptado ha sido la de establecer una relación de cliente-proveedor entre lo que comunmente se llaman las “áreas de negocio” (como si el resto de las áreas no fueran parte del negocio) y el área de tecnología.

Así el cliente tiene una idea de lo que quiere que el equipo de desarrollo debe implementar, un analista se encarga de documentar y elaborar las especificaciones del requerimiento, un project manager será el encargado de velar para que las actividades necesarias para la entrega del proyecto se lleven adelante, y finalmente el cliente recibirá el producto solicitado. Este modelo, aún utilizado en cientos de empresas de todos tipo tiene básicamente 2 grandes inconvenientes: el primero es que generalmente el entregable no cumple con las expectativas del cliente, y el segundo es que los tiempos de delivery no son los establecidos en el gantt. En definitiva éste modelo termina costando recursos y tiempo, y generando un valor a veces muy pobre.

Photo by RoseBox رز باکس on Unsplash

Volviendo al título que dio origen a éste post, algunas empresas nacen con estas concepción o bien otras emprenden el cambio hacia una organización de producto porque están convencidos que ese es el camino, y así de forma iteartiva comienzan la transformación, que desde ya no es fácil ni rápida ni tampoco se lleva adelante sin dolor. Desde el board, el C-level y los mandos medios hay una convicción y ésta permea a través de todas la organización.

Tambien están los que no tienen esa convicción pero leen, escuchan y ven ejemplos de exito como los de Netflix, Spotify y Amazon y deciden comenzar con algunos cambios. Incorporan la figura del Product Owner, a veces reportando a las áreas comerciales y otras veces al área de tecnología, los miembros de los equipos van intercambiandose de acuerdo a la necesidades de corto plazo, se implementa de alguna forma una metodlogía ágil para organizar las tareas de los equipos, pero en general no se tratan de equipos epoderados sino de doers que en definitiva terminan haciendo lo que determine lo que se conococe con el acrónimo HiPPO, “highest paid person’s opinion”. Se implementan los OKRs por que Google los implementó, pero en definitiva son objetivos más orientados a outputs que a otra cosa.

El peor de los mundos. Claramente los resultados no estarán acorde a las expectativas que la transformación hacia Producto generó en toda la compañía. Y probablemente se tome la decisión de volver hacia atrás. El tema acá es no haber cruzado el puente, es haber implementado algunos cambios, algunos sólo superficiales y el no haber estado convencidos del proceso desde un inicio.

Photo by Fabio Comparelli on Unsplash

En algunas actividades los modelos híbridos son modelos exitosos, que toman lo mejor de una disciplina y lo mejor de otra. En el caso de la forma de organizar una compañía en relación al desarrollo de productos el modelo híbrido no es recomendable.

Si realmente estás transcitando por ésta transformación o estás pensando en implementar un cambio de éste tipo, la mejor recomendación es hacerla, respetando sí la cultura y valores de la compañía, customizandola de acuerdo a ellas, pero hazlo a fondo. “It’s a marathon, not a sprint”.

T1E5 — Relación de Producto con Stakeholders y estrategia con Leandro Malandrini

--

--

Somos una comunidad de creadores de productos digitales con contenido 100% en español. Product Management, UX, Lean, Experimentación, Data Science, Marketing… si ayuda a hacer productos exitosos, es bienvenido.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Federico Iglesias

Federico Iglesias

Product Leadership | Product Director @ Globant