Preguntas de entrevista para Product Owners – Parte 1

De acuerdo a la Guía de Scrum, el Product Owner es el responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar ampliamente entre distintas organizaciones, Equipos Scrum e individuos. El Product Owner es la única persona responsable de gestionar el Product Backlog.

A continuación se dan a conocer algunas preguntas junto a sus posibles respuestas que podrian ayudar a seleccionar al candidato adecuado para que asuma el rol de Product Owner.

La segunda parte se encuentra publicada en el siguiente enlace Preguntas de entrevista para Product Owners – Parte 2

El siguiente contenido es una adaptación, traducida al castellano, del artículo 42 Scrum Product Owner Interview Questions to Avoid Agile Imposters y se la realizó con la finalidad de difundir y comprender las responsabilidad del rol del Product Owner.

Ante todo, ¿Cuál es el propósito de ser ágil?

Como se indica en el Manifiesto por el Desarrollo Ágil de Software, ser ágil se trata principalmente de priorizar la adaptabilidad en lugar de seguir un plan. O, parafraseando a Peter Drucker: se trata más de “hacer las cosas correctas” y menos de “hacer las cosas correctamente”. En consecuencia, con respecto al desarrollo de productos, ágil se trata de: posponer la decisión de invertir en un producto hasta el último momento económicamente factible. Esto se logra probando hipótesis de la manera más rápida y económica posible, mitigando así el riesgo y maximizando el valor del producto y el trabajo del equipo de desarrollo. Ser ágil significa tener el coraje de detenerse cuando el camino elegido ya no es viable.

El rol del Product Owner tambien es conocido como el “cuello de botella” y el “talón de Aquiles” de Scrum; si el candidato menciona esto, puede considerarse como un plus. Sin embargo, si el candidato enfatiza la tarea de crear historias de usuarios: pregúntele más y vea si se amplía su perspectiva.

¿Cómo caracterizarías el rol del Product Owner? ¿Serías un facilitador, un coach, un manager, un visionario, alguien táctico, un coordinador o un conductor?

Con esta pregunta, se intenta comprender mejor cómo el candidato percibe el rol del Product Owner. A pesar de la falta de autoridad gerencial en el sentido tradicional, el rol del Product Owner es un rol de liderazgo. En consecuencia, todas las caracterizaciones sugeridas por esta pregunta son aplicables al Product Owner.

El rol del Product Owner tambien es conocido como el “cuello de botella” y el “talón de Aquiles” de Scrum; si el candidato menciona esto, puede considerarse como un plus. Sin embargo, si el candidato enfatiza la tarea de crear historias de usuarios: pregúntele más y vea si se amplía su perspectiva.

¿Hasta qué punto, el Product Owner es un Product Manager?

Existe una línea muy delgada entre un Product Manager y un Product Owner, y la diferencia depende de cómo cada rol se haya cristalizado dentro de la estructura y cultura de una organización. Por lo general, independientemente de las tareas de Product Management, el Product Ownership implica establecer la visión y la estrategia del producto, su alineación con las metas y objetivos de la organización y gestionar a todos los Stakeholders internos y externos durante todo el proceso.

Lee más sobre las diferencias entre Product Owners y Product Manager en la publicación de Roman Pichler Product Owner = Product Manager?

¿Cuándo fue la última vez que le dijo “No” a un Stakeholder? ¿Cómo se abordó la situación? ¿Cuál fue la razón para decir “No”?

La autoridad para decir “No” es un empoderamiento necesario que deben tener los Product Owners, y la capacidad del candidato para usarlo es una calificación esencial. Decir “No” es necesario, por ejemplo, para proteger al Equipo Scrum de los proyectos de dudoso valor de los Stakeholders. También es útil para poner fin al pensamiento de silo y la optimización local dentro de una organización.

Los Product Owners crean valor no solo enviando el producto correcto, sino también maximizando deliberadamente la cantidad de “trabajo no realizado”. Una organización necesita respetar un “No” de los Product Owners. Si se ignora o se anula el “No” del Product Owner, no podrá cumplir la función de: maximizar el valor del producto en toda la organización. La aplicación de “Scrum” sin un Product Owner empoderado, de hecho, crea una especie de proceso “Waterfall 2.0”, ya que favorece la ejecución de un plan en lugar de la adaptación al cambio.

En última instancia, el nivel de control o influencia del Product Owner sobre el trabajo atrasado del producto actúa como una prueba decisiva de la adopción de principios ágiles por parte de la organización. Si el propietario del producto no puede decir “No”, no tiene control y la organización no puede ser ágil.

