Planteamiento y escenarios aplicables
Eres el responsable de un producto SaaS B2B de colaboración. La próxima iteración tiene únicamente 6 semanas-ingeniero, pero tres solicitudes no caben a la vez:
- Ventas propone SSO, estimado inicialmente en 5 semanas-ingeniero. Un cliente actual afirma que ampliará su contrato tras el lanzamiento, y Ventas lista 12 clientes potenciales similares.
- Soporte propone la restauración masiva para proyectos archivados por error, estimada inicialmente en 3 semanas-ingeniero. El problema representa el 18% de los tickets en las últimas 4 semanas y afecta a cerca del 8% de los administradores activos mensuales.
- El equipo de Plataforma propone una migración de almacenamiento, estimada inicialmente en 6 semanas-ingeniero. La versión actual pierde soporte en 9 meses, mientras que la migración, la observación y la reversión requieren al menos 5 meses.
Todas las cifras son suposiciones del caso de entrevista, no puntos de referencia de la industria. Explica qué validarías, cómo compararías distintos tipos de trabajo, qué solicitud elegirías y qué les dirías a los equipos cuyas solicitudes no fueron seleccionadas. El entrevistador podría cambiar una restricción (por ejemplo, adelantar la fecha de fin de soporte del almacenamiento o revelar que el SSO solo sirve a un cliente) para ver si te aferras a la conclusión inicial.
Esta es una pregunta de criterio de producto para product managers, product owners y líderes técnicos que participan en decisiones de hoja de ruta. El material público de entrevistas de 2026 todavía incluye la priorización de tres solicitudes de funciones en competencia como una pregunta directa para PM. La guía pública de entrevistas para PM de DoorDash también dedica una ronda específica a la Priorización de Producto y busca datos, compensaciones (trade-offs), decisiones difíciles y una métrica norte (north star) explícita desde el inicio.
Qué evalúa el entrevistador
La primera señal es si estableces el objetivo de la decisión. Los ingresos, los tickets, el riesgo de plataforma y el costo de ingeniería no pueden arrojar una sola conclusión hasta que el equipo sepa si este ciclo prioriza la expansión empresarial, la retención, la eficiencia de soporte o una reducción de riesgos obligatoria. Un candidato sólido también identifica las salvaguardas (guardrails) que el objetivo no puede anular.
La segunda señal es si reconoces las restricciones duras. La seguridad, el cumplimiento, los compromisos firmados, el fin de soporte de proveedores y las dependencias irreversibles pueden formar una puerta de elegibilidad. El trabajo que ha alcanzado su fecha de inicio seguro más tardía merece capacidad antes de puntuar las oportunidades ordinarias. Al mismo tiempo, «el soporte termina en 9 meses» no significa automáticamente «empezar esta semana». Todavía necesitas restar el tiempo de migración, observación, reversión y contingencia para calcular la fecha de inicio seguro más tardía.
La tercera señal es la calidad de la evidencia. Un embudo de ventas, una tasa de tickets de soporte y el riesgo de plataforma no son comparables por naturaleza. Una respuesta sólida verifica si el compromiso del cliente es contractual, si los 12 prospectos han alcanzado una etapa comparable, si el 18% de los tickets comparten la misma causa raíz, si el 8% de los usuarios están bloqueados en un recorrido crítico y si cada estimación incluye revisión de seguridad, trabajo de lanzamiento y mantenimiento continuo.
La cuarta señal es una decisión. Decir «usaría RICE, MoSCoW o una matriz de valor-esfuerzo» no resuelve el planteamiento. El material actual sobre prácticas de producto también advierte que un solo marco no puede comparar todos los tipos de trabajo. La guía original de RICE permite que las dependencias y los requisitos básicos del mercado (table stakes) anulen el orden de puntuación. Un marco reduce los puntos ciegos; el candidato sigue siendo responsable de la recomendación, el costo de oportunidad y las condiciones que la revertirían.
Por último, el entrevistador busca una comunicación operativa. Una decisión de hoja de ruta necesita evidencia, suposiciones, un responsable, fechas y detonantes de revisión. Prometerle «pronto» a cada equipo genera tres compromisos ocultos y no ofrece evidencia de que el candidato pueda gestionar expectativas.
Preguntas aclaratorias antes de responder
- ¿Cuál es el resultado principal único para este ciclo? Este caso asume que la empresa prioriza la expansión empresarial este trimestre, sujeta a la fecha de inicio seguro más tardía para la migración de almacenamiento.
- ¿Qué significa 6 semanas-ingeniero? ¿Es un ingeniero durante 6 semanas o esfuerzo fungible distribuido entre varias personas? ¿Incluye ya revisión, pruebas, trabajo de lanzamiento y guardias operativas? Este caso lo trata como esfuerzo total de ingeniería fungible.
- ¿Cuándo es el inicio seguro más tardío para la migración? ¿Son los 9 meses un plazo estricto o una alerta temprana? ¿Cuánto tiempo toman la escritura dual, la validación, la reversión y la contingencia? Este caso asume que el responsable de plataforma verifica que el trabajo puede comenzar a más tardar dentro de 4 meses, pero la capacidad debe reservarse en el próximo ciclo de planificación.
- ¿Qué tan sólida es la evidencia comercial para SSO? ¿Está la expansión estipulada como condición contractual? ¿Están los 12 prospectos bloqueados por la misma funcionalidad? ¿Cuáles son el valor esperado y la probabilidad de cierre? Este caso asume que la condición del cliente actual está confirmada y 4 de los 12 prospectos han completado la validación técnica.
- ¿Merece el problema de soporte una solución a nivel de producto? ¿Están deduplicados el 18% de los tickets? ¿Es la tarea crítica para el 8% de los administradores? ¿Podrían la capacitación, los permisos o el diseño del flujo de trabajo ser la causa raíz? Este caso asume que la restauración masiva aborda la causa principal y no se han perdido datos.
- ¿Tienen las tres estimaciones un alcance consistente? ¿Incluye SSO la revisión de seguridad y la configuración empresarial? ¿Incluye la restauración masiva registros de auditoría? ¿Incluye la migración escritura dual y un simulacro de reversión? Las estimaciones con límites diferentes no se pueden comparar directamente.
- ¿Puede una prueba de riesgo de bajo costo reducir la incertidumbre? Un pequeño spike técnico puede aportar información valiosa, pero dividir las tres solicitudes en fragmentos no produce ningún resultado. Este caso permite un spike de seguridad para SSO de 3 días hábiles dentro del presupuesto de 6 semanas-ingeniero.
- ¿Quién es el responsable de la decisión final? El PM debe presentar una recomendación respaldada por evidencia. Contratos firmados, obligaciones regulatorias o riesgos técnicos inaceptables pueden requerir un responsable de decisión designado y una ruta de escalamiento.
Estructura de respuesta en 30 segundos
«Confirmaría el objetivo del ciclo y las restricciones duras, especialmente la fecha de inicio seguro más tardía de la migración. Luego normalizaría el resultado, la evidencia, el esfuerzo, el costo de la demora, las dependencias y la reversibilidad, puntuando únicamente las oportunidades comparables. En este caso, la migración puede esperar un ciclo y la expansión empresarial lidera las prioridades, por lo que dedicaría 3 días hábiles a validar SSO. Si el esfuerzo total se mantiene dentro de las 6 semanas-ingeniero, lo elijo; de lo contrario, cambio a la restauración masiva. Reservaría capacidad de migración para el próximo ciclo, le daría a Soporte una solución alternativa y una fecha de revisión, y documentaría cada supuesto y detonante de reversión».
Análisis detallado paso a paso
Comienza reformulando las solicitudes como resultados en lugar de comparar tres nombres de funciones. El objetivo de SSO es eliminar un obstáculo para la expansión empresarial. La restauración masiva busca reducir el retrabajo de los administradores y el costo de soporte. La migración de almacenamiento apunta a eliminar el riesgo de continuidad antes de una fecha límite del proveedor. Luego, establece el objetivo del ciclo y las salvaguardas. En este caso, la expansión empresarial es el objetivo; la seguridad de los datos, las obligaciones contractuales y la fecha de inicio seguro más tardía de la migración son las salvaguardas.
En segundo lugar, construye una puerta de restricciones duras. Plantea cuatro preguntas para cada solicitud: ¿La demora violaría la ley, un contrato o un límite de seguridad? ¿Existe una fecha límite externa estricta? ¿Hemos alcanzado la fecha de inicio seguro más tardía? ¿Se puede recuperar el daño más adelante? Si las respuestas hacen que el trabajo sea obligatorio en este ciclo, reserva esa capacidad antes de clasificar las oportunidades ordinarias. En este punto, el equipo de plataforma ha establecido que la migración puede comenzar hasta dentro de 4 meses, por lo que la restricción no se ha activado aún. Esa conclusión todavía necesita un responsable y una fecha; «más tarde» no es un plan.
En tercer lugar, normaliza la evidencia. La siguiente tabla es únicamente una instantánea del caso actual:
| Dimensión | SSO | Restauración masiva | Migración de almacenamiento |
|---|---|---|---|
| Resultado esperado | Expansión empresarial | Menos retrabajo y menos tickets | Menor riesgo de continuidad |
| Evidencia de alcance | 1 condición de expansión confirmada; 4 prospectos validados técnicamente | 18% de tickets; 8% de administradores activos mensuales | El soporte finaliza en 9 meses |
| Calidad de la evidencia | Media | Alta | Alta |
| Esfuerzo total | 5 semanas-ingeniero más una verificación de alcance de 3 días hábiles, con un tope de 6 semanas-ingeniero en total | 3 semanas-ingeniero | 6 semanas-ingeniero |
| Costo de la demora | Puede retrasar la expansión de este trimestre | Los tickets y el retrabajo continúan acumulándose | Puede esperar un ciclo ahora; aumenta rápidamente después |
| Reversibilidad y dependencias | Se puede detener si el alcance de seguridad es desfavorable | Se puede implementar gradualmente y revertir con mayor facilidad | Múltiples dependencias y reversión costosa |
La «evidencia de alcance» no debe ser una simple repetición del número dado por el solicitante. Deduplica la lista de ventas según la etapa, la condición contractual y la necesidad compartida. Segmenta los datos de soporte por causa raíz, grupo de usuarios y gravedad. Planifica hacia atrás desde la fecha límite de la plataforma considerando el trabajo real y la contingencia. La falta de información debe reducir la confianza en la prioridad. Los decimales precisos no pueden hacer que una estimación de impacto sin respaldo sea confiable.
En cuarto lugar, elige un método de comparación acorde al tipo de trabajo. RICE puede comparar alcance, impacto, confianza y esfuerzo cuando las opciones son oportunidades de funciones que sirven a un mismo objetivo. El costo de la demora ayuda cuando el factor temporal es crucial. MoSCoW puede ayudar a converger en el alcance. Cuando se mezclan oportunidades comerciales, mejoras de experiencia y riesgos de base, clasifica y aplica la puerta de restricciones primero, y luego usa un cuadro de mando reducido para lo que quede. Una puntuación es un insumo para la discusión, y cada excepción de tipo «imprescindible» debe tener una justificación por escrito.
En quinto lugar, toma una decisión. Bajo los supuestos de este caso, la migración de almacenamiento no ha alcanzado su fecha de inicio seguro más tardía. SSO se alinea de forma más directa con la expansión empresarial y cuenta con una condición de expansión confirmada más 4 oportunidades similares validadas técnicamente. Ejecuta una verificación de seguridad y alcance de 3 días hábiles. Si confirma que el trabajo completo se mantiene dentro de las 6 semanas-ingeniero, asigna el ciclo a SSO.
Establece dos condiciones de cambio explícitas. Si el alcance completo de SSO supera las 6 semanas-ingeniero, o si la condición de expansión y la necesidad compartida del mercado no pueden verificarse, detente y cambia a la restauración masiva de 3 semanas-ingeniero. Utiliza la capacidad restante para validar la migración de almacenamiento en lugar de iniciar una tercera función incompleta. La regla de cambio delimita la exploración y evita caer en la falacia del costo hundido tras unos pocos días de trabajo.
En sexto lugar, gestiona el trabajo no seleccionado. Reserva 6 semanas-ingeniero, un responsable, una fecha de inicio y una revisión de riesgos para la migración de almacenamiento en el próximo ciclo de planificación. Reabre la priorización de inmediato si la fecha límite del proveedor se adelanta, si la validación demuestra que la migración tomará más tiempo o si el margen de contingencia cae por debajo del acordado. Proporciona a Soporte un procedimiento manual masivo y controlado, etiquetado de tickets y la próxima fecha de revisión. Continúa midiendo la gravedad y el tiempo de resolución para que una solución temporal no se convierta en un aplazamiento indefinido.
Finalmente, define el resultado y la retrospectiva. Tras el lanzamiento de SSO, verifica si los clientes bloqueados completan la configuración, si se cumple la condición de expansión, si avanzan las oportunidades calificadas y si los fallos de autenticación o la carga de soporte se mantienen en niveles aceptables. En la ventana de evidencia acordada, compara los resultados con las suposiciones iniciales. Si el valor no se materializa, identifica si se estimó mal el alcance, el impacto, la confianza o el esfuerzo. La habilidad para priorizar incluye corregir una decisión, no solo defender la postura inicial.
Respuesta de muestra de alta calidad
La recomendación a continuación utiliza los datos del caso ficticio del planteamiento.
«Traduciría primero las solicitudes en resultados: SSO elimina un obstáculo para la expansión empresarial, la restauración masiva reduce el retrabajo de los administradores y la migración de almacenamiento controla el riesgo de continuidad. Confirmaría que la expansión empresarial es el resultado principal del trimestre, mientras que la seguridad, los contratos y la fecha de inicio seguro más tardía de la migración se mantienen como salvaguardas.
Combinar 1 cliente, el 18% de los tickets y un plazo límite de 9 meses en una sola puntuación sería prematuro. El equipo de Plataforma debe calcular hacia atrás pasando por migración, observación, reversión y contingencia. El caso indica que el trabajo puede comenzar de manera segura hasta dentro de 4 meses, por lo que la restricción dura no se ha activado en este ciclo. Aun así, reservaría desde ahora 6 semanas-ingeniero y un responsable para el próximo ciclo. Ventas debe verificar la condición de expansión y determinar cuántos de los 12 prospectos están bloqueados por la misma funcionalidad de SSO; la evidencia actual es de 1 condición confirmada y 4 prospectos técnicamente validados. Soporte debe demostrar que el 18% de los tickets se debe a la falta de restauración masiva y descartar por separado temas de capacitación o permisos.
Bajo estos supuestos, recomiendo SSO para este ciclo. Es lo que mejor se alinea con la expansión empresarial y su estimación de 5 semanas-ingeniero se ajusta al presupuesto. Primero ejecutaría una verificación de seguridad y alcance con un límite de 3 días hábiles, incluida dentro del presupuesto de 6 semanas-ingeniero. Si el alcance total aún cabe en las 6 semanas-ingeniero, continuamos. Si no es así, o si la condición de expansión y la necesidad compartida no se verifican, nos detenemos y cambiamos a la restauración masiva de 3 semanas-ingeniero.
Las solicitudes no seleccionadas aún necesitan respuestas ejecutables. La migración pasa a la hoja de ruta con fecha de inicio en el próximo ciclo, responsable asignado y detonantes de riesgo que puedan adelantarla. Soporte obtiene un proceso manual controlado y actualiza los datos de gravedad y tiempo de gestión antes de la siguiente revisión de planificación. Plasmaría el objetivo, la evidencia, las suposiciones, la decisión y las condiciones de cambio en un registro de decisión de una página para que Ventas, Soporte, Ingeniería y el equipo directivo compartan la misma lógica.
Tras el lanzamiento, revisaría la tasa de finalización de configuración de SSO, el cumplimiento de la condición de expansión, el avance en oportunidades de venta, los fallos de autenticación y los nuevos tickets de soporte. En la ventana de revisión acordada, examinaría el error de estimación. Si el objetivo o la fecha límite estricta cambian, repriorizaré; la primera decisión no es una promesa inmutable».
Errores comunes
- Aplicar RICE de inmediato → Se fuerza trabajo heterogéneo en una sola puntuación y una fecha límite estricta puede diluirse en un promedio → Clasifica primero; verifica restricciones legales, de seguridad, contractuales, de dependencias y de inicio más tardío; luego compara oportunidades.
- Seguir al interesado más ruidoso → El poder organizacional sustituye la evidencia del usuario y del negocio → Normaliza la evidencia y registra el resultado, alcance y confianza detrás de cada solicitud.
- Poner «el soporte termina en 9 meses» automáticamente en primer lugar → Sin calcular hacia atrás considerando migración y margen de seguridad, la urgencia es desconocida → Calcula la fecha de inicio seguro más tardía y asigna un responsable y un detonante de revisión.
- Tratar los 12 prospectos como ingresos garantizados → La etapa, la probabilidad y la necesidad común no se han verificado → Verifica condiciones contractuales, etapa del embudo y valor reutilizable, luego reduce la confianza ante la incertidumbre.
- Contar únicamente los tickets → Los duplicados, los problemas de baja gravedad y unos pocos usuarios frecuentes pueden distorsionar el resultado → Segmenta por causa raíz, usuarios afectados, gravedad de la tarea y tiempo de resolución.
- Dividir al equipo entre las tres solicitudes → Ninguna tendrá suficiente capacidad para completarse, creando tres esfuerzos inconclusos y mayor costo de cambio de contexto → Elige un resultado y separa solo una validación con límite de tiempo y regla de salida.
- Prometer todas las solicitudes para el próximo lanzamiento → Los compromisos ocultos entran en conflicto y el siguiente ciclo hereda el mismo problema → Asigna a cada elemento no seleccionado un estado, fecha, responsable y condición de reapertura.
- Generar una puntuación sin una recomendación → El entrevistador no puede comprobar si asumirás el costo de oportunidad → Declara la elección, a qué estás renunciando, por qué y qué evidencia la revertiría.
- Calificar la priorización como acertada en el momento del lanzamiento → El despliegue no demuestra que el valor esperado haya aparecido → Observa la hipótesis original y revisa las estimaciones de alcance, impacto, confianza y esfuerzo.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: El CEO ordena explícitamente priorizar un elemento en primer lugar. ¿Sigues priorizando?
Aclara si esto es nueva información, una recomendación o la instrucción definitiva, y saca a la luz cualquier objetivo o restricción que el CEO conozca y el equipo no. Si el derecho de decisión pertenece al CEO, documenta la decisión y los riesgos y procede a ejecutarla. El PM aún debe presentar el costo de oportunidad, los compromisos desplazados y un plan de validación. Un cuadro de mando no puede anular la autoridad explícita, y la autoridad no justifica ocultar riesgos.
Pregunta de seguimiento 2: La evidencia para las tres solicitudes está incompleta. ¿Cómo evitas una investigación interminable?
Identifica las incógnitas con mayor probabilidad de alterar el orden y delimita su tiempo de análisis (time-box). En este caso, el alcance de seguridad de SSO y la condición del cliente determinan si SSO es elegible; la fecha de inicio más tardía del almacenamiento decide si la restricción dura se activa. Dedica 3 días hábiles a esas variables, utiliza rangos para el resto y redacta la bifurcación con anticipación: si el resultado es A, se elige X; si el resultado es B, se elige Y. La investigación debe servir para adquirir información orientada a la decisión, no conocimiento exhaustivo.
Pregunta de seguimiento 3: ¿Cómo comparas la solicitud de un solo cliente grande con los problemas de muchos usuarios pequeños?
Traduce «grande» y «muchos» a valor atribuible, alcance, gravedad, ajuste estratégico, confianza, esfuerzo y carga de mantenimiento. Evalúa si la solicitud del cliente grande representa una funcionalidad reutilizable que abre mercado y si el problema de los usuarios pequeños bloquea una tarea central. El recuento de clientes por sí solo no decide la prioridad. Un problema poco frecuente que impide un trabajo crítico puede superar en prioridad a un inconveniente menor pero frecuente.
Pregunta de seguimiento 4: La deuda técnica siempre pierde en la puntuación. ¿Qué harías?
Expresa la deuda técnica en términos de probabilidad de fallo, retrasos en la entrega, exposición de cumplimiento, costo operativo o trabajo downstream que bloquea, y muestra cómo cambia ese riesgo con el tiempo. Una vez que alcanza un umbral inaceptable o la fecha de inicio seguro más tardía, reserva capacidad por restricción dura. Antes de eso, financia una validación de riesgos acotada y capacidad futura explícita. Un modelo de ingresos a corto plazo no es adecuado para trabajos de infraestructura con horizontes a largo plazo.
Pregunta de seguimiento 5: Llega una solicitud urgente a mitad del desarrollo. ¿Repriorizas inmediatamente?
Aplica la misma puerta de control: seguridad, cumplimiento, pérdida de un cliente crítico o una fecha límite irreversible. Si no se activa ninguna restricción dura, compara el valor residual de terminar el trabajo actual, el costo de cambio de contexto y el costo de la demora de la nueva solicitud. Si reordenas prioridades, documenta el punto de detención, el tratamiento del trabajo ya realizado y los compromisos que se desplazan. Si mantienes el plan, fija la próxima fecha de revisión. Registra las interrupciones recurrentes por separado, ya que pueden indicar objetivos inestables o fallas en el proceso de recepción de requerimientos.
Pregunta de seguimiento 6: Se lanza SSO pero no genera expansión. ¿Cómo revisas la decisión?
Audita el registro de la decisión capa por capa: ¿Era real la condición comercial? ¿Compartían los prospectos la misma necesidad? ¿Completaron los clientes la configuración? ¿Cumplió la implementación los requisitos de seguridad empresarial? ¿Fue la ventana de observación lo suficientemente amplia? Luego, distingue un error de criterio de uno de ejecución. Si se sobrestimó el alcance o el impacto, endurece los estándares de evidencia futuros. Si la calidad de entrega bloqueó la adopción, repara la experiencia antes de juzgar la oportunidad. La retrospectiva debe modificar la siguiente estimación; argumentar que «el mercado tuvo un rendimiento inferior» no es suficiente.