Preguntas de entrevista Product Owner

Trato el backlog como un documento vivo que refleja las prioridades actuales, no una lista de deseos. Utilizo una combinación de valor de negocio, impacto en el usuario, dependencias técnicas y esfuerzo para ordenar los elementos. Para la priorización habitual aplico WSJF (Weighted Shortest Job First) o una matriz valor/esfuerzo simplificada según la madurez del equipo. Mantengo sesiones semanales de refinamiento con el equipo para estimar, clarificar y preparar los elementos de forma que la parte superior del backlog esté siempre lista para el sprint. También mantengo una distinción clara entre los diez primeros elementos (detallados y estimados) y el resto (intencionalmente ligeros hasta que ascienden). Las partes interesadas pueden ver el backlog pero entienden que la posición refleja el pensamiento actual, no un compromiso con una fecha concreta.

Redacto las user stories en el formato estándar: "Como [persona], quiero [acción] para [resultado]." La persona debe ser específica, no un "usuario" genérico, porque las personas vagas llevan a stories vagas. Los criterios de aceptación siguen la estructura Dado/Cuando/Entonces: "Dado [contexto], cuando [acción], entonces [resultado esperado]." También añado casos negativos (qué no debe ocurrir) y casos límite cuando son relevantes. Antes de que una story entre en sprint, la reviso con al menos un desarrollador y un diseñador para confirmar que no es ambigua y es testable. Las stories que no se pueden probar no están listas. Trato los criterios de aceptación como un contrato entre el equipo y las partes interesadas, no como documentación escrita a posteriori.

Empiezo haciendo visible el conflicto en lugar de absorberlo en privado. Reúno a las partes interesadas relevantes, les muestro el orden actual de prioridades del backlog y explico la compensación: atender esta solicitud significa retrasar aquella. Uso datos siempre que puedo para hacer la conversación objetiva. Cuando dos prioridades son genuinamente iguales, escalo a quien posee la estrategia de producto con una recomendación clara y una breve justificación. Documento cada decisión de prioridad y el razonamiento que hay detrás para tener un registro cuando las prioridades vuelvan a cambiar. El objetivo es hacer explícitas y compartidas las compensaciones, no ser quien dice no en nombre de la empresa sin que nadie entienda por qué.

Un director comercial en mi empresa anterior quería que desarrolláramos una función de exportación personalizada para un solo cliente empresarial. La función no estaba en nuestra hoja de ruta y habría requerido dos semanas de trabajo de ingeniería. Extraje los datos sobre solicitudes similares de nuestra cola de soporte y descubrí que menos del 3% de los usuarios habían pedido alguna vez una función comparable. Preparé un documento de una página mostrando el coste de oportunidad: las mismas dos semanas podrían completar una corrección de rendimiento que afectaba al 40% de los usuarios activos. Presenté ambas opciones al director comercial y ofrecí una vía intermedia: una exportación CSV ligera que se podía hacer en tres días y satisfaría la necesidad esencial del cliente sin el desarrollo completo. El director aceptó. El cliente cerró contrato. Encuentro que el "no" funciona mejor cuando viene acompañado de una alternativa.

Estábamos a mitad de sprint cuando un competidor lanzó una función con la que nuestro equipo de ventas estaba perdiendo negociaciones. No tenía datos sobre cuántas negociaciones se veían afectadas ni tiempo para un ciclo de descubrimiento completo. Realicé dos llamadas de 30 minutos con comerciales que habían perdido negociaciones recientemente y revisé los últimos cinco informes de negociaciones perdidas en nuestro CRM. Eso me dio suficiente señal direccional para despriorizar una story de menor valor e insertar un spike para delimitar la respuesta competitiva. Fui claro con el equipo: era una investigación con tiempo limitado, no una función comprometida. El spike duró tres días y decidimos desarrollar una versión mínima. Permitió cerrar dos negociaciones el mes siguiente.

En un sprint nos comprometimos con cinco stories y entregamos dos. La causa principal fue una dependencia de una API de terceros que el equipo asumía estable, pero que cambió sus requisitos de autenticación a mitad de sprint. Realicé una retrospectiva rápida centrada en el riesgo de dependencia: no lo habíamos señalado en la planificación del sprint porque lo considerábamos poco probable. Añadimos un paso de "verificación de dependencias" a nuestra Definición de Preparado: cualquier story que toque un servicio externo requiere confirmación de que la integración es estable antes de entrar en el sprint. Los cuatro sprints siguientes cumplieron todos sus compromisos. La lección que saqué fue que una Definición de Preparado incompleta es una de las causas ocultas más frecuentes de fallo de sprint.

Hago seguimiento en dos niveles. En el nivel de entrega miro la velocidad, la tasa de completitud de stories y si los criterios de aceptación se cumplieron sin retrabajo. Son indicadores retrasados de la salud del equipo. En el nivel de resultado sigo la métrica que el sprint debía mover: tasa de activación, reducción de la tasa de errores, adopción de funciones. Establezco un objetivo para cada release antes de que se entregue y reviso los números reales a los 30 días. Si entregamos todas las stories pero la métrica no se movió, eso es un fallo de descubrimiento, no un éxito de entrega. Comparto ambos niveles con las partes interesadas en una revisión mensual para que la conversación gire en torno a los resultados, no solo al cumplimiento de plazos.

Durante un sprint busco estar disponible sin ser intrusivo. Asisto al stand-up diario y escucho los bloqueos que tienen una dimensión de producto: requisitos poco claros, casos límite que faltan o decisiones de partes interesadas pendientes. Busco responder a esos problemas el mismo día. Evito cambiar stories a mitad de sprint salvo por una razón crítica, porque los cambios a mitad de sprint destruyen el impulso y la confianza. Si el equipo descubre que una story es más grande de lo estimado, trabajo con el Scrum Master para decidir si reducimos el alcance para cumplir el objetivo del sprint o si señalamos el riesgo en la sprint review. También hago seguimientos a mitad de sprint en las stories en curso para detectar malentendidos antes de que lleguen a las pruebas de aceptación.

Separo intencionalmente la planificación interna de la comunicación externa. Internamente trabajo con una hoja de ruta trimestral "ahora, después, más adelante" que vincula cada iniciativa a un objetivo de negocio. Con las partes interesadas comparto una versión centrada en objetivos y temas en lugar de funciones o fechas específicas, porque los compromisos detallados sobre funciones hechos meses antes casi siempre resultan equivocados. Sí comparto ventanas de release específicas para elementos con dependencias externas, como una campaña de ventas o un compromiso contractual, pero los señalo como de alta certeza. Mantengo una revisión mensual de la hoja de ruta con las partes interesadas clave para revisar las prioridades y mantener las expectativas actualizadas.