El Product Backlog se encuentra controlado por un “comité de producto” que se reúne periódicamente para aprobar nuevos Features. ¿Se puede actuar como un Product Owner creíble si no se tiene control sobre el Product Backlog?

Si un comité, consejo o cualquier miembro de la gerencia, que no sea el Product Owner, ejerce control sobre el Product Backlog, el Product Owner se convierte solo en un Proxy. Probablemente, el Product Owner en este caso es más un Product Manager que ha pasado a trabajar con un equipo ágil que emplea un subconjunto de Scrum. Puede funcionar bien si está alineado con la naturaleza de la organización, su cultura y el producto, pero no puede llamarse “Scrum”.

¿Qué títulos le parecen más adecuados para su tarjeta de presentación cuando piensa en su rol como Product Owner?

Los buenos títulos incluyen o deberían ser similares a: CEO de Producto, Emprendedor o Intraemprendedor, Innovador, Visionario de Producto, Líder Servicial, Single Wringable Neck, Strategic Thinker, Systems Thinker.

¿Cómo el Product Owner coopera con el Equipo Scrum?

El Product Owner debe cooperar con el Equipo Scrum desde temprano, frecuentemente, y de manera respetuosa y transparente. El Product Owner debe estar disponible para el Equipo Scrum de forma regular y responder a las consultas de los miembros con la rapidez adecuada.

¿Considerar que Scrum aborda adecuadamente el proceso de Product Discovery?

Design Thinking, Lean Startup, Lean UX y Service Design son metodologías ágiles mucho más adecuadas para el Product Discovery que Scrum. Scrum define al Product Owner como el único guardián del Product Backlog: la única persona que sabe lo que es más valioso en un momento dado. Scrum no explica cómo el Product Owner obtiene esta información.

¿Cómo se puede aprender sobre nuevas ideas y requisitos?

Para responder a esta pregunta, el candidato debe describir su proceso ideal de Product Discovery, desde la idea pasando por la hipótesis y la experimentación hasta la validación (preferiblemente).

Hay varias formas de proponer ideas de productos. Los enfoques comunes incluyen el análisis de las necesidades del mercado, las tendencias de la industria, nuestros propios datos (por ejemplo, análisis, NPS) y lo que está haciendo la competencia. Las sesiones regulares de lluvia de ideas entre los Stakeholders (por ejemplo, de ventas o atención al cliente) y el Equipo Scrum tienden a ser fructíferas. Permitir que los miembros del Equipo Scrum pasen parte de su tiempo en nuevas ideas es una práctica poderosa. Observar a los clientes mediante la realización de pruebas de usuario continuas es otro enfoque eficaz.

¿Cómo se puede incluir el User Research en el proceso de Product Discovery?

El User Research, o mejor, las pruebas de usuarios, debería ser un ejercicio continuo en cualquier organización impulsada por productos. Es una parte vital del ciclo de creación, prueba y aprendizaje de ágil. Prácticamente, esto significa que la comunicación con los Diseñadores e Investigadores de UX es una parte integral de lo que hacen el Product Owner y el Equipo Scrum (idealmente, los Diseñadores e Investigadores de UX son parte del equipo); y que el Product Owner debe recopilar continuamente el feedback de los clientes realizando entrevistas frecuentes con los usuarios y observando el uso del producto.

Estos enfoques para las pruebas de usuarios también se aplican a proyectos técnicos, como las API.

¿Cuánto tiempo se asignaría al User Research y a comprender las necesidades de los clientes?

Si el candidato dice que dedica el 50% de su tiempo al User Research, ¡genial! Sin embargo, si el Product Owner pasaría menos del 10% de su tiempo en el User Research, y si nadie más manejara el Product Discovery en representación del Product Owner, entonces el proceso de Product Discovery debe mejorarse. Una forma de lograr esto sería relevando al Product Owner de tareas administrativas como la escritura de historias de usuario (un Product Owner no es necesariamente el autor de las historias de usuario).

¿Cómo sería el proceso para manejar las ideas de productos de los Stakeholders y de la organización en general?

Por lo general, es una buena idea tener un proceso que involucre activamente a los Stakeholders y a los miembros de la organización en el Product Discovery. A la gente le gusta tener un propósito y ser parte de algo más grande que ellos. Brindar a todos en la organización la oportunidad de contribuir, sin importar el rango, facilita el trabajo como Product Owner. Tal proceso no requiere tecnología sofisticada: una simple hoja de cálculo o formulario compartido es suficiente para comenzar.

