Equipos de producto o de funcionalidad, esta es la cuestión

Blog

Equipos de producto o de funcionalidad, esta es la cuestión

Este artículo seguramente molestará a muchas personas.

Lo siento por eso, pero el grado de ruido y confusión en torno al papel del producto en las empresas tecnológicas es que solo está empeorando.

Además, veo que los problemas y los comportamientos problemáticos se institucionalizan en conferencias y los programas de capacitación.

Sin embargo, muchas personas solo escuchan lo que quieren en eso, y me ha quedado claro que necesito ser más explícito.

Por lo tanto, si bien este artículo puede ser doloroso de leer, si se ha sentido frustrado con los mensajes contradictorios y confusos de las personas en el mundo de los productos, si tiene paciencia conmigo aquí, espero que esto le brinde la claridad necesaria.

En el mundo de la tecnología, existen realmente tres tipos distintos de “equipos de producto”, en términos generales.

Los más comunes en términos de números absolutos no son realmente equipos de productos, son equipos de entrega.

También conocido como “equipos de desarrollo” o “equipos de scrum” o “equipos de ingeniería” y si su empresa está ejecutando algo como SAFe, desafortunadamente este es usted.

En esta situación, hay un cierto número de desarrolladores y un product owner.

El product owner en este modelo es a lo que me refiero como “administrador de la cartera de pedidos”.

Alguien necesita hacer este trabajo, pero se trata de entregar resultados, y en realidad es muy poco lo que me preocupa en términos de la necesidad de una innovación verdadera y consistente en nombre de nuestros clientes.

He hablado con varias personas de porqué este modelo en realidad solo se vuelve a empaquetar en cascada, y no se usa en verdaderas compañías de productos tecnológicos. Así que vamos a sacar eso del camino.

Este artículo trata realmente sobre la diferencia entre los otros dos tipos de equipos.

Distintos tipos de equipo

Ahora una advertencia justa de que estoy a punto de presentar una nomenclatura que no es estándar.

Pero necesito hacer esto porque hoy, como industria, nos referimos a los otros dos tipos de equipos como “equipos de producto” o “squads”.

Como verán, si bien se ven similares en un nivel superficial, son dramáticamente diferente, especialmente cuando hablamos del papel del gerente de producto.

Cuando escribí sobre las virtudes de los equipos de productos empoderados, me refería a lo que seguiré llamando aquí como equipos de productos.

Específicamente, son multifuncionales (producto, diseño e ingeniería); están enfocados y medidos por los resultados (en lugar de la producción).

Los equipos están facultados para descubrir la mejor manera de resolver los problemas que se les ha pedido que resuelvan.

El propósito de un equipo de producto en este sentido es resolver los problemas de la manera que aman a nuestros clientes, pero a la vez trabajan para nuestro negocio.

Por mucho que desearía lo contrario, sé que solo un pequeño porcentaje de los equipos que existen son equipos de productos en este sentido.

La mayoría de las veces, los equipos no tienen poder alguno. En contraste, están ahí para servir al negocio.

En este artículo, me referiré a esta tercera clase de equipos como equipos de características.

Estoy doblando un poco la definición más establecida de equipos de características aquí, pero estoy usando el término porque ayuda a resaltar que estos equipos tienen que ver con la producción.

Por lo general, se proporciona al equipo en forma de una lista priorizada que se denomina hoja de ruta.

Los riesgos de los equipos

Recuerde que en el producto siempre hay cuatro riesgos:

  • Valor riesgo (¿la gente lo comprará o elegirá usarlo?)
  • Riesgo de usabilidad (¿pueden los usuarios descubrir cómo usarlo?)
  • Riesgo de viabilidad (¿podemos construirlo con el tiempo, las habilidades y la tecnología que tenemos?)
  • Riesgo de viabilidad empresarial (¿funcionará esta solución para las diversas dimensiones de nuestro negocio?)

En un equipo de producto capacitado, el gerente de producto es explícitamente responsable de garantizar el valor y la viabilidad; el diseñador es responsable de garantizar la usabilidad.

