Turn Vague Feedback Into a Concrete Process Fix
When an employee or teammate says 'something's off' or 'this process feels messy,' most managers either brush it off or fix the wrong thing. Vague feedback carries a real root cause underneath it, but that root cause never shows up in the first sentence. The surface problem is 'the feedback is unclear'; the real problem is 'I jump straight to a fix without asking the questions that would clarify it, so I end up fixing the wrong thing.' This prompt doesn't target a customer complaint, it targets an INTERNAL process: it takes a team member's vague complaint, hands you the question set that clarifies it, walks the root cause chain step by step, and lands on a concrete, actionable process change. It fixes a breakdown in the work, not the product.
You are an internal process improvement and root cause analysis expert. Your expertise: taking a team member's vague, "something's missing" style feedback, narrowing it down to a root cause with clarifying questions, and turning it into a concrete process change. Your job is NOT to improve the product; it's to fix a breakdown in the work itself, without blaming anyone. You'll give me: - [VAGUE FEEDBACK: who said it, exactly what they said, in what context] - [PROCESS: what work/process this feedback relates to, briefly] - [IF ANY: other clues you've noticed about this before] - [TEAM SIZE: how many people work in this process, and what role the person giving feedback plays in it] RETURN THE OUTPUT IN THIS EXACT ORDER, WITH THESE EXACT HEADERS: === CLARIFYING QUESTION SET === 4-5 questions that narrow down this vague feedback. In order: when/where it happened, how it was noticed, who it affects, whether it's happened before. Each question should build on the answer to the one before it, not be listed at random. === POSSIBLE ROOT CAUSE HYPOTHESES === 2-3 possible root cause hypotheses that could shift depending on the answers to the clarifying questions. For each one, state which answer would confirm it and which answer would rule it out. === ROOT CAUSE CHAIN (5 WHYS LOGIC) === Starting from one "why" question, build a chain as deep as the given information allows. Each step should land on a more fundamental cause than the one before it. === CONCRETE CHANGE PROPOSAL === Based on the root cause found at the end of the chain, one concrete process change that can be tested at small scale. Not generic advice like "be more careful," a structural change; make clear who does what step differently, and when. === TEST AND VERIFICATION PLAN === How to test this change at small scale, how long to wait before checking the result, and what question to ask again. === IF THE CHAIN STOPPED IN THE WRONG PLACE === If, a week later, the person who gave the feedback says "still the same," what that means (the root cause chain may have stopped too early) and how to go one step further back. RULES: - Do NOT invent a root cause; don't state a cause as certain before it's been clarified, present it as a hypothesis. - Don't frame the person giving feedback in blaming language; look for the problem in the process, not the person. - Don't skip the clarifying questions and jump straight to a fix; don't propose a change before the root cause is clear. - Don't propose a large-scale restructuring; the change should be testable at small scale. - Write in natural, direct English, calm and constructive.
How to use it
- Write down the vague feedback exactly as it was given, word for word, without editing it. Add who said it and in what context; the same sentence from a different person can point to a different root cause.
- Actually ask the clarifying questions to that person, don't try to answer them in your head. The root cause chain only moves forward with real answers; guess and skip ahead, and you'll fix the wrong process.
- Test the change that comes out of the root cause chain in a small area first, don't roll it out everywhere at once. Check back with the same person a week later and ask if it changed; if it didn't, the chain stopped one step too early, go back further.
Example / tip
Input: a teammate said 'the order process gets messy sometimes,' nothing more. AI output (shortened): Clarifying questions, 1. When was the last time it got messy, which order, 2. How did you notice it was messy (an actual error, a delay, or just a feeling), 3. Who does this mess-up affect, you or the customer. Root cause chain, if the answer is 'I update the same order in two different systems separately, and sometimes one gets forgotten,' the shallow fix isn't 'be more careful,' the real root cause is 'there's no single point of update.' Change proposed: make one system the single source of truth instead of two, copy to the other automatically or manually from there, so updates happen from one place only.
Usage example
Copy the prompt as is, fill in the bracketed fields for your own business, and paste it into ChatGPT or Claude. The more concrete your input, the more useful the output. Take the first draft, ask for a one-sentence fix on whatever you don't like, then give it a final pass in your own voice.
When not to use it
This prompt is for internal process and team feedback; pulling product improvements out of customer complaints is a different job. For a serious performance issue, a disciplinary matter, or anything that could lead to termination, bring in your actual HR process and legal counsel where needed, separately from this.
Output quality checklist
- Do the clarifying questions actually dig toward the root cause, or do they stay on the surface?
- Does the root cause chain go one level deeper with every 'why,' or does it stop at the first answer?
- Is the proposed change concrete and testable at small scale, or does it call for a big restructuring?
- Does the recommendation actually target the internal process, not the product?
