Why Polished Answers Go to the Wrong Question

You may know this sequence from your own week.

1. A short request arrives with a deadline. For example: "Hi, can you put together a deck on improving our service process? Need it by Friday. Thanks."
2. You fill the gaps with your own guesses. Which service? Improve it for whom? Who will see the deck? You don't ask, because Friday is close, so you decide.
3. You build a polished output. Three days of slides, charts and recommendations.
4. The requester reviews it. They say, "This is great work, but it's not quite what we meant."

The problem is not effort or skill. The output started before anyone agreed on what the requester needs. Every guess in step 2 became part of the deck, and the requester only sees those guesses at the end, when they are hardest to change.

In this course, the need means the problem or question the requester wants the work to address. It is not the format they asked for. "A deck" is a format. The need might be "help the regional manager decide whether to change how complaints are handled."

When a requester says "not quite what we meant," listen to what they are pushing back on. It is rarely the quality of your charts or your writing. It is usually the framing: the question you decided the work was answering.

Say you built the service-process deck around speeding up response times for customers. The requester replies: "Actually, this is for our operations director, who wants to know whether we should move support in-house. Speed matters less than cost and staffing."

Your slides may be well made. But the audience was wrong, the decision was wrong, and the measures you chose were wrong. Fixing that doesn't mean adjusting a few slides. You have to rethink most of the deck.

The two kinds of feedback need different responses:

• Craft feedback ("tighten this slide," "add a source") means small edits on top of a sound base.
• Framing feedback ("this isn't the question we had") means the base itself needs to change.

This course aims to bring framing feedback to the start, when it costs a short email instead of three days.

A finished-looking deck makes wrong assumptions harder to spot and more expensive to undo.

It is harder to spot because polish signals confidence. When a requester sees clean slides and a clear storyline, they read the content as settled. A wrong assumption buried on slide 3, such as "the audience is frontline staff," passes as a decision someone already made. A rough one-page note with a line saying "Audience: frontline staff (assumed)" invites a quick "No, it's the director."

It is more expensive to undo because each hour you spend builds on the guesses before it. Once the framing changes, much of that work no longer fits.

Use the sliders to look at your own pattern. Set how many hours you usually spend before the requester sees anything, and roughly how much of that work you could keep if the framing turned out to be wrong. These are your estimates, not a benchmark. The point is to see how the hours at risk grow when the first check-in comes late.

Don't work slower. Put a short step before the real work:

1. Read the request for what it states, what it implies and what it leaves out.
2. Draft a few clarifying questions the requester can answer quickly.
3. Draft a one-page brief, a short document that states four things: the need (the problem to address), the audience (who will use the output), the decision it supports (what someone will choose or approve because of it) and the constraints (limits such as deadline, budget, scope or format).
4. Send it for confirmation and get a clear yes or a correction.
5. Then build.

AI helps with steps 2 and 3. It can draft questions and a brief in minutes, which you then trim and check.

Throughout the course we'll use the same sample request: an email asking for "a deck on improving our service process by Friday." If you have a comparable real request from your own role, such as a short ask from a client or manager with a deadline, you can use it instead. Pick one now and keep it handy for the coming lessons.

Before learning the new step, find where it was missing in your own work. Think of a recent request where the result came back with "not quite" or needed a big rework. Then trace it back:

• When did you open the slide tool, spreadsheet or document? That is when building started.
• What did you know for certain at that moment? Usually it was the topic and the deadline.
• What did you decide on your own? For example the audience, the purpose, the scope or the level of detail.

Here is an example. A project lead got "Can you pull together options for the client workshop?" on Monday. She spent Monday afternoon building a 20-slide options deck. On Wednesday the client said they only wanted a one-page agenda. Her building started Monday afternoon. What she knew was the topic and that a workshop existed. What she guessed was the format, the depth and that "options" meant strategy options.

Use the flip cards to practise. Then answer the question for your own case.

You'll paste parts of requests into an AI assistant in this course, so set the rules now.

• Use only the AI tool approved for your work. A free chatbot on your phone is not approved just because it's convenient.
• Follow your organization's rules on client-confidential information (anything a client has shared with you in confidence) and employee information (names, performance, personal details). If you're unsure what the rules are, ask before you paste anything.
• Even in an approved tool, share only what the task needs. To draft clarifying questions, the AI needs the shape of the request, not the client's name or the payroll figures.
• Anonymize where you can. Replace names with roles, clients with a general description and figures with rounded or placeholder values. You can also describe the situation in general terms.

For example, you don't need to paste "Maria Chen at Northfield Logistics says our 14 support agents are failing." You can write: "A client contact in logistics asks for a deck on improving their customer support process. The team is small." The AI can still draft useful questions from that.

In this course AI does the drafting. It produces lists of clarifying questions and first versions of the brief, fast. That saves time, but the AI doesn't know your requester, their politics, what was said in last month's meeting or what your firm has already promised.

So the split is clear:

• AI drafts: possible questions, a structure for the brief, wording options.
• You decide: which questions matter, what is fact and what is a guess, and what you send.
• You own what is agreed. When the requester confirms a brief, they're confirming it with you, not with a tool.

Here is a quick example. The AI drafts a brief that says "Deadline: Friday, owner: Operations team." The deadline came from the email. The owner was the AI's inference, a reasonable guess with no source. If you send it without checking, the requester may read it as something already agreed. Your job is to catch that and mark it as a proposal. Later lessons show you how.