El líder tecnológico es responsable de garantizar la viabilidad. El equipo hace esto realmente colaborando de manera intensa, con el fin de descubrir una solución que funcione para todos nosotros.

Cuando hablo y escribo sobre lo difícil que es ser un verdadero gerente de producto de un equipo de producto capacitado, es precisamente porque es muy difícil asegurar el valor y la viabilidad.

Sin embargo, en un equipo de características, todavía (con suerte) tiene un diseñador para garantizar la usabilidad, y tiene ingenieros para garantizar la viabilidad, pero esto es fundamental para entender.

El valor y la viabilidad del negocio son responsabilidad del interesado o ejecutivo que solicitó la función en la hoja de ruta.

Si dicen que necesitan que usted desarrolle la característica x, entonces creen que la característica x entregará cierta cantidad de valor, y creen que la característica x es algo viable para el negocio.

Vale la pena señalar que, aunque la parte interesada es la responsable implícita del valor y la viabilidad, seguirá encontrando una manera de culparlo a usted y a su equipo si no se obtienen los resultados esperados.

Tomó demasiado tiempo, el diseño era malo, se cortaron capacidades críticas para establecer la fecha, etc. Y, por supuesto, su equipo probablemente nunca estuvo convencido de que valía la pena construirlo en primer lugar.

Es una canción antigua y he escrito mucho sobre este problema.

Superficialmente, un equipo de características y un verdadero equipo de producto empoderado son ambos escuadrones. Entonces se ven similares, pero las diferencias son profundas.

Comencemos con el rol del gerente de producto.

En un equipo de producto capacitado, donde el gerente de producto necesita garantizar el valor y la viabilidad, el conocimiento profundo del cliente, los datos, la industria y especialmente su negocio (ventas, marketing, finanzas, soporte, legal, etc.) es absolutamente no negociable y esencial

Sin embargo, en un equipo destacado, ese conocimiento está (en el mejor de los casos) disperso entre las partes interesadas.

En cualquier caso, con suerte está claro que las responsabilidades del gerente de producto en este modelo son muy diferentes para un equipo de funciones.

El trabajo del gerente de producto en un equipo de funciones se describe más comúnmente como una forma de facilitador, “pastorear a los gatos” para que la función sea diseñada y entregada, o alguna forma nebulosa y débil de líder multifuncional que no es realmente responsable para cualquier cosa específica.

Estos equipos de funciones a menudo pensarán que están descubriendo productos, pero en realidad solo se trata de diseño y tal vez una pequeña prueba de usabilidad.
Pero hay otras consecuencias del equipo de funciones en el rol de gerente de producto.

Debido a que el equipo no tiene poder, para ser claros, cuando se le da salida para entregar no tiene poder en ningún sentido significativo, es muy difícil atraer y retener verdaderos diseñadores de productos (alguien experto en diseño de servicios, diseño de interacción, visual diseño e investigación de usuarios).


En la gran mayoría de los casos en los que tiene equipos de características, el diseñador (si hay uno) es un diseñador gráfico.

No es que el diseño gráfico o visual no sea importante, pero lo relevante aquí es que ahora hay una gran brecha: alguien necesita descubrir al menos el diseño de interacción y, con suerte, investigar un poco a los usuarios.

Por lo tanto, es muy común ver presión sobre el gerente de producto en este modelo para tratar de llenar estos vacíos.

Hay otras consecuencias negativas de esta situación, ya que no es difícil aprender las herramientas que usan los diseñadores, pero es difícil aprender cómo hacer un buen diseño e investigación de usuarios.

Lamentablemente, muchos gerentes de producto nunca han tenido la oportunidad de trabajar con un verdadero diseñador de productos profesional, por lo que ni siquiera saben lo que se están perdiendo.


Si tiene la suerte de tener un verdadero diseñador de productos en su equipo (al menos hasta que se vayan a mudarse a una empresa donde sus habilidades puedan ser utilizadas plenamente).

Entonces generalmente (y con razón) se preguntan cuál es el propósito del producto gerente es, ya que no es difícil para ellos asumir las responsabilidades adicionales del gerente de producto del equipo de funciones ya que de todos modos están haciendo la mayor parte del trabajo.

