Cuando un producto escala, los problemas técnicos que antes eran menores se vuelven bloqueos de negocio. El PM que entiende la escalabilidad puede comunicar el impacto de la deuda técnica en términos de negocio y priorizarla en el roadmap. Aprende a identificar los cuellos de botella de escalabilidad, comunicarlos a stakeholders no técnicos, y construir un roadmap técnico que equilibre velocidad de features y salud del sistema.
Cuándo usarlo: Construir y defender un roadmap técnico de escalabilidad ante el negocio
Herramienta recomendada: Claude
Actúa como Product Manager senior con experiencia en productos de alto tráfico y en la gestión del balance entre features de negocio y trabajo técnico de escalabilidad. Ayúdame a construir un roadmap técnico de escalabilidad que pueda presentar y defender ante stakeholders de negocio. **El contexto** El producto ha pasado de 10.000 a 200.000 usuarios activos en 18 meses. El equipo de ingeniería alerta sobre problemas de rendimiento y escalabilidad que aún no son visibles para los usuarios pero que podrían ser catastróficos si seguimos creciendo al mismo ritmo. El CEO quiere nuevas features para crecer más rápido, pero el CTO dice que necesitamos invertir en infraestructura antes. Soy el PM en medio de ese debate. **Entregables que necesito** 1. **Framework para identificar y priorizar deuda técnica de escalabilidad**: diseña un proceso para trabajar con el equipo de ingeniería e identificar los principales riesgos de escalabilidad del sistema. Incluye: cómo hacer una sesión de technical risk mapping, cómo evaluar cada riesgo por probabilidad de ocurrencia e impacto en el negocio, y cómo traducir riesgos técnicos a términos de negocio que los stakeholders puedan entender. 2. **Cómo comunicar la escalabilidad a stakeholders no técnicos**: diseña una guía para presentar los problemas de escalabilidad al CEO, CFO o board. Incluye: cómo cuantificar el impacto económico de un problema de escalabilidad (tiempo de inactividad, coste de clientes perdidos, coste de emergencias técnicas), cómo usar analogías efectivas, y qué nivel de detalle técnico incluir y cuál omitir. 3. **Modelo de priorización de features vs. trabajo técnico**: propón un framework para decidir cuánto de la capacidad del equipo dedicar a features de negocio vs. mejoras técnicas de escalabilidad. Considera modelos como el 70/20/10 de Google, cómo ajustarlo según el estado de salud del sistema, y cómo comunicar esa distribución al equipo y a los stakeholders. 4. **Construcción del roadmap técnico de escalabilidad**: explica cómo construir un roadmap de iniciativas técnicas de escalabilidad para los próximos 12 meses. Define cómo agrupar las iniciativas por impacto (rendimiento, disponibilidad, costes de infraestructura), cómo secuenciarlas respetando dependencias técnicas, y cómo presentarlo al lado del roadmap de features sin que parezca que compiten. 5. **Métricas de salud técnica del producto**: define los indicadores de salud técnica que el PM debe monitorizar regularmente. Incluye: latencia de API (p50, p95, p99), tasa de errores, disponibilidad (SLO/SLA), coste de infraestructura por usuario activo, tiempo de despliegue, y frecuencia de incidentes. Explica cómo llevar estas métricas a las revisiones de producto. 6. **Cómo gestionar una crisis de escalabilidad**: diseña un protocolo de gestión de crisis cuando se produce un problema grave de escalabilidad en producción. Define los roles, la comunicación interna y externa, el proceso de triage técnico, cómo priorizar el trabajo de emergencia, y el postmortem que sigue a la resolución. **Formato de salida** Encabezados claros por sección. El framework de priorización en formato tabla con criterios de puntuación. El roadmap técnico en formato de tabla por trimestre. Las métricas con umbrales de alerta sugeridos.