techwithtam/get-to-the-point

Get to the point

Rewrite a draft so a decision-maker understands the ask immediately.

Decision-makers have very little time. In the first few lines, they need to know what's happening, what's needed from them, and what their options are. Put that first and keep the supporting detail ready for questions.

The detail still matters, and the user must be able to speak to all of it. It belongs below the opening or in the likely questions.

Steps

1. Identify the decision-maker. Establish who will receive the message, what they care about most, how much detail they expect, what they need before they act, and who they report to. Use the draft and the user's description first, and ask only for what is missing. A detail-oriented decision-maker will question more, so prepare more answers for them. A decision-maker who briefs someone above them needs the main point in wording they can repeat. Done when you can state what they need before they can act.
2. Set one intent. Decide whether this message informs the decision-maker, explores options with them, or asks them to decide. Each one takes a different kind of thinking, and people need time to move from one to the next, so a message that asks for more than one is harder to answer. When the draft combines them, keep the one the user needs now and move the others to a separate message. When urgency compresses all three, keep them in order and set a time for each. Done when the message has one intent or a timed sequence.
3. Define the outcome. State the outcome the user needs from this message and why it matters, in precise terms. Ask the user if the draft leaves either one out. Done when you can finish this sentence from the user's facts: after this message, the decision-maker will...
4. Write the opening. Start with the conclusion. Aim for three specific sentences: what's needed, why it matters, and what happens without action. For a decision, the first sentence states the decision and the recommendation. For an update, the first sentence states what has happened, and the next two state what it means and what the decision-maker should be ready to do. Name the options in the opening or directly after it, with the implications of each. That is the level of detail a decision-maker needs to support a choice. Once they know the conclusion, they can evaluate the reasoning as they read. Without it, they read while trying to guess the conclusion. Done when the decision-maker could act on the opening alone.
5. Answer direct questions directly. When the decision-maker has asked a direct question, give the answer first and the conditions after it. A long conditional reply to a yes-or-no question reads as evasion, even when every condition is accurate, and it costs the user credibility. If the draft does not support a clear answer, ask the user for one.
6. Sort the detail. The opening may be all the message needs. Add below it only what this decision-maker needs to understand the ask and act on it, because any other detail distracts from the ask. Keep every condition or risk that would change the decision. Move the rest to the likely questions. Done when every fact from the draft appears in the message, in the likely questions, or under What changed.
7. Prepare the likely questions. List what this decision-maker is most likely to ask, with an answer to each drawn from the draft, including any contingency the user has planned. Decision-makers often test one detail to find out whether the user knows the work. The quality of the answer affects how much they trust the rest of the message. Calibrate each answer to the question, so a quick check gets a short answer and a serious challenge gets more detail. Done when each question has an answer or appears under Questions for you.
8. Edit for clarity. Replace jargon, acronyms, and buzzwords the decision-maker doesn't use, because they would have to translate each one. Keep the technical terms they use themselves. Split a long sentence when it carries several qualifiers, and keep whole, professional sentences. Remove hedges that don't change the meaning, because a hedged statement invites doubt even when it is correct. State real uncertainty once, where it affects the decision.
9. Check the medium. Match the medium to the intent, the urgency, and what the decision-maker expects. Information suits writing, and exploring options suits a conversation. A decision suits a meeting with the written background sent ahead. An urgent message in chat must hold everything the decision-maker needs, because they may have to act without a follow-up. If the user will present this in person, give them a few cue words for each point, because reading full notes while speaking weakens the delivery. Keep the user's medium unless it works against the intent, and tell them when it does.
10. State the next step. End with the specific action, its owner, and its date. Done when the message names who does what next.

Rules

• Use only the user's facts, preserve their voice, and mark anything you inferred.
• Ask the user for any missing date, figure, or owner.
• When the user wants more detail in the message because someone challenged them once, keep it in the likely questions. A challenge is routine, and the next one will be about something else.

Output

Return four parts in this order:

1. The message. The rewritten draft, ready to send.
2. Likely questions. Each question with its answer.
3. What changed. One line for each item you moved, split, or cut, so the user can restore it.
4. Questions for you. Anything the user needs to supply or confirm.

After the reply

When the user shares a reply or a meeting outcome, check that everyone knows what happens next. A partial answer is acceptable if it settles the next step. If it doesn't, draft a short, direct follow-up that asks for the next step and explains why the user needs it.

When the outcome is clear, draft a short record of the decision, the next steps, and their owners for the people affected. People forget or reinterpret a verbal agreement quickly, and the record gives them the same version to work from.

Examples

These examples are synthetic.

Not this	Do this	Why
Assuming the risks stay contained and the vendor responds in time, we should be in a position to deliver most of this by March.	Yes, we can deliver by March 1 if the vendor confirms access by Friday.	The question was yes or no. The decision-maker can weigh the condition once they have the answer.
Background, then analysis, then the recommendation on page four.	The recommendation in the first sentence, with the analysis below it.	Chronological order makes the decision-maker wait for the point.
We need to align on the go-forward approach for the migration.	Please approve the move to Clearline by May 15.	The request names the action, the subject, and the date.
A 30-row comparison of every vendor feature.	Clearline costs $18,000 a year more than Bellwether and is the only vendor that passed the pilot.	A decision-maker chooses between implications. The full comparison stays ready for questions.
What should we do here, and can you sign off today?	Here are the two options and what each one means. We need your decision on Friday.	The second version separates the options from the decision and gives the decision-maker time to weigh them.
SIP trunk porting is on the critical path.	The go-live date depends on moving our phone numbers, which takes 10 days.	A decision-maker outside the user's field would have to translate the first version.
Thanks, everyone. Great discussion.	We approved Clearline, and Nadia will give the current vendor notice by May 15.	The first version records nothing. The second names the decision and its owner.