El resultado es que en los equipos de funciones, el rol de gerente de producto es principalmente gerente de proyecto y diseñador en parte (no calificado).

A menudo hay una frustración similar con los ingenieros.

El gerente de producto que realmente es un gerente de proyecto a menudo está en desacuerdo con la forma en que los ingenieros creen que necesitan estar trabajando.

Sin mencionar que en este modelo, los ingenieros están relegados a la entrega, y como he dicho muchas veces, si ese es el caso, solo estamos obteniendo aproximadamente la mitad de su valor real (así que de nuevo, los buenos querrán irse y únete a un equipo de producto capacitado donde realmente pueden practicar su oficio).

Entonces, para cerrar este punto crítico, cuando escribo que el gerente de producto necesita “estar entre los talentos más fuertes de la compañía”, y “el CEO debe ver a los gerentes de producto como futuros líderes potenciales de la compañía” y “el un gerente de producto fuerte es el CEO del producto ”, definitivamente no estoy hablando de un gerente de producto para un equipo de funciones.

Espero que en este momento sepa si está trabajando en un modelo de equipo de características o en un modelo de equipo de producto con poder, pero he aprendido que las personas a menudo son muy reacias a admitir cuando están en el modelo de equipo de características.el equipo de funciones en el rol de gerente de producto.

Debido a que el equipo no tiene poder, para ser claros, cuando se le da salida para entregar no tiene poder en ningún sentido significativo, es muy difícil atraer y retener verdaderos diseñadores de productos (alguien experto en diseño de servicios, diseño de interacción, visual diseño e investigación de usuarios).

En la gran mayoría de los casos en los que tiene equipos de características, el diseñador (si hay uno) es un diseñador gráfico.

No es que el diseño gráfico o visual no sea importante, pero lo relevante aquí es que ahora hay una gran brecha: alguien necesita descubrir al menos el diseño de interacción y, con suerte, investigar un poco a los usuarios. Por lo tanto, es muy común ver presión sobre el gerente de producto en este modelo para tratar de llenar estos vacíos.

Hay otras consecuencias negativas de esta situación, ya que no es difícil aprender las herramientas que usan los diseñadores, pero es difícil aprender cómo hacer un buen diseño e investigación de usuarios.

Lamentablemente, muchos gerentes de producto nunca han tenido la oportunidad de trabajar con un verdadero diseñador de productos profesional, por lo que ni siquiera saben lo que se están perdiendo.

Si tiene la suerte de tener un verdadero diseñador de productos en su equipo (al menos hasta que se vayan a mudarse a una empresa donde sus habilidades puedan ser utilizadas plenamente), entonces generalmente (y con razón) se preguntan cuál es el propósito del producto gerente es, ya que no es difícil para ellos asumir las responsabilidades adicionales del gerente de producto del equipo de funciones ya que de todos modos están haciendo la mayor parte del trabajo.

El resultado es que en los equipos de funciones, el rol de gerente de producto es principalmente gerente de proyecto y diseñador en parte (no calificado).

A menudo hay una frustración similar con los ingenieros. El gerente de producto que realmente es un gerente de proyecto a menudo está en desacuerdo con la forma en que los ingenieros creen que necesitan estar trabajando.

Sin mencionar que en este modelo, los ingenieros están relegados a la entrega, y como he dicho muchas veces, si ese es el caso, solo estamos obteniendo aproximadamente la mitad de su valor real (así que de nuevo, los buenos querrán irse y únete a un equipo de producto capacitado donde realmente pueden practicar su oficio).

Entonces, para cerrar este punto crítico, cuando escribo que el gerente de producto necesita “estar entre los talentos más fuertes de la compañía”, y “el CEO debe ver a los gerentes de producto como futuros líderes potenciales de la compañía” y “el un gerente de producto fuerte es el CEO del producto ”, definitivamente no estoy hablando de un gerente de producto para un equipo de funciones.

Espero que en este momento sepa si está trabajando en un modelo de equipo de características o en un modelo de equipo de producto con poder, pero he aprendido que las personas a menudo son muy reacias a admitir cuando están en el modelo de equipo de características.rustración similar con los ingenieros.

