AI can produce polished material before the task is understood. That speed is useful only after you know what is being produced, who will use it, and what must be true for it to be acceptable.
The first move is therefore not “write the report.” It is “help me define the work product.” A work product is the inspectable artifact created by the assignment: a briefing note, risk register, schedule narrative, design option comparison, or another concrete deliverable. It needs a form, an intended user, and a useful outcome.
A specification records the approved conditions for that work product. NASA’s systems-engineering guidance offers a useful distinction: a need should describe the problem rather than prematurely prescribe the solution, while a good requirement should be clear, feasible, unambiguous, and verifiable [1]. The same discipline applies to AI-assisted professional work.
Let the AI Interview You
Most people begin with an incomplete mixture of goals, constraints, preferences, assumptions, and solution ideas. A one-question-at-a-time interview slows the conversation just enough to separate them.
The interview should establish six things:
Purpose: What outcome should this work product enable?
Users: Who will read, use, approve, or be affected by it?
Form: What exactly will be delivered?
Scope: What is included, and equally important, what is excluded?
Conditions: What must be true for the result to be acceptable?
Authority: Which assumptions or decisions require a person’s approval?
This is not limited to software. Government digital-service guidance uses the same logic in a compact form: identify the actor, the need, the goal, and acceptance criteria that describe when the work is done [2]. In a construction or engineering context, the vocabulary may change, but the principle does not.
Keep Three Boundaries Clear
The specification defines the target. It does not produce the work product, design the verification method, or authorize autonomous iteration.
That separation matters. If the same conversation quietly moves from defining the need to choosing the solution, important assumptions can disappear into the draft. If it also decides how success will be checked, the criteria may be softened to fit what the AI has already produced.
The interview should end with a named, approved version. That version becomes a stable reference whether the next step is completed by a person, one AI, a team, or a later improvement loop.
The Prompt
Help me define a work product and its specification by interviewing me.
Ask one question at a time. Clarify the problem, who will use the result, the
useful outcome, the smallest worthwhile scope, and the constraints. Separate
needs from proposed solutions and confirmed facts from assumptions. Do not fill
material gaps yourself.
When you understand the task, summarize:
- Goal and intended use
- Work product, form, and intended users
- In scope and out of scope
- Requirements and constraints
- Acceptance conditions describing what must be true
- Assumptions, open decisions, and approval authority
Ask me to correct or approve the summary. After approval, issue the specification
as a named version. Stop there. Do not design the verification method or produce
the work product.
Start by asking me to describe the project idea in my own words.What a Good Output Looks Like
A strong result is short enough to review and specific enough to govern later work. The work product is named in concrete terms. Scope boundaries are visible. Acceptance conditions describe outcomes rather than vague aspirations. Assumptions are not presented as facts. Open decisions have owners.
For low-risk work, a concise specification may be enough. For contractual, safety-critical, or multi-party work, add identifiers, source references, tolerances, traceability, and formal change authority. Those are extensions of the same model, not reasons to make every prompt heavy.
Once the specification is approved, the next question is no longer “what are we making?” It is “what evidence would show that this version meets the approved conditions?” That is the role of the verification layer.
References
1. National Aeronautics and Space Administration. (2016). NASA systems engineering handbook: Appendix C—How to write a good requirement.
2. Government Digital Service. (2016). Writing user stories.
Notes
Join the EPM Network to access insights, influence our research, and connect with a community shaping the industry’s future.
Support us by sharing this article with your friends and colleagues, or over social media.