Contratación · July 21, 2026 · 7 min de lectura

Ingeniería de prompts para product managers: la IA redacta, el criterio decide

Un PM puede obtener un borrador de especificación de la IA en segundos; el riesgo es publicarlo. La habilidad está en plantear bien el problema, detectar la suposición errónea y recortar el alcance sobredimensionado. Una guía práctica con un ejemplo trabajado y cómo se evalúa.

← Parte de The five pillars of a hire: what great assessments actually measure

Un product manager puede obtener de una IA un primer borrador de especificación, una priorización o un resumen competitivo en segundos. Lo seductor es lo terminado que parece; lo peligroso es exactamente lo mismo. Un modelo producirá un documento seguro y bien formateado construido sobre una suposición que, sin ruido, es incorrecta, y un PM que lo publica tal cual ha externalizado lo único para lo que existe el puesto. Esta es la entrada de gestión de producto de nuestra serie de ingeniería de prompts por rol, y es una de las cosas más claras que revela el AI Sandbox.

El planteamiento es el pensamiento de producto

La mitad de un buen prompting de PM ocurre antes de que el modelo se ejecute: plantear el problema, las restricciones y la métrica de éxito con precisión. Ese planteamiento no es un truco de prompt: es el pensamiento de producto, hecho explícito. Dale al modelo un enunciado de problema afilado y te dará un borrador útil; dale 'escribe una especificación para filtros guardados' y rellenará los huecos con suposiciones genéricas. La otra mitad es lo que haces con el borrador: detectar la suposición errónea, recortar el alcance que el modelo sobredimensionó y anclarlo en usuarios y métricas reales. Eso es fluidez con la IA en un puesto de PM.

Un ejemplo trabajado

Pide una especificación de una página para una funcionalidad de filtros guardados. La versión débil pide de forma vaga y publica el resultado pulcro. La versión fuerte plantea el problema real, la restricción dura (un sprint, sin migración de esquema) y la métrica de éxito, y luego pide al modelo que señale sus propias suposiciones. Cuando el borrador asume en silencio un modelo de datos que exigiría la migración que acabas de descartar, el PM lo detecta y reformula la solución.

## TASK
Draft a one-page spec for saved search filters.

## CONTEXT
- Problem: power users re-apply the same 5 filters every day
- Constraint: ship in one sprint, no schema migration
- Success metric: % of searches that reuse a saved filter

## OUTPUT
Problem, non-goals, proposed solution, open questions.
Flag every assumption you make about our data model.

• Bueno: plantea el problema y las restricciones, usa la IA para un borrador rápido, y luego detecta una suposición errónea y ata la especificación a usuarios y métricas reales.
• Débil: publica una especificación generada por IA, con migración incluida, sin criterio de producto superpuesto encima.

Buenas prácticas que de verdad marcan la diferencia

• Plantea con precisión. Problema, restricciones y métrica de éxito por delante: cuanto más afilado el planteamiento, más útil el borrador y menos suposiciones genéricas que deshacer.
• Pide al modelo que señale sus suposiciones. Eso saca a la luz la premisa silenciosamente errónea antes de que quede enterrada en un documento pulido.
• Usa la IA para el borrador, nunca para la decisión. Es una cura para la página en blanco, no un sustituto del criterio sobre usuarios, alcance y compromisos.
• Ancla cada afirmación en la realidad. Ata la especificación al comportamiento y las métricas reales de los usuarios, no a la narrativa verosímil que produjo el modelo.

Modos de fallo comunes

• Publicar-el-borrador: confundir un documento bien formateado con uno bien razonado.
• Planteamiento vago: sin enunciado del problema ni restricciones, así que el modelo inventa los suyos, y tú los heredas.
• Ampliación del alcance por defecto: aceptar funcionalidades que el modelo sobredimensionó en lugar de recortar al problema real.

Cómo lo evaluamos

Una presentación de caso de estudio no te dirá si alguien detecta una suposición errónea en el borrador de una IA, y prohibir la IA evalúa un flujo de trabajo que los PM ya han dejado atrás. Le das al candidato una tarea de producto realista con las herramientas que usaría de verdad y observas el criterio que superpone encima, que es lo que hace una evaluación con AI Sandbox, y cómo se puntúa la fluidez con la IA como pilar. Mira qué cubre una evaluación completa de product manager, por qué esta es la prueba honesta en la contratación nativa de IA, o mira cómo se compone una evaluación ajustada al rol.

La IA le da a cada PM un primer borrador rápido. Los que vale la pena contratar tratan ese borrador como el comienzo del pensamiento, no el final, y la diferencia se nota en la suposición que detectan.