El gerente de producto que realmente es un gerente de proyecto a menudo está en desacuerdo con la forma en que los ingenieros creen que necesitan estar trabajando.

Sin mencionar que en este modelo, los ingenieros están relegados a la entrega, y como he dicho muchas veces, si ese es el caso, solo estamos obteniendo aproximadamente la mitad de su valor real (así que de nuevo, los buenos querrán irse y únete a un equipo de producto capacitado donde realmente pueden practicar su oficio).

Entonces, para cerrar este punto crítico, cuando escribo que el gerente de producto necesita “estar entre los talentos más fuertes de la compañía”, y “el CEO debe ver a los gerentes de producto como futuros líderes potenciales de la compañía” y “el un gerente de producto fuerte es el CEO del producto ”, definitivamente no estoy hablando de un gerente de producto para un equipo de funciones.

Espero que en este momento sepa si está trabajando en un modelo de equipo de características o en un modelo de equipo de producto con poder, pero he aprendido que las personas a menudo son muy reacias a admitir cuando están en el modelo de equipo de características.


Aquí hay algunas pruebas que puede aplicar a su equipo:

  • ¿Se le proporcionan hojas de ruta con características y fechas priorizadas, o se le asignan problemas para resolver con los resultados comerciales?
  • ¿Hay confusión de roles entre usted y su diseñador?
  • ¿Hay confusión de roles entre usted y su gerente de entrega?
  • ¿Pasas la mayor parte del día haciendo gestión de proyectos?
  • ¿Intentó usar OKR y fue un desastre, ya sea que terminó siendo rechazado, o se produjo una combinación artificial de resultados y características?
  • ¿Tienes un equipo de misioneros o mercenarios?
  • ¿Cuál es el nivel de responsabilidad?

Si bien los equipos de características y los equipos de productos se ven muy similares en la superficie, son dramáticamente diferentes en cómo operan.

El nivel de empoderamiento y responsabilidad, y especialmente las responsabilidades del gerente de producto también afectan.

Puedo decirle que, con pocas excepciones, los mejores equipos de productos en las mejores compañías tienen que ver con el modelo de equipo de producto empoderado.

Sin embargo, admitiré que incluso en lo que considero las mejores compañías de productos, no todos los equipos de productos están facultados.

En verdad, algunos son equipos de características. Por lo general, eso se debe a que el liderazgo aún no confía en ese equipo en particular.

A veces, esa confianza debe ganarse primero. Y a veces el problema es con el líder que quiere dictar soluciones.

Nunca he tratado de ocultar mi fuerte sesgo hacia equipos de productos verdaderamente empoderados.

Pero creo que ahora necesito ir más allá de solo abogar por equipos empoderados.

Necesito llamar a los equipos de funciones, los problemas que causan y los malos resultados que ofrecen.

Innumerables empresas hoy se dan cuenta de la inutilidad del modelo de equipo de entrega, y saben que necesitan transformarse en una verdadera compañía de productos con tecnología.

Sin embargo, creen que pueden “marcar esa casilla” haciendo los cambios superficiales para pasar a estos equipos de características .


Al concluir aquí, quiero enfatizar la diferencia entre ser un gerente de producto para un equipo de características frente a un equipo de producto capacitado.

Es un trabajo completamente diferente, que requiere un conjunto de habilidades muy diferente.

Probablemente ni siquiera debería ser el mismo título de trabajo.

Es triste para mí que tantos diseñadores e ingenieros nunca hayan estado expuestos a un verdadero gerente de producto y nunca hayan podido trabajar en un equipo verdaderamente capacitado.

Es por eso que sostengo que hay tanto talento subutilizado por ahí, y por qué sigo tratando de persuadir a las personas para que intenten trabajar como lo hacen las mejores empresas.

Una cosa que puede hacer de inmediato es que la próxima vez que lea un artículo o un tweet relacionado con el producto.

Asista a una conferencia o asista a una capacitación sobre el producto, considere si el autor, el orador o el capacitador están hablando sobre el modelo de equipo de producto autorizado, o el modelo del equipo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

WhatsApp chat