• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Estrategia

¿Cooperar o competir en un mundo digital?

Mi empresa actual no es la primera en la que soy propietario u ostento una participación significativa. Durante los últimos doce años he creado varias, de las cuales esta ha sido la más exitosa. Algunas incluso las he vendido a otros competidores del mercado.

Cooperar o Competir, ese es el dilema

Uno de los aspectos que siempre me ha parecido más interesante del mundo empresarial es el de colaborar o competir con otras empresas que, en principio, son competidores nuestros.

Probablemente el primer impulso cuando tratamos con un competidor sea el de evitar colaborar. ¿Por qué querría colaborar con alguien que puede quitarme lo mío? Detrás de este pensamiento a priori lógico se encuentra un dilema bastante más amplio de lo que pensamos.

Imaginemos que estamos ante una oportunidad empresarial enorme a la que concurrimos en competencia con otra compañía a la que conocemos bien. Si colaboramos para conseguirla, ambos ganamos. Si nosotros intentamos colaborar pero nuestro competidor se aprovecha de esa posición, entonces perdemos. Si nuestro competidor intenta colaborar pero nosotros nos aprovechamos, entonces ganamos. Si ambos intentamos aprovecharnos el uno del otro, entonces ambos perdemos.

Esta es una adaptación del dilema del prisionero y parte de la teoría de juegosfruto del trabajo de John Nash, que fue ilustrada en la película Una mente maravillosa.

El contexto es clave

En el caso del dilema del prisionero, el contexto es clave. No es lo mismo un contexto de suma cero, donde si uno gana otro pierde, que un contexto más rico donde si perdemos, tenemos otra oportunidad. Los entornos empresariales modernos son del segundo tipo, lo cual permite adaptar nuestra estrategia a la de los competidores.

Volviendo al ejemplo anterior, si en una oportunidad posterior nos volvemos a encontrar con el mismo competidor, entonces podemos decidir colaborar o no dependiendo de lo que este haya hecho la vez anterior. En general podemos optar siempre por una estrategia (colaborar o competir) o adaptar nuestra estrategia en función de lo que haga nuestro competidor. Por último, podemos actuar aleatoriamente, o dejándonos llevar por otros factores.

¿Y que hay de la falta de comunicación?

Imagina que en el ejemplo, nuestro competidor se aprovecha de nosotros pero es a causa de un error de comunicación. ¿Deberíamos de darle otra oportunidad? ¿Y si no sabemos que ha sido a causa de un problema de comunicación?

En ese caso, podríamos incorporar una regla a nuestra estrategia que nos indicara si debemos dar una segunda o una tercera oportunidad cuando pensamos que nuestra falta de colaboración se debe a un error de comunicación.

Adoptando heurísticos

La clave es adoptar una posición fija ante cierto tipo de situaciones. Un marco de decisión que nos facilite el tomar decisiones sin tener que hacerlo una por una. En nuestra vida real lo hacemos continuamente, están estudiadas y se llaman heurísticos. El problema es que no siempre somos conscientes de ellas y de las consecuencias de las mismas.

Daniel Kahnehman lo describe en su libro thinking fast and slow. El problema de los humanos es que tenemos un cerebro primitivo, mucho más viejo evolutivamente hablando, y un cerebro moderno, que es capaz de tomar decisiones infiriendo información. Eso hace, por ejemplo, que nos sintamos en ocasiones tristes, o amenazados, sin saber por qué. Nuestro cerebro más viejo toma el control para protegernos de peligros que identificamos como amenazantes aunque realmente no lo sean.

¿Entonces que debo hacer? ¿Colaborar o competir?

La regla de oro es: trata a otro como deseas ser tratado. El problema es que el mundo es injusto y en ocasiones poner la otra mejilla no es fácil. ¿Quieres simularlo? Los chicos de NCASE han desarrollado un simulador de confianza que permite ver cuales son las estrategias más óptimas desde todos los parámetros que hemos visto.

Tener conocimiento de esto permite desarrollar una estrategia de toma de decisiones rápida sobre colaborar o competir. Solamente este mes me he encontrado ante 3 de estas situaciones. Este marco me ha ayudado a tomar una decisión rápida y coherente a lo largo del tiempo.

Las 5 diferencias entre un product owner y un product manager

Trabajando en entornos ágiles con cierta envergadura, es normal encontrarse con dos figuras que, a través de la relación sobre el producto, en ocasiones tienen conflictos en cuanto a la definición de sus roles y sus tareas. Estos son el Product Manager y el Product Owner.

El Product Owner, en entornos que usan Scrum, es el último responsable del Product Backlog, de los ítems que contiene y del éxito del desarrollo del producto. Además, puede gestionar el presupuesto específico del producto -y lo hace en entornos que no tienen un Product Manager- y la cuenta de resultados del producto.

