Sign in Start free
ANALYTICS & REPORTING

Answering a loaded stakeholder question

Use when you have been asked a data question whose framing already assumes an answer.

stakeholder-question-answering.md
Download .md 
A stakeholder has asked a data question. Answer it honestly, including the part where the question itself is off.

Question as asked: {{QUESTION}}
Who asked and what they are trying to decide: {{ASKER_AND_GOAL}}
Data I have: {{AVAILABLE_DATA}}
Data I do not have: {{MISSING_DATA}}

Output:
1. What they are really trying to decide, in one sentence.
2. Any assumption baked into the question that the data does not support. If there is none, say so.
3. The best answer the available data can give, with its uncertainty stated.
4. The better question, if there is one, and what it would take to answer it.
5. A short reply I can send, 120 words maximum, that answers the question without being evasive and without pretending to more certainty than we have.

Rules:
- Do not answer a question the data cannot answer just because it was asked. Say what is missing.
- Do not be condescending about the framing. Correct it in one clause and move on.
- The reply in section 5 must lead with the answer, not with caveats.
- No hedging phrases stacked together. One clear statement of confidence.
- No em dashes.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

  • {{QUESTION}}
  • {{ASKER_AND_GOAL}}
  • {{AVAILABLE_DATA}}
  • {{MISSING_DATA}}

Getting a better result

  1. Write down what they are deciding before you pull any data; it often changes the query.
  2. Section 2 is the value here, but keep it to a clause in the actual reply.
  3. If section 4 keeps producing the same missing data, that is your next tracking ticket.

Questions about this prompt

When do I use this rather than answering the question?

When the framing already contains an answer, or when the data you hold cannot support one. Answering straight either endorses the assumption or produces a hedged non-reply. This separates the decision they are trying to make from the question they typed, and those are frequently different things.

What do I need in front of me?

The question in the words it was asked, who asked and what they are deciding, the data you have and the data you do not. Writing down the decision before pulling anything usually changes the query. The missing data field is what stops the answer being quietly fabricated to fit the question.

What comes back?

The real decision in one sentence, the assumption the data does not support, the best available answer with its uncertainty stated, a better question if one exists, and a reply of 120 words or fewer that leads with the answer. Section two is the value, but it belongs in the reply as a clause.

What is the mistake that costs me here?

Sending section two as your reply. Correcting the framing at length reads as evasion whatever you intended, which is why the reply is capped and has to answer first. If section four keeps naming the same missing data, stop writing it as a caveat and raise it as a tracking ticket.