Si bien uno a veces no quiere estar atado a definiciones de alcance o presupuesto, la mayoría de las veces esto termina siendo más bien una ventaja que un problema.
El próximo 19/05, comienza la primer edición de mi curso Estrategia de producto. Para más información, puedes seguir este enlace.
Seth Godin hace un tiempo acuñó la popular frase: “Las restricciones son un regalo” (Constraints are a gift).
Esta simple frase no puede ser más cierta, especialmente en el ámbito de la gestión de proyectos y del diseño/desarrollo de productos.
Al auto-imponernos límites sobre lo qué podemos hacer y lo que no, y al reconocer aquellos que ya existen sobre nosotros y no tenemos control directo, vamos a estar generando un mejor enfoque sobre las soluciones en las que trabajamos.
Uno de los grandes desafíos que tiene armar una estrategia de producto siempre fue “¿hasta que punto nos abstraemos del problema original?”.
Es decir, “¿cuánto queremos abarcar?”, “¿qué tipo de soluciones vamos a considerar?”.
En mi experiencia, cuando las restricciones no están definidas claramente, los equipos terminan considerando soluciones que desde un principio no serán viables de ejecutar.
Ya sea porque son muy costosas, o porque no se cuenta con el equipo necesario, o porque es muy riesgosa. ¡O 10 razones más!
Identificar cuáles son tus restricciones es una actividad fundamental, porque al incluirlas en tu estrategia la van a dotar de un mayor realismo.
La van a conectar mejor con el día a día.
Las restricciones delimitan cuál es tu “área de juego”, y determinan un primer nivel de prioridad donde todas las iniciativas que estén por fuera de esta “área de juego” no serán consideradas en principio.
Marcar un “área de juego” no quiere decir que dejemos de pensar libremente nuevas soluciones “out-of-the-box”.
Es reconocer justamente aquellos límites que siempre están, para así poder enfocarnos mejor en aquello que tenemos capacidad directa para ejecutar.
Hay distintos tipos de restricciones y “modelos” dando vuelta por ahí.
A continuación, ¡te mencionaré algunos!
Le llaman el iron triangle (👀) del Project Management, y representan, al menos lo que creo que yo, al grupo esencial de restricciones: tiempo, alcance y costo.
Esta tríada siempre está presente en cualquier discusión de planificación de estrategia e inicio de proyectos. Veamos cada uno:
📌 Tiempo: al pasar los meses, la oportunidad de incrementar el valor entregado a los usuarios como el valor capturado de ellos, se pospone. Sí, el tiempo también es costo, pero es más que eso: es la demora en el impacto de los objetivos, es el costo de oportunidad, es la pérdida de competitividad.
📌 Alcance: responde a la pregunta, ¿qué tan grande será el esfuerzo?. Cuántas tareas*,* cuántas features o historias de usuario serán incluidas en el proyecto. El alcance tiene que ver directamente con el esfuerzo que llevará la solución.
📌 Costo: finalmente, está el aspecto monetario. Si bien el tiempo se puede trasladar a costo, no es lo único a tener en cuenta. El costo de un proyecto puede venir no solo por costo fijos recurrentes, sino por costos variables, costos fijos de un solo pago o costos hundidos (por ejemplo, una investigación de mercado).
Tiempo, alcance y costo determinan tu área de juego.
Hasta dónde puede ir tu solución, en cuánto tiempo y bajo qué presupuesto.
Veamos esta variante del modelo anterior: ¿que pasa cuando criterios de calidad interfieren en las definiciones sobre tiempo, alcance y costo?
La calidad es un tipo de restricción que depende de muchas veces de los guidelines de un equipo, las normativas de una organización o de las regulaciones impuestas a un mercado.
Estas directrices determinan muchas veces una calidad mínima que debe garantizarse en todo nuevo proyecto o producto, y por eso condiciona al resto de restricciones.
Imagina que dispones de solo 20.000 dólares y 2 meses para un nuevo proyecto, pero que por regulaciones en el mercado financiero, debes garantizar al menos una infraestructura segura y validada por una entidad financiera.
Esta condición de calidad mínima fácilmente puede empujar tu proyecto a un mayor costo, mayor tiempo y un mayor alcance.
La calidad también se ve presente en qué tipos de compromisos técnicos y de usabilidad un equipo de producto está dispuesto a tomar.
Por ejemplo: 📌 ¿Qué tan dispuesto estás a acumular deuda técnica?, ¿qué nivel de escalabilidad debe tener el código en un MVP?
📌 ¿Qué heurísticas de la usabilidad podemos prescindir a favor de una entrega más rápida?
Es importante considerar siempre la calidad y entender en qué nos afecta.
Este modelo agrega dos restricciones más a las vistas anteriormente: riesgo y recursos.
El riesgo como restricción refiere a los posibles incidentes que pueden aparecer en caso de avanzar con el proyecto o desarrollo de una solución.
No necesariamente es una restricción que bloquee el avance de algo, pero sí algo que lo condiciona su elección.
Por ejemplo, tu stakeholder puede preferir ir por el desarrollo de una solución de menor impacto pero bastante menos riesgosa.
Los riesgos de un proyecto deben ser correctamente priorizados, y debe armarse así un plan que, por un lado, reduzca las probabilidades ocurrencia y que, sí suceden, que pueda mitigar su impacto negativo.
Atender las consecuencias de un riesgo lógicamente implica recursos, y es algo con el que un equipo debe convivir en su proyecto.
Por otra parte, los recursos como restricción definen la capacidad de ejecución del equipo.
Por ejemplo, si el proyecto requiere una integración compleja con una API de terceros, y no están los recursos necesarios para ello, entonces la viabilidad técnica del proyecto se verá seriamente comprometida.
Las personas son una restricción debido al encaje que tiene que haber entre la naturaleza de las tareas de un proyecto con respecto a las destrezas y habilidades que disponga el equipo.
Si bien mencionamos algunas de las restricciones más importantes, lógicamente no hemos pasado por todas.
Algunas otras restricciones relevantes pueden ser:
📌 Objetivos estratégicos: la conexión de un proyecto con una métrica importante para el negocio es fundamental para representa una oportunidad real de negocio.
📌 Modelo de negocio: aspectos como el modelo de monetización, canales o segmento objetivo pueden restringir el tipo de soluciones que uno busca desarrollar.
📌 Tecnología: uno puede pensar una solución totalmente innovadora, pero sí en el mercado aún no existe la tecnología necesaria para llevarla a cabo, entonces es más bien una fantasía.
📌 Dependencias: las relaciones entre distintos equipos y la cantidad de trabajo “encadenado” puede afectar el ritmo y velocidad de ejecución de un proyecto.
Que tan importante y condicionante es una restricción para tu equipo va a depender justamente del contexto.
Para algunos equipos, el tiempo es algo totalmente negociable pero el presupuesto es algo que se fija como una piedra pesada.
Para otros equipos, el tiempo es innegociable y sí se permiten una mayor libertad en cuanto a las definiciones de alcance (product scope).
Considerar las restricciones de un proyecto o desarrollo de una nueva solución es un aspecto clave en el diseño de estrategia de producto.
Es importante identificar cuál es tu área de juego y qué restricciones de tiempo, calidad, costo, calidad, riesgos, recursos, entre otras, van a condicionar tu conjunto de alternativas viable.
Lejos de verlas como algo malo o que restringe la “libertad creativa” del equipo, debes verlas como un verdadero “regalo”.
Reconocer las restricciones te va a dar una estrategia más realista, habilita un mejor alineamiento de los esfuerzos y evita dispersarse en soluciones que, de antemano, sabemos que por A o por B no vamos a tener la capacidad para ejecutarlas.
Eso sí, un último consejo a tener en cuenta.
Habilita al menos un mínimo grado de flexibilidad.
Respetar las restricciones de manera rígida te llevará a una estrategia que pierda capacidad de adaptación ante los cambios esperables de un entorno de alta incertidumbre.
Debes tener en claro qué restricciones pueden comprometerse o flexibilizarse, y cuáles son innegociables y deben respetarse en todo momento.
Por lo general, en desarrollo de producto, el tiempo es una restricción poco respetada que suele flexibilizarse muy fácilmente para respetar el alcance definido previamente.
En mi opinión, esto no debería ser así, pero ya es tema para otro artículo…
¡Hasta acá llegamos!
Éxitos.
1. Aprende con Lumi: mi app de microcursos es ideal para desarrollar y fortalecer habilidades de Product Management con pequeñas píldoras de contenido de tan solo 5 minutos.
2. Descubre mis cursos: súmate a mis cursos tanto en vivo como grabados que realizo sobre Product Management. Puedes aprender sobre Product Analytics y Jobs-to-be-done, entre otros temas.
3. Mentorías 1-1: consulta por mi servicio de mentorías 100% personalizadas, donde te acompaño en tu desarrollo como Product Manager y te aconsejo en la resolución de los desafíos que tengas en el camino.
4. Consultoría de producto: acompañó a equipos y empresas a superar los principales bloqueos y obstáculos relacionados con la gestión del desarrollo y diseño de productos digitales.
Conocimiento práctico sobre Product Management en solo 5 minutos, cada martes.