Inicialmente, una plantilla para sugerir nuevos Features del producto podría consistir en preguntas que aborden el Por qué, el Cómo, el Qué y el Para quién. Podría abordar la naturaleza táctica o estratégica de la sugerencia, un posible periodo de tiempo o una estimación del rendimiento esperado de la inversión.

Lo más importante es que el diseño de un proceso para manejar las ideas de productos debe mantenerse ágil: el proceso debe comenzar con una solución simple y luego mejorarse una vez que se hayan analizado el feedback inicial de los Stakeholders sobre el proceso.

¿En qué etapa se involucraría al Equipo Scrum en el proceso de Product Discovery?

Se debe involucrar a un Equipo Scrum lo mas antes posible en el proceso de Product Discovery. Existen principalmente tres razones para hacerlo:

  1. Cuanto más antes participen los ingenieros en el proceso de Product Discovery, menores serán las posibilidades de buscar soluciones que técnicamente no sean viables o que no den como resultado un retorno de la inversión.
  2. Involucrar a un Equipo Scrum desde el principio asegura que el equipo y el Product Owner desarrollen un entendimiento compartido y apropiación de lo que se construirá. Esto ayuda significativamente con la asignación de recursos a los problemas correctos, maximizando el valor para el cliente y mitigando el riesgo de inversión.
  3. Involucrar a los ingenieros de un Equipo Scrum al principio del proceso garantiza su compra y la disposición del equipo a participar en todas las fases del desarrollo de un producto. Esto motiva al equipo a participar cuando se realicen cambios necesarios para lograr los objetivos definidos para cada Sprint o Release de producto.

¿Cómo se evitaría la asignación incorrecta de recursos a Features o productos en los que nadie está realmente interesado?

Los Product Owners pueden evitar la asignación incorrecta de recursos al tomar una decisión firme en el momento en que quede claro que un producto o Feature no es valioso o no es factible. Esto significa que es necesario establecer un proceso de monitoreo continuo, por ejemplo a través de pruebas de usuario regulares. Una vez que el ciclo ágil de buildtestlearn demuestra que una idea o producto es poco probable que tenga éxito, la asignación de recursos debe detenerse.

Los Product Owners no deben permitir que la falacia del costo hundido enturbie su juicio. No importa cuánto se haya gastado, los gastos pasados no justifican el trabajo continuo en un producto que probablemente no tenga éxito.

Su organización recientemente ha decidido “ser ágil” en el desarrollo de productos. ¿Cómo se educaría a los Stakeholders sobre las implicaciones?

Un buen punto de partida para educar a los Stakeholders sobre las implicaciones de volverse ágil sería organizar un seminario de capacitación que explique la mejor manera de aplicar los cuatro principios del Manifiesto por el desarrollo Ágil de software. El Product Owner debe asegurarse de que los Stakeholders reconozcan que “adaptarse al cambio frente a seguir un plan” es fundamental para el éxito de la organización.

Los Stakeholders deben comprender que, una vez que se vuelven ágiles, la emisión de “requisitos” (y, por lo tanto, esfuerzos de optimización localizados) ya no son una forma válida del proceso de entrega del producto. En cambio, el descubrimiento y desarrollo iterativo del producto se convierte en el principio rector, elevando el experimento y el fracaso a las prácticas estándar.

Ser ágil significa competir con otras ideas de productos (probablemente más valiosas) por recursos escasos, y aceptar que el Product Owner es el único responsable del Product Backlog. Significa que no hay más fechas de entrega, sino intervalos de entrega establecidos por la organización de la entrega del producto, y los Equipos de Scrum individuales en particular, de acuerdo con el conocimiento que tenga la organización en ese momento. Significa tener en cuenta que lo que se sabe puede cambiar en cualquier momento y que estos cambios probablemente afectarán los intervalos de entrega.

Los Stakeholders deben comprender la magnitud de abandonar un estilo de gestión de comando y control, y lo que significa empoderar a los equipos autónomos y autoorganizados para la entrega del producto, antes de comprometerse a ser ágiles. Es responsabilidad del Product Owner educarlos.

¿Cómo se organizaría la colaboración entre un Equipo Scrum con los Stakeholders -y mejorarla con el tiempo?

