Introducción a Product Management

El Product Manager: Constructor de Puentes El Product Manager (PM) es la persona responsable de definir qué se construye y por qué. No es un jefe de diseñadores ni de desarrolladores — es un facilitador que conecta las necesidades del negocio, los usuarios y la tecnología para crear productos exitosos. Responsabilidades principales de un PM Descubrimiento: investigar qué problemas tienen los usuarios y qué oportunidades existen en el mercado Estrategia: definir la visión del producto y cómo se a

Descubriendo Qué Construir El descubrimiento de producto (Product Discovery) es el proceso de identificar las oportunidades más valiosas antes de invertir en diseño y desarrollo. El objetivo es minimizar el riesgo de construir algo que nadie quiere, no puede usar o no es viable técnicamente. Los 4 riesgos del producto Riesgo de valor: ¿los usuarios realmente quieren esto? ¿Resuelve un problema real o significativo? Riesgo de usabilidad: ¿los usuarios pueden usar esto? ¿Entienden cómo funciona si

El Arte de Decir No: Priorización de Features La priorización es la habilidad más importante y difícil de un PM. Siempre hay más ideas que capacidad para ejecutarlas. Tu trabajo es elegir las pocas que generarán el mayor impacto con el menor esfuerzo posible. RICE Framework Reach (Alcance): ¿a cuántos usuarios afecta esta feature en un período dado? (número estimado) Impact (Impacto): ¿cuánto mejora la experiencia para esos usuarios? (3=masivo, 2=alto, 1=medio, 0.5=bajo) Confidence (Confianza):

El Roadmap: Comunicar la Dirección del Producto Un product roadmap no es una lista de features con fechas. Es una herramienta de comunicación que muestra la dirección estratégica del producto y los problemas que planeas resolver en cada horizonte temporal. Elementos de un buen roadmap Visión: una frase que describe el estado futuro ideal del producto (el norte al que apuntas) Objetivos: 2-3 metas medibles por trimestre alineadas con los objetivos del negocio Temas: agrupaciones de trabajo por pr

Historias de Usuario: Conectar Necesidades con Desarrollo Las historias de usuario son la forma estándar en que los PMs comunican requerimientos al equipo de desarrollo. Una buena historia explica quién necesita qué y por qué, sin dictar cómo implementarlo. Formato clásico de una historia de usuario Como [tipo de usuario], quiero [acción/funcionalidad], para que [beneficio/objetivo] Ejemplo: 'Como freelancer, quiero exportar mis facturas en PDF, para que pueda enviarlas por email a mis clientes'

Midiendo el Éxito de tu Producto Lo que no se mide no se puede mejorar. Las métricas de producto te dicen si tus decisiones están funcionando, dónde hay problemas y qué oportunidades existen. Un PM que no mira métricas está tomando decisiones a ciegas. North Star Metric (NSM) La NSM es la métrica única que mejor refleja el valor que tu producto entrega a los usuarios Spotify: tiempo de escucha / Airbnb: noches reservadas / Slack: mensajes enviados Tu NSM debe: correlacionar con retención, reflej

Comunicar con Claridad es tu Superpoder Un PM pasa el 60-70% de su tiempo comunicando: escribiendo specs, presentando a stakeholders, facilitando reuniones, resolviendo conflictos y alineando equipos. La claridad en tu comunicación determina directamente la velocidad y calidad de ejecución del equipo. Comunicación con el equipo de desarrollo Sé específico en los requerimientos pero flexible en la implementación — define el qué, no el cómo Siempre incluye el contexto del problema: por qué estamos

Decidir con Incertidumbre: La Realidad del PM La mayoría de las decisiones de producto se toman con información incompleta. Nunca tendrás el 100% de los datos que querrías. La habilidad clave no es eliminar la incertidumbre, sino tomar buenas decisiones a pesar de ella. Framework de decisiones reversibles vs irreversibles Decisiones reversibles (Type 2): si nos equivocamos, podemos cambiar fácilmente — decide rápido, no busques consenso Ejemplo reversible: cambiar el color de un botón, agregar u