A los Product Owner y Product Managers se nos acusa de no decir «no» lo suficiente.

Es verdad.

Ni los mejores dicen que no tanto como debieran.  

En el día a día, el Product Owner recibe peticiones de stakeholders, clientes, usuarios, ideas del propio Equipo, etc., y atenderlas todas es, sencillamente, imposible. El Product Owner puede y debe rechazar todas aquellas que no casen con nuestros objetivos (véase, Product Goal & Sprint Goal).

¿Por qué no decimos que no? Las razones son variopintas, listo aquí algunas de las más frecuentes:

• Porque no tenemos objetivos bien definidos, es decir, no tenemos las prioridades claras.
• Porque es más fácil que nos digan lo que hay que hacer, en lugar de tener nuestro propio plan.
• Porque queremos ser buena gente y quedar bien con todo el mundo.
• Porque el jefazo de turno nos intimida y es más fácil decirle que sí.
• Porque es algo rápido (“quick win”) y lo metemos en el Sprint y ya está, sin darnos cuenta de otros daños colaterales.
• Porque teníamos información limitada o estábamos inmersos en una situación de estrés, y simplemente tomamos la decisión equivocada. 
• Etc.

El problema es que, cada vez que decimos sí a algo, hay otro algo que no sucede, o que sucede más tarde. Lo más probable es que las prioridades estratégicas que de verdad nos importan se demoren, porque peticiones de diversa índole, a las que el Produt Owner debería haberse opuesto, se terminan “comiendo” la capacidad del Equipo en el día a día.

No caigas en la trampa.

Decir que no de la manera adecuada tiene un efecto pedagógico. No se trata de ser dictatorial ni menos aun de querer llevar la razón a toda costa; se trata de explicar las cosas, de comunicar con empatía el producto que el Product Owner tiene en la cabeza (o, con suerte, en el Product Backlog).

Ideas para decir que “no” de forma elegante

Se trata de ser transparentes respecto a las decisiones que tomamos.

Por supuesto, la manera de decir que no y el cuanto debamos fajarnos para ello depende del contexto especifico en el que nos encontremos.

Veamos algunos ejemplos que quizás puedan servirte de inspiración, en especial para declinar propuestas procedentes de stakeholders.

• Rechazar peticiones que no contribuyen al Product Goal (o, si queremos ser más tácticos, Sprint Goal): «Lo siento, pero esta petición no nos ayudará a conseguir el Product Goal X en el que estamos trabajando, así que por el momento no vamos a poder hacer nada. Recuérdamelo por favor en unos meses y quizás podamos reconsiderarlo».

• Explicar por qué la idea es incompatible con la dirección estratégica que se está dando al producto: «Gracias por tu aportación, pero me temo que esta idea no encaja con la estrategia de producto actual, porque la visión es permitir que los usuarios puedan hacer X, y no Z, dado que así …».

• Exponer por qué la petición no será atendida, cuando ya hay evidencias en sentido opuesto. «Gracias por tu aportación. Esa era nuestra idea inicial, pero resulta que los usuarios quieren hacer X y no Y, es algo que hemos aprendido recientemente; aquí te dejo un gráfico con los datos de uso».

• Si la petición de verdad tiene sentido, pero la tienes que madurar: «Que interesante, lo añado al Product Backlog para que lo estudiemos, aunque seguramente no podamos abordarlo en los próximos Sprints. Te mantengo al tanto”. Esta respuesta realmente es una especie de sí en diferido que te compromete. Su único beneficio es que te “compra tiempo”; sin embargo, te da trabajo: el stakeholder te preguntará en unas semanas (o, con suerte, puede que se olvide), o tú querrás ser profesional y tenerle informado. Además, tendrás otro elemento en el Product Backlog, añadiendo más ruido (menos transparencia) a este.

• Mejor que la anterior, con total honestidad: «Interesante pero no lo tengo claro en este momento, y ahora mismo estamos enfocados en X y no puedo pararme a pensarlo bien. Recuérdamelo por favor en unas semanas».

• Si la petición tiene sentido, pero quieres más detalles: «Veámoslo en una reunión, creo que va a ser difícil que lo prioricemos en este momento, pero me gustaría entender bien el problema». En este caso, lo que buscas es entablar un diálogo constructivo con el stakeholder, más que dar un sí o un no inmediatos.

• Ofrecer alternativas, cuando la petición debe abordarse, aunque no en la forma que el stakeholder sugiere: «Hacer X seguramente implique un gran esfuerzo y no pienso que vaya a ser efectivo, de acuerdo con los datos pasados. Como solución de compromiso podríamos hacer Z. ¿Qué te parece?»

Como todo en esta vida, decir que no también es cuestión de práctica. Espero que estas ideas te sirvan de ayuda.

¿Cuáles son tus formas favoritas de decir que no?

Importante

Conviene ser firme y dar un mensaje claro, a la vez que ser explicativo y empático. El stakeholder puede estar lidiando con un verdadero problema que tú, por razones sensatas, no puedes priorizar en este momento, por lo que hacerle sentirse escuchado o valorado es lo mínimo que puedes hacer. Puede que ese problema incluso determine futuros Product Goals.

No olvidemos que los stakeholders son una fuente de ideas y feedback indispensable, luego crear transparencia en torno a nuestras decisiones como Product Owner será necesario ganarnos su confianza, mantener una estrecha relación y, en última instancia, conseguir llevar el producto a buen puerto.