Toma de decisiones en la definición de productos

Análisis de los niveles de delegación de Appelo aplicadas a roles de Líder de Producto, Project manager y Product Owner, y su impacto desde las necesidades del negocio y el usuario, a la delegación completa de una solución.

Dominar la toma de decisiones es un arte. En Diseño de experiencias o desarrollo de productos y servicios “es el resultado de los acuerdos entre quienes las construyen”. ¿Cómo llegamos a esos acuerdos? En mi caso — como responsable de un área de Producto en formación, como ex Product owner y ex Project manager — investigando, escuchando al usuario, mirando el mercado, negociando, co-diseñando, conversando y usando datos.

Lo bueno es que en el mundo de la toma de decisiones de un producto, por mucho que tu rol de gestión lo incluya, no todas las decisiones son 100% tuyas. Y eso es un alivio. Pero es un territorio que debemos saber recorrer o, al menos, mirar desde sus bases.

¿Quién corta el queque? ¿Todos?

En el baile de la toma de decisiones, se generan varias dinámicas entre diferentes actores, como stakeholders, usuarios y el mismo equipo. Y en casi todas, hay que saberse los pasos de la negociación. Pero generalmente, la decisión recae en el rol ligado a producto, por una autoridad intrínseca que tienen este tipo de cargos. Porque para eso nos contrataron, ¿cierto?

Sin embargo, quienes venimos desde la Experiencia de usuario, sabemos que “la negociación contractual es una herramienta usual para establecer acuerdos en cualquier industria. [Pero] en [UX], no resulta suficiente: para lograr valor, es necesaria la colaboración”, dice Santiago Bustelo en la guía Experience Decision Making en 30 minutos, un buen recurso que crearon en Kambrica, sobre los procesos de toma de decisiones en la construcción de experiencias.

El desafío del rol de Producto

1. Cultivar relaciones y coordinar acciones cuando apelar a la autoridad no es posible, implica reconocer y atender necesidades y dolores. En mi experiencia, en la formación de la primera área de Producto de Prey, tuve que poner atención en las aprensiones del equipo de Tecnología y del resto de las áreas que existían en la empresa, para poder movilizar el proceso de creación y mejora continua del producto, incluso de proyectos internos que no tenían impacto en el usuario.
2. Dada la complejidad y resistencia del entorno en el que teníamos que empezar a trabajar, comencé a identificar los diferentes niveles en los que se podía tomar decisiones, tanto desde mi rol como vocera del negocio y del usuario, hasta la total libertad de los tracks de Discovery y Delivery para que le entregaran valor al cliente sin tener que pasar por los managers de las áreas.

La conciencia de estas etapas no se desarrolló de manera incremental, sino como parte de un flow estratégico de prueba y error. Mi guía fue y es la escala de Jurgen Appelo en la que invita a los equipos a ponerse de acuerdo sobre cómo van a tomar decisiones.

7 niveles de delegación de Appelo

Imaginemos que estás en un rol de gestión de producto, y revisemos las diferentes capas de interacción que existen para definir qué camino seguir.

1. Decir

Tú tomas la decisión por otros y quizás expliques tu motivación a los demás. Una discusión al respecto no es deseada ni asumida.

Ejemplos:

• Definir el objetivo de una funcionalidad
• Definir el KPI de una funcionalidad
• Decir cuáles son las prioridades

Viéndolo desde una perspectiva del liderazgo, tambien pueden ser decisiones como cuáles serán los objetivos que le pediré a mi equipo o el perfil de una persona de mi equipo.

Estas son cosas que el PM informa o avisa al equipo. Estas son decisiones que son parte de tu descripción de cargo y que el resto asume como propias de tu trabajo. No hay muchas preguntas porque a nadie le corresponde opinar ni fú ni fa.

Personalmente, donde más ejerzo el poder de “Decir” es diciendo que no. ¿Hagamos una nueva feature? ¿Por qué no estamos haciendo esto? ¿Y si cambiamos esto otro? No, porque hay prioridades que defino yo.

2. Vender

Tú tomas una decisión por otros pero tratas de convencerlos de que tomaste la decisión correcta, y luego los ayudas a sentirse involucrados.

Esto lo veo cuando quiero llevar a acabo algún proyecto de área y tengo que buscar aliados en otros equipos o cuando quiero que alguna tarea se lleve a cabo de alguna forma particular, debo vender el porqué, los beneficios y lo que ganamos haciéndolo de esta forma. De esta menera genero compromiso y acuerdo.

La venta es la antesala de la negociación.

Ejemplos:

• Definición de OKRs de mi área
• Definición de la estrategia del producto

3. Consultar