El Product Manager, en función del enfoque se utilice, es el encargado de manejar la parte de negocio de producto. Entre sus responsabilidades están la de manejar los KPIs, reportes, cuentas de resultados y responsabilidad sobre el resultado final. En el caso de organizaciones que usan SAFe, es la persona a quien otros Product Owners en la organización reportan. ¿Fácil, no?

product owner product manager

Alto, porque hay que considerar más cosas en esta lucha de titanes. En primer lugar, está la estrategia de producto, en la cual hay que tomar decisiones importantes sobre como acercarse al mercado o encontrar financiación. En el otro está la táctica del mismo, y esta no es implementar el Product Backlog -gran error-, sino acercarse a los detalles del lanzamiento o actualización del mismo, canalización y otros. Estrategias de comercialización. Publicidad.

La gestión y desarrollo de Producto en Scrum, caen más del lado de la estrategia que de la táctica. Es aquí donde comienza la indefinición expuesta en la imagen de arriba. Cuestiones como la realización de historias épicas, definición de requerimientos tienen que considerar una parte previa de análisis del mercado y estrategia competitiva. Aunque también tienen una parte táctica. ¿Menos fácil?.

Si el equipo usa Scrum, debe tener un sólo Product Owner que trabaje con ellos. Él o ella tienen la última palabra sobre el Product BacklogLa parte táctica -sprint a sprint- es en que el Product Owner tiene que estar inmerso para asegurar el éxito del Incremento al final del Sprint. Eso hace que estas dos figuras tiendan a chocar de nuevo. Veamos las 7 diferencias.

El Product Owner tiene la última palabra sobre el contenido del backlog

El Product Backlog es competencia exclusiva del Product Owner como miembro del equipo Scrum. Son él o ella los que se encargan de transferir la estrategia de producto a partir de una fragmentación adecuada del Product Backlog.

En algunas organizaciones no es así. El Product Owner es solamente un títere del Product Manager sin posibilidad de decisión. Esto provoca una gran ineficiencia en el equipo Scrum. Cuando necesitas respuestas, sólo tienen a un minion que no puede hacer nada.

El Product Manager tiene responsabilidad ejecutiva sobre los resultados del Producto

Cuando los dos conviven en un entorno corporativo, es normal que el Product Manager sea quien tiene responsabilidad ejecutiva sobre el producto. Esto crea un problema en equipos que usan Scrum, debido al primer punto.

Un Product Owner que trabaja con varios Product Managers es normal en empresas pequeñas. En empresas grandes, es normal tener un VP de ProductoLa manera de solucionarlo es aceptar por parte del Product Manager que tiene que dar la cara pero no puede ejecutar la responsabilidad, lo cual es perfectamente normal. Una buena idea es utilizar una matriz RACI+F para solucionar este asunto. Quien es el responsable, da la cara, es consultado, informado o facilita cada proceso.

Las responsabilidades del Product Owner forman parte del espectro de las del Product Manager

Scrum se centra en el Product Owner como representante del negocio, quien tiene toda la información y la gestiona dentro del pequeño área que supone Product Ownership. El Product Management es normalmente mucho más amplio que sólo el Product Ownership. El PO puede cubrir esta parte, pero es importante diferenciarlo.

La colaboración es necesaria en este caso, para que la estrategia y la táctica en torno al producto están alineadas. No valen las medias tintas. El profesionalismo es lo que marca la diferencia en estos entornos.

El Product Owner es el emprededor, el Product Manager el ejecutor estratégico

En otras ocasiones, por ejemplo en el framework Nexus, el Product Owner posee el máximo nivel de propiedad sobre el producto, y los Product Managers se encargan de ejecutar pequeñas partes del producto trabajando en el día a día de los equipos y la estrategia a medio plazo.

Personalmente, creo que define bien, y es la opción con la que yo me identifico. El Product Owner tiene que ser responsable y estar disponible para la táctica y para la estrategia. Puede utilizar a un espectro de profesionales, desde un experto en SEO a UX para crear e implementar la estrategia.

Todo esto puede pasar a la vez

Hay organizaciones que pueden tener a un über Product Owner, que trabaja con distintos Product Managers que se encargan de varios Productos y que a la vez tienen product owners para cada uno de ellos. Los Product Owners trabajan con los equipos y a la vez con el metaequipo. Los product Manager aportan experiencia a cada uno de los productos. Y todo puede funcionar ágilmente


No existe una solución común. Los distintos frameworks han reflejado una realidad a través de distintos enfoques. Hacer producto es algo personal de cada organización y no puede extrapolarse exactamente a otra. Es labor de la organización averiguar cual es la mejor manera de trabajar. Siendo transparente, inspeccionando y adaptando.

Si tienes interés en profundizar más, hemos hecho un video con las claves de un Product Owner.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad