MENTALIDAD DE PROYECTO Y PRODUCTO

MENTALIDAD DE PROYECTO Y PRODUCTO

 ¿QUÉ ES MENTALIDAD DE PROYECTO?

Una mentalidad de proyecto es un enfoque para lograr ciertas actividades y propósitos en un período de tiempo determinado. Puede llevarse a cabo a través de una sólida colaboración entre los equipos para lograr el objetivo. Para muchas organizaciones, una mentalidad de proyecto significa contratar equipos para cumplir con los plazos, los presupuestos y otras limitaciones, para centrarse en un plan inicial y la tarea predeterminada. Un proyecto puede construirse eventualmente dentro de las restricciones establecidas, pero a menudo puede convertirse en un producto invaluable ya que el enfoque está orientado hacia la gestión de tareas, un elemento diferenciador central entre la gestión de proyectos y la gestión de productos.

La mentalidad del proyecto se centra en la planificación, la estimación, la entrega y el resultado. En este caso, los Product Owners y los líderes técnicos tienen la mentalidad de que saben lo que quieren y cómo lograrlo. De acuerdo con sus suposiciones, se planifica un proyecto con todos los hitos. El plan requiere ser ejecutado dentro de la misma organización o tercerizado. Eventualmente, el proyecto se pone en marcha para su ejecución.

Si la ejecución se subcontrata, la asignación se denomina proyecto. Los empleados (a quienes se asigna este proyecto) se preparan con una mentalidad de entrega. El equipo de organización de servicios construye el producto, que luego es ejecutado por las contrapartes del cliente. En este caso, el equipo de desarrollo desconoce los problemas que enfrenta el usuario final, que se supone que deben resolverse. No hay lugar para la iteración de seguimiento o la ideación de primera mano, ya que todo está controlado por el equipo técnico del cliente.

¿QUÉ ES MENTALIDAD DE PRODUCTO?

La mentalidad de producto permite hacer lanzamientos continuos del producto en desarrollo y así integrar la retroalimentación de clientes potenciales para realizar ajustes sobre la marcha, de manera que con ello se logra reducir la incertidumbre y dar prioridad a los aspectos más valiosos para clientes y usuarios. En palabras simples la mentalidad de producto se refiere a la idea de extraer información sobre lo que los clientes quieren de un producto sin que ellos lo digan directa o exactamente, y eventualmente desarrollen un producto con el que estén satisfechos.

Por otra parte, la mentalidad de producto ve al equipo de desarrollo como un equipo de consultores para el desarrollo del producto, de manera que convierte el cliente y el equipo en socios. Product Mindset (Mentalidad de producto) es una forma de abordar los servicios que implica un importante valor añadido a los servicios prestados. Lo cual genera mayores satisfacciones a los clientes y se potencia notablemente el beneficio obtenido. En el caso de la industria de TI, el producto o productos del cliente son "adoptados" por la empresa que implementa tal mentalidad de producto y la participación de las empresas de software ya no se centra exclusivamente en la ejecución. De hecho, aparecen nuevos roles que duplican o, en ocasiones, incluso reemplazan a los que se incluyen naturalmente en las responsabilidades del cliente (como, por ejemplo, el rol de propietario del producto).

Si en caso se quisiese implementar la mentalidad de producto debemos considerar que con otras mentalidades el equipo no debe trabajar con especificaciones incompletas, ya que generalmente, el equipo espera que el cliente aclare todos los detalles relacionados con una función (o una historia de usuario) antes de comenzar su desarrollo. Para evitar desperdiciar esfuerzos en desarrollar y reescribir algunas partes de la aplicación dos o varias veces, el equipo del proyecto pospone el desarrollo de algunos elementos esenciales de la aplicación, enfocando su esfuerzo en un intercambio de correos electrónicos tipo "ping-pong" o reuniones de aclaración que pueden durar siempre, sin embargo, el enfoque del proyecto desde el uso de la mentalidad de producto implica la implementación de características que no han sido completamente especificadas por el cliente. Obviamente, esto significa conocer lo mejor posible el dominio comercial del cliente y al mismo tiempo implica un mayor grado de riesgo. Sin embargo, de esta manera, ya no se impide el desarrollo de características importantes, ya que el cliente ahora es mucho más capaz de identificar sus necesidades, teniendo un ejemplo ya implementado.

Un enfoque de mentalidad de producto ayuda a las colaboraciones duraderas entre las empresas orientadas a servicios y sus clientes, ya que estos últimos ven al equipo de desarrollo como parte de su propia organización, acreditándolo con confianza y respeto. Esta unión, sin embargo, puede resultar en un apego, a veces exagerado, de los miembros del equipo por el cliente y su(s) producto(s), algunos incluso considerándose empleados del cliente y no de la empresa de servicios de la que forman parte.

