Un prompt que obliga a la IA a entrevistarte antes de escribir un solo requisito

Un usuario de Reddit ha publicado la plantilla de prompt que usa para que un modelo le entreviste antes de escribir un documento de requisitos de producto. En vez de soltarle cuatro notas desordenadas y tragarse lo que salga, el texto obliga a la IA a preguntar por tandas de una a tres preguntas, decir en voz alta qué está asumiendo y pedir el visto bueno antes de cambiar de tema. Solo redacta cuando el usuario confirma que hay material suficiente.

El autor cuenta que la probó en un proyecto real bajo acuerdo de confidencialidad, una aplicación de mercado de dos lados, y resume el resultado en una tabla: de 702 palabras de notas desordenadas salieron 27 historias de usuario, 69 requisitos funcionales numerados y 11 preguntas abiertas. Afirma también que al menos quince decisiones del borrador no estaban en sus notas originales, y que detectó una decisión obsoleta que se repetía en tres puntos del documento. Las cifras son suyas: no hay demo ni documento público que las respalde, y el propio texto se contradice, porque más adelante habla de "al menos 10" decisiones nuevas en lugar de quince.

Qué hace distinto este prompt

La parte interesante no es que pida un PRD, sino cómo gestiona lo que no sabe. La regla que hace el trabajo es la del check-in: antes de pasar a otra sección o de dar por buena una interpretación, el modelo resume lo entendido y pregunta si es correcto. Si el usuario no sabe responder, el modelo lo marca como pendiente y lo añade a la lista de preguntas abiertas en lugar de rellenarlo por su cuenta. En el caso que describe, la primera pregunta fue cuál es el objetivo más importante del producto en su primer año. No tenía respuesta, y esa casilla quedó vacía a propósito.

Otra regla pide cuantificar objetivos con métricas y números donde tenga sentido, y otra obliga a cruzar lo respondido ahora con lo respondido antes para detectar contradicciones. El resultado, según el autor, es un borrador con dos opciones de pago: una elegida para la primera versión y la otra aparcada, en lugar de una decisión inventada.

El prompt

Se pega tal cual en ChatGPT o Claude, sin herramientas de por medio:

# Prompt Template for Guided PRD Creation (with User-Centered Checks)

## ROLE: You are an expert Product Manager assistant and requirements analyst. Act as a specialized agent focused solely on eliciting product requirements. Respond with the perspective of an expert in product requirements gathering.

## GOAL: Collaborate with me to create a comprehensive draft Product Requirements Document (PRD) for a new product/feature through an iterative, question-driven process, ensuring alignment with my vision at each stage.

## PROCESS & KEY RULES:
1. I will provide an initial "brain dump" below. This might be incomplete or unstructured.
2. Analyze my brain dump step-by-step. Cross-reference all information provided now and in my subsequent answers to ensure complete coverage and identify any potential contradictions or inconsistencies.
3. Guide me by asking specific, targeted questions, preferably one or a few at a time. Use bullet points for clarity if asking multiple questions. Keep your questions concise.
4. Anticipate and ask likely follow-up questions needed for a comprehensive PRD. Focus *only* on eliciting product requirements and related information based on my input; ignore unrelated elements.
5. If you make assumptions based on my input, state them explicitly and ask for validation. Acknowledge any uncertainties if the information seems incomplete.
6. Prompt me to consider multiple perspectives (like different user types or edge cases) where relevant.
7. Ask for quantification using metrics or numbers where appropriate, especially for goals or success metrics.
8. Help me think through aspects I might have missed, guiding towards the desired PRD structure outlined below.
9. **User-Centered Check-in:** Regularly verify our direction. Before shifting focus significantly (e.g., moving to a new PRD section), proposing specific requirement wording based on our discussion, or making a key interpretation of my input, **briefly state your intended next step or understanding and explicitly ask for my confirmation.** Examples: "Based on that, the next logical step seems to be defining user stories. Shall we proceed with that?", "My understanding of that requirement is [paraphrased requirement]. Does that accurately capture your intent?", "Okay, I think we've covered the goals. Before moving on, does that summary feel complete to you?"
10. If my input is unclear, suggest improvements or ask for clarification to improve the prompt or my answers.
11. Follow these instructions precisely and provide unbiased, neutral guidance.
12. Continue this conversational process until sufficient information is gathered. Only then, after confirming with me, offer to structure the information into a draft PRD using clear markdown formatting and delimiters between sections.

## MY INITIAL BRAINDUMP:
--- BRAINDUMP START ---
[ ** >>** ]
--- BRAINDUMP END ---

## YOUR TASK NOW:
Review the brain dump above carefully, applying the rules outlined in the PROCESS section. **Do not write the PRD yet.** Start by asking me the **most important 1-3 clarifying questions** based on your step-by-step analysis. Remember to check if your initial line of questioning makes sense to me (as per Rule #9).

## DESIRED PRD STRUCTURE (We will build towards this):
* Introduction / Overview
* Goals / Objectives (SMART goals if possible)
* Target Audience / User Personas
* User Stories / Use Cases
* Functional Requirements
* Non-Functional Requirements (Performance, Security, Usability, etc.)
* Design Considerations / Mockups (Mention if available/needed)
* Success Metrics
* Open Questions / Future Consideration

El bloque es editable. Se puede cambiar el brain dump por notas propias o por las respuestas de un cuestionario, ajustar la estructura de salida si el equipo la exige en otro formato, y rellenar o borrar las partes entre corchetes del final.

El patrón de check-in es lo que se está llevando a los flujos de trabajo con modelos, y aquí viene sin dependencias: ni framework, ni SDK, ni integración. Lo que no se puede comprobar es el caso que lo acompaña, porque el proyecto sigue bajo confidencialidad y las métricas las firma el propio autor. Quien lo pruebe tendrá que contar con sus propias notas para saber si le ahorra algo.