Product Trio: El triunvirato perfecto

Escrito por Cris Busquets. Publicado en Proceso de diseño

¿Qué es el product trio?

Producto piensa en la estrategia, diseño diseña y el equipo de desarrollo… desarrolla. Así es como trabajan muchas empresas, con estas tres “patas” desconectadas entre sí.

Esta estructura puede funcionar, pero crea desconexión entre las diferentes partes y promueve un tipo de trabajo que John Doerr define como “mercenarios”: equipos que no se siente empoderados, no tienen el ownership de su trabajo y, obviamente, están muy desconectados del problema que están resolviendo.

¿Tiene solución? Sí. Y tiene pinta de que se encuentra en los “product trios”.

¿Qué es un “product trio”?

La primera persona a quien le leí ese concepto fue Teresa Torres, autora del libro Continuous discovery habits y reconocida coach que ayuda a equipos de producto a integrar de forma adecuada prácticas de product discovery.

Según Torres, la estructura que te describía al inicio de este artículo lleva a proyectos que terminan costando más dinero del que estaba presupuestado y que además, entregan menos funcionalidades de las previstas. Esto es así porque se produce una desconexión entre las tres partes: las product managers no tienen claro qué se puede desarrollar, las personas que programan no son conscientes de la estrategia y quienes diseñan, que están en medio, no tienen toda la información que necesitan para hacer bien su trabajo.

Un product trio es una estructura en la que los perfiles de producto, diseño y desarrollo trabajan de forma conjunta, de manera que es más fácil identificar si aquello en lo que se está trabajando es viable y está alineado con el negocio, puede hacerse y si es útil para los usuarios.

El trabajo en product trios permite:

  • Compartir conocimiento y obtener diferentes puntos de vista
  • Que el proceso sea end-to-end, es decir, desde el discovery hasta el delivery
  • Un liderazgo compartido entre los tres perfiles, cada uno desde su disciplina
  • Que se hable un mismo lenguaje, el de negocio, y este sea el que guíe las discusiones y las decisiones que se tomen

Además se trata de una estructura adaptable, en la que tendrá más o menos peso una parte en función de la fase del proceso en la que se encuentre el proyecto:

Product trio y el proceso de diseño (fuente)

¿Cómo se aplica el “product trio”?

Imagino que quizás estarás pensando que sí, que esto suena muy bien pero que a ver cómo se aplica esto “en el mundo real”.

Como te conté en el artículo sobre las diferentes estructuras de los equipos de diseño, hay diferentes formas de organizar una compañía:

  • Transversal → equipos centralizados: existe uno de diseño, uno de desarrollo y otro de producto
  • Multifuncional → los equipos combinan diferentes perfiles y roles según el producto: pueden tener una product manager, dos product designers y tres desarrolladores o cualquier otra variación
  • Híbrida → se construyen equipos “bajo demanda” en función de lo que necesite la compañía o el producto

Independientemente de cual sea la que utilices en tu trabajo, la estructura del product trio es aplicable en todas. No hay que crear un equipo especial con ello, “simplemente” tiene que producirse de forma relativamente regular (por ejemplo, una vez a la semana o cada dos) una reunión en la que participen las personas responsables de producto, diseño y desarrollo de una funcionalidad o producto de la compañía.

Te pongo un ejemplo más claro. En Holaluz trabajan en equipos multidisciplinares organizados según producto / servicio / fase del funnel. De forma periódica se producen reuniones de product trio dentro de cada equipo. Así, por ejemplo, existe esta reunión en el equipo encargado de ventas de solar, el de zona clientes, etc.

Esta es la mejor manera de asegurar una buena alineación entre todas las partes, ya que permite transmitir correctamente la estrategia y que dentro del equipo se defina la mejor manera de enfocar y trabajar los proyectos.

Sé de buena tinta que esta estructura se está utilizando ya en otras empresas españolas, como SEAT:CODE y Mercadona Tech.

Apuntes finales

Esta estructura es relativamente fácil de implementar en compañías que ya trabajen desde un enfoque de producto, porque “solo” requiere establecer las dinámicas para que se produzcan estas reuniones a tres bandas y todo lo hablado se lleve al día a día.

En empresas en las que no exista un enfoque tan claro hacia producto será más difícil hacerlo, pero no imposible. En estos casos posiblemente sea mejor empezar concienciando sobre la importancia de tener un enfoque en el producto y los usuarios, especialmente con los equipos de desarrollo y marketing.

Qué me dices, ¿te encaja? ¿cómo se trabaja en la compañía en la que estás?



Esto también te interesa 👇

Entrevista Lidia Chía, Senior Game UX Designer

Entrevista a Lidia Chía, Senior Game UX Designer