Un modelo de entrega centrado en el producto exige centrarse en los objetivos finales de una organización en lugar de los logros a corto plazo. Aquí los equipos dan más peso al resultado final y al proyecto que a factores como los plazos y los presupuestos. El objetivo es aumentar el ROI (Retorno de la inversión). Por lo tanto, las métricas de éxito de los principios de la mentalidad del producto giran en torno a la creación de una gran experiencia para el cliente, la creación de una hoja de ruta que garantice lanzamientos frecuentes y el enfoque en la creación del producto correcto. Las organizaciones se están dando cuenta cada vez más de los beneficios del producto sobre la mentalidad del proyecto.

PASOS PARA CONVERTIRSE EN UNA ORGANIZACIÓN CON MENTALIDAD DE PRODUCTO

Actualmente las empresas centradas en proyectos no pueden adaptarse a la incertidumbre, la flexibilidad y la velocidad necesarias para impulsar la innovación en productos, servicios y experiencias de los clientes en el dinámico mercado actual. Por lo tanto, el cambio para convertirse en una organización centrada en el producto debe centrarse en áreas.

1. SINERGIZAR LA ASOCIACIÓN DE NEGOCIOS Y TI

Principalmente identificamos los roles centrados en el producto en la empresa de desarrollo Agile: líder de capacidad, gerente de producto, entrenador Agile y arquitecto DevOps.

Los líderes de capacidad y los gerentes de producto generalmente provienen de líneas comerciales. El entrenador ágil y el arquitecto DevOps provienen de las líneas de TI. 

Reunir a los líderes de capacidad y gerentes de productos en la mesa de la empresa es el paso más importante para iniciar una colaboración continua.

2. FINANCIACIÓN ÁGIL DE PRODUCTOS

Una organización con una mentalidad de producto comienza a financiar productos de forma incremental e iterativa. Proporciona flexibilidad que permite la experimentación y permite que el equipo se adapte a los cambios en las prioridades comerciales. El equipo creado garantiza que la organización esté asignando fondos de manera responsable para dirigir la agilidad y la innovación para lograr los objetivos estratégicos.

En lugar de procesos de aprobación prolongados que alargan el tiempo de comercialización, que es una rutina en un enfoque centrado en proyectos, puede cambiar la financiación y equilibrar la capacidad entre iniciativas proporcionando visibilidad del rendimiento y conectando la estrategia con la entrega.

3. EL CAMBIO DE CENTRARSE EN LOS DATOS

En el mundo digital dinámico y en constante evolución actual, donde el uso de datos aumenta a diario, el papel del director de datos (CDO) debe ser cambiar su enfoque de los proyectos de análisis y datos a dirigir una organización centrada en el producto. Este nuevo CDO con el nuevo rol de adoptar la mentalidad de producto para una organización puede llamarse CDO 4.0, como lo recomienda el informe de investigación de Gartner.

CDO 1.0: El foco principal estaba en la gestión de datos

CDO 2.0: el enfoque principal estaba en el análisis

CDO 3.0: El foco principal estuvo en la transformación digital

El CDO 4.0 se enfoca en los productos, en la administración, las ganancias, las pérdidas en lugar de solo ser responsable de impulsar proyectos, programas de datos y análisis.

Para esta mentalidad es recomendable lo siguiente:

Enfoque en el usuario y su problema. Por lo general estamos acostumbrados a pensar en respuestas y soluciones, ya que esto es lo que aprendimos en la escuela, de manera que no se cuestiona la pregunta y simplemente se da la respuesta. En Product Management solucionar el problema equivocado cuesta tiempo, dinero y esfuerzo, es por eso que una de las mayores cualidades de un gran Product Manager es su habilidad para definir un problema. Por ejemplo, cuando se entrevista perfiles, nos deberíamos enfocar en entender el proceso mental que lleva la persona para definir un problema, en el proceso veremos que un parte de los postulantes platican más sobre las soluciones que implementaron, pero no del problema que trataban de resolver, de manera que eso no nos dice nada sobre si tuvieron éxito o no. Un problema se define con hipótesis basadas en datos duros, observaciones y retroalimentación de un usuario. Muchas veces un producto no funciona porque está mal definido, es decir las hipótesis no describen la realidad del usuario o no definen las barreras que crean el problema. Un Product Manager debe tener la capacidad de detectarlo para poder revisar y cambiar sus hipótesis. Debemos estar capacitados para identificar cuáles de las interpretaciones, ideas y aprendizajes son hipótesis y cuales sesgos de nuestro entorno influyen para crear esa idea, para bien y para mal.