Preguntas por inputs primero, los que tomas en consideración antes de tomar una decisión que respeta la opinión de los otros.

Ejemplos:

• Definición de la visión del producto
• Roadmap de desarrollo del producto
• Prioridades del backlog
• Criterios de aceptación de historias de usuario
• Prioridades de otras áreas que impactan al equipo de desarrollo

Las dinámicas más literales de la consulta es cuando me reuno con otras áreas para absorver más detalles que me permitan tomar una decisión. Lo mismo hago con reuniones constantes con mi jefe, que me guía a considerar variables ajenas a mi rol para desarrollar proyectos a futuro.

La definición del backlog es responsabilidad de una Product Owner, pero con el tiempo he ido incorporando a más personas estilo “comité” para poder llegar a una decisión final de las prioridades, como el Scrum Master, el CEO, Líder de Ventas y el CTO de la compañía. Así mismo, el backlog se llena con prioridades de otras áreas, no sólo del producto, que también son conversadas con los stakeholders.

4. Consensuar

Discutes con todos los involucrados y, como grupo, alcanzas un consenso sobre la decisión.

Ejemplos:

• Refinamientos de historias de usuario
• Planes de campañas con otras áreas
• Retrospectivas
• Talleres y procesos de Design sprints
• Definición de OKRs de la empresa

Esta es la meca de la co-creación y la colaboración. Todos los actores están involucrados, y todos pesan lo mismo en sus opiniones.

5. Asesorar

Tu ofrecerás tu opinión y esperarás que escuchen tus sabias palabras, pero será decisión del resto, no tuya.

Como área de Producto nos ha tocado liderar procesos de investigación con donde mi rol como líder es de “guía experta”. Comparto mi visión con el equipo a cargo, espero que la escuchen, pero las responsables de la investigación son las personas haciendo el trabajo. El cómo la desarrollan y la comunican, es decisión de ellas.

6. Supervisar

Primero le dejas a los otros la decisión, y después les pides que te convenzan de su sabia decisión.

Dentro de mi equipo tuvimos que comprar una plataforma de medición de uso del producto. Yo no la iba a usar, pero quien sí la iba a usar la eligió, de una lista que le pedí que cotizara. Yo pedí que se justificara el precio y por qué teníamos que ir por esa herramienta y no otra, pero la decisión no fue mia. Yo supervicé que estuviera dentro de nuestro presupuesto.

7. Delegar

Les dejas la decisión a ellos y tú ni siquiera quieres saber los detalles que sólo saturarán tu cerebro.

Esto es el ejemplo de la confianza que puedes depositar en un equipo o en otra persona. Crees que esa persona está completamente capacitada para tomar la decisión, incluso mejor que tú, ya sea por conocimiento, tiempo o relevancia de la tarea.

Hoy mi equipo directo funciona con tareas delegadas que levantan elles mismes. Yo ya no reviso las pautas de testeos, a no ser que ellos quieran mi opinión. Me informan de decisiones que toman en otras conversaciones de equipo y estamos trabajando en que cada rol pueda movilizar sus propios proyectos.

Yo pienso que muchas veces el equipo de Delivery y Discovery tiene más fuerza que una Product Owner o una PM. Hay decisiones que escapan más allá del rol, si consideramos que el fin último es que las historias cumplan su propio objetivo. Si el botón está a la derecha o a la izquierda no es algo de lo que me pueda preocupar considerando que hay entre 2 y 7 expertos conversando y discutiendo para llegar a esa definición.

Ejemplos:

• Criterios de aceptación que van más allá de mi experticia
• Todos los niveles de desarrollo técnico del producto
• Cómo se construye una funcionalidad
• Quiénes participan de un tests de usuario

Estos 7 niveles se han hecho más claros en la medida que hemos madurado como equipo y como empresa, y después de un tiempo se han vuelto naturales en en las dinámicas de la organización.

Beneficios

La escala es una excelente guía para todas las personas que sufren delegando tareas. Permite visualizar qué cosas son muy importantes y otras que pueden ser tomadas en su totalidad por otra persona o un equipo.

No hay un nivel mejor que otro. Son alternativas de toma de decisión que sirven mejor dependiendo de la ocasión. Esto te permite navegar el día a día con distintas herramientas, si es que sabes a lo que te enfrentas.

Y lo más importante ¡no son exclusivas del rol de gestión! Todos, en cualquier cargo, ejercemos esta escala de delegación. Appelo dice: “Los siete niveles de delegación pueden ser usados para definir cómo el proceso de toma de decisiones es delegada de un manager a un individuo o un equipo, de un equipo o individuo a un manager y entre individuos o equipos entre pares” — Appelo, Managing for Happiness.