Diseña con mentalidad de principiante

Diseña con la mentalidad de un principiante

Diferencias diseñador junior y senior

Diferencias entre diseñadores juniors y seniors


Deja tu opinión

  1. Hola Cris. Muchas gracias por tu artículo. En Centribal ya trabajamos de esta manera para acordar qué y cómo. Nos funciona muy bien a nivel de entrega de valor. Mi siguiente objetivo es que el producto trío haga el Discovery de manera conjunta.
    Saludos!

    1. Cris Busquets

      Ay, lo del Discovery es «el otro gran tema». Suele ser difícil, pero espero que encontréis una forma que os encaje 🙂

  2. Hola Cris!! Lo primero, felicitarte por este post que me ha encantado y aprovecho para darte las gracias por todo tu trabajo y el contenido ¡tan valioso! que generas para la comunidad.

    Ante tu pregunta, te respondo que Sí: «La estructura del Product Trío me encaja perfectamente y es algo que precisamente trabajo con cada cliente al comienzo de cada proyecto».

    En mi caso, trabajo en el área de Servicio de Consultoría de Microsoft donde, en cada proyecto, trabajamos en equipos multidisciplinares con diferentes roles (un Digital Advisor centrado en la parte relacional y el negocio del cliente, un Product Designer y Tech Lead centrados tanto en el diseño de UX/UI y la solución técnica, y los Developers y el Project Manager centrados en el delivery).

    Para esto, el enfoque que tenemos en consultoría es involucrar desde el momento 0 a los principales responsable de negocio del cliente como si fueran uno más del equipo. Y la dinámica que seguimos es trabajar con un enfoque Agile donde tenemos un sprint inicial para hacer el discovery y definir la estrategia a seguir. A partir de ahí, en los siguientes sprints trabajamos en el diseño y desarrollo de la solución de forma iterativa con el cliente.

    Algo que siempre me gusta matizar es que ponemos mucho foco en trabajar en modo DevOps, ya que nos ayuda a que todo el equipo sea más autónomo de principio a fin tanto en el diseño y desarrollo como a la hora de desplegar y operar de la solución para que los usuarios finales y responsables de negocio puedan probar cualquier cambio y dar feedback en cada iteración.

    1. Cris Busquets

      Gracias por tu comentario, Ignacio 🙂

      Suena muy bien como lo tenéis estructurado en el área de Servicio de Consultoría de Microsoft. Me pregunto si siempre podéis cumplir lo de «un sprint para discovery y otro para delivery» o si a veces se mezclan entre sí porque hay que trabajar en diferentes iniciativas.

      1. Hola Cris,

        Respondiendo a tu pregunta, efectivamente, las actividades de discovery y delivery son iterativas y se entre mezclan entre sí 😉 Pero para ponerte un poco más en contexto, te explico cómo lo hacemos:

        1. Como empresa de fabricante de software, el área de consultoría de Microsoft se encarga precisamente de hacer el delivery de proyectos de soluciones tecnológicas para grandes compañías.
        2. Dichos proyectos, normalmente suelen ser de tamaño grande (de 12 a 24 meses) y en algunos casos pequeños (entre 3-6 meses)
        3. Como te he comentado, en todos ellos se asigna un equipo multifuncional con roles dedicados donde siempre intentamos hacer un Sprint 0 (de tres semanas) para hacer el Discovery inicial mediante reuniones de negocio, entrevistas a usuarios, sesiones técnicas, y sesiones de design thinking.
        4. Dicho Sprint 0 nos permite alinear a todas la partes y tener una visión global del proyecto (es decir, comprender el contexto del cliente, objetivos de negocio, necesidades de los usuarios, el problema a resolver y aspectos o requisitos técnicos a tener en cuenta). Y, además, nos ayuda a delimitar el roadmap del proyecto, las áreas de trabajo y un backlog para los primeros Sprints que luego vamos refinando.
        5. Si el proyecto es grande (entre 12 y 24 meses), en los siguientes sprints, normalmente definimos actividades de discovery y delivery en paraleo según las prioridades y áreas de trabajo identificadas.
        6. Si el proyecto es pequeño (entre 3-6 meses), normalmente son necesarios dos sprints adicionales donde se mezclan actividades de discovery y delivery al mismo tiempo. Luego se pone foco en diseño, desarrollo y entrega en cada sprint hasta la finalización del proyecto.

        En cualquier caso, todo esto depende de cada cliente y cada proyecto. Pero si te interesa, hablamos cuando quieras y te cuento más detalles sobre como trabajamos. 🙂 Sería todo un placer tener la oportunidad de hablar contigo.

Deja tu comentario

Tu email no será publicado. Los campos con asterisco son obligatorios.