Lo importante es el outcome no el entregable. En project management la medida del éxito son entregables listos en tiempo y forma. No es que esto sea malo, de hecho, ser un master de la ejecución lleva a una carrera muy fructífera, pero como Product Manager, lo más importante es el impacto de estos entregables, por lo que el entender el problema va de la mano con este aspecto, lo que determina si estamos teniendo éxito o no, es que tan poderoso es el outcome de nuestra solución, no que la solución exista como tal. El éxito lo vemos en indicadores y métricas no en cantidad de entregables.
Pensar en outcomes quiere decir enfocarse y mantener presente el ‘para qué’ estamos construyendo algo. Si tu equipo está enfocado en optimizar o crear una función, da un paso atrás, evalúa por qué no es definir y solucionar un problema. 

Accountability antes, después y durante la creación de productos. Accountability se refiere a ser tan dueños de las ideas, análisis y trabajo para crear un producto como de los resultados que obtenemos, con todo y los factores que no están en nuestro control. Es la única manera en la que podremos iterar de manera efectiva. Los Product Managers que han sido emprendedores entienden esto bien. Cuando eres el responsable principal del éxito o fracaso de una iniciativa tomas en cuenta todo lo que puedas para poder continuar mejorando tu producto y llevarlo a tener éxito. Lo opuesto a ser accountable es deslindarse, por ejemplo, culpando a otras áreas por omisiones o retrasos o a cambios en el mercado por algo que no vimos venir. Esas cosas pasan, sí, pero al final un gran Product Manager persevera y hace que las cosas correctas sucedan sin pretextos.

Iterar, seguir el método científico y personalizar tus procesos. ‘Falla rápido y falla de manera inteligente’ es una frase conocida en el medio de desarrollo de tecnología para incentivar avanzar rápido aprendiendo de nuestros errores. Hacer esta práctica parte de tu día a día, permite que el desarrollo de un producto sea incremental. Cada versión es un incremento, por lo que no trates de poner todo lo que te imagines en una sola versión. Elige incrementos que puedas probar si funcionan cómo imaginas y ve acumulando valor para el usuario, evita caer en patrones de desarrollo de cascada con tiempos de entrega larguísimos.

También, de manera personal, itera en la forma en la que llevas tu equipo. Elige la forma que más te funcione para llevar a cabo flujos de design thinking, lograr shared understanding con equipos multidisciplinarios y ejecutar metodologías agile.

Para más información consultar:

• ¿Scrum Master o Project Manager? 
• Product Mindset 
• Mentalidad de producto
• Product Mindset Over Project Mindset: Benefits and Roadmap

COMPARACIÓN DE LA MENTALIDAD DE PROYECTO Y LA MENTALIDAD DEL PRODUCTO

Tabla Comparativa 

MENTALIDAD DE PROYECTO	MENTALIDAD DE PRODUCTO
La Mentalidad de Proyecto no existe una validación para comprobar si el producto es valioso, ya que las organizaciones invirtieron una gran cantidad de recursos sin garantía de retorno.	La mentalidad de producto permite hacer lanzamientos continuos del producto en desarrollo, integrar la retroalimentación de clientes potenciales y realizar ajustes sobre la marcha. Con ello se logra reducir la incertidumbre y dar prioridad a los aspectos más valiosos para clientes y usuarios.
La gestión de proyectos se centra específicamente en el rendimiento y se mide por la precisión con la que pudimos estimar el cronograma y luego entregar el resultado según al cronograma. El enfoque del pensamiento del proyecto es la entrega.	No se centra en el rendimiento ni en plazos y fechas, este se centra en el objetivo que queremos lograr o en el trabajo por hacer. Su enfoque es el producto.
El éxito es medido de acuerdo con parámetros preestablecidos: entrega del alcance deseado en presupuesto y plazo.	El éxito se mide de manera continua de acuerdo con métricas de negocio: tasa de uso o retención, ingresos, ahorro en costes, entre otros.
Orientación a la gestión de tareas y personas por parte del Project Manager.	Obtención de feedback de los clientes o usuarios lo mas antes posible para seguir produciendo.
Trasvases de conocimiento entre departamentos o especialistas a medida que las fases del proyecto progresan.	Énfasis en la visión y objetivos de producto en lugar de en la gestión de tareas, lo cual otorga mayor autonomía al Equipo de Desarrollo; mayor creatividad y menor despilfarro en actividades de reporte.
Uso de Waterfall o Water-Scrum-Fall	Uso de Agile y Scrum. Las funciones del Proyect Manager tradicional son eliminadas u absorbidas en parte por el Product Owner, el Scrum Master y el Equipo de Desarrollo.