Hay varias formas de establecer y mejorar la colaboración de un Equipo Scrum con los Stakeholders a lo largo del tiempo:

  • El Product Owner podría establecer reuniones periódicas con cada Stakeholder, o hacer que los Stakeholders nombren embajadores del producto que luego actúen como “oficiales de enlace” después de haber sido capacitados adecuadamente en los procesos ágiles del equipo.
  • Los talleres podrían organizarse con los Stakeholders o sus embajadores, idealmente con la ayuda del Scrum Master o el Coach ágil. Un buen enfoque es asociarse con expertos en experiencia del usuario (UX) para llevar a cabo, por ejemplo, talleres de: user journey ó user story mapping.
  • Se podría invitar a los Stakeholders a sesiones de refinamiento para explicar el valor de una historia de usuario al Equipo Scrum.

Los Sprint Reviews y demos, los Release demos y las entrevistas a usuarios también son buenas ocasiones para mejorar la colaboración entre el Equipo Scrum y los Stakeholders. En la búsqueda de la colaboración, la comunicación y la transparencia son clave.

¿Cómo se negociaría con los Stakeholders que no cooperan?

Una forma a menudo exitosa de tratar con los Stakeholders que no cooperan es atraerlos demostrandoles el valor del desarrollo ágil de productos.

Al principio de la transición a ágil, aconsejamos educar a los Stakeholders sobre principios ágiles con talleres relacionados con productos. Los buenos ejemplos de los temas en los que estos talleres podrían enfocarse incluyen: user story mapping y product roadmap planning. Recomendamos obtener la ayuda de un Coach ágil experimentado en esta etapa.

Resulta útil establecer un cronograma para comunicar el progreso con los Stakeholders. Una buena manera de hacerlo es mediante reuniones periódicas. Además, educar a los miembros de los equipos de los Stakeholders para que actúen como “oficiales de enlace” mejora significativamente la cooperación al mitigar el sentimiento muy normal de los Stakeholders de perder el control.

En una etapa posterior en la transición a ágil, las ceremonias típicas como Sprint o Release demos también funcionan bien para demostrar el valor entregado.

Atraer a los Stakeholders que no cooperan es un proceso que llevará tiempo. No hay atajos. Si todo lo demás falla, el Product Owner debe buscar el apoyo de un patrocinador de nivel C.

Lee más sobre la comunicación con los Stakeholders en 10 Proven Stakeholder Communication Tactics during an Agile Transition.

Un nuevo Feature está demorado y se ha subestimado drásticamente debido a una deuda técnica inesperada. Sin embargo, su Stakeholder más importante insiste en “terminarlo” porque ya se ha invertido mucho esfuerzo. Cómo se trataría esto?

Unirse a los principios ágiles requiere “adaptarse al cambio antes de seguir un plan”. Si un proyecto está atrasado, es posible que ya haya perdido su valor original para la organización y sus clientes. Es necesario reevaluar el valor del proyecto antes de dedicarle más recursos. Si el proyecto aún ofrece valor, el Product Owner y su equipo probablemente deberían hacerlo – teniendo en cuenta, sin embargo, que otras oportunidades de inversión en el Product Backlog competirán por su atención.

Los Stakeholders que insisten en “terminarlo” debido a la inversión previa han caído en la falacia de los costos hundidos. Los Product Owners nunca deberían hacerlo.

¿Cómo se actuaría con los proyectos favoritos?

Los Product Owners deben enviar los proyectos favoritos de los Stakeholders al proceso estandarizado que cada idea de producto debe seguir. La actualización continua del caso de negocios para cada uno de estos proyectos los obliga a competir con proyectos más valiosos. Tarde o temprano, el sentido común termina con una mala asignación de recursos, ya que los proyectos favoritos rara vez proporcionan un retorno de la inversión.

Para aquellos Product Owners que tengan que tratar con proyectos favoritos, los Stakeholders con proyectos más valiosos son buenos aliados en este conflicto.

El departamento de ventas a menudo compromete nuevos Features para cerrar tratos sin hablar primero con el Product Owner. ¿Cómo se actuaría ante esto?

Si el departamento de ventas está comprometiendo nuevos Features sin hablar con el equipo de desarrollo de productos, su actitud probablemente sea alentada por la gerencia para alcanzar los objetivos de ventas. Refleja una mentalidad no ágil y oportunista que valora la gratificación instantánea (más ventas) sobre una estrategia de desarrollo de producto sostenible. Para cambiar esta mentalidad, ayuda el comunicarse con el departamento de ventas y ofrecerles soporte en el aspecto técnico del proceso de ventas lo antes posible. Sin embargo, dados los incentivos habituales para el equipo de ventas, un cambio real solo sucederá si la gerencia acepta los principios de desarrollo de productos ágiles.

Leave a Reply

Your email address will not be published. Required fields are marked *