Start by using the feynman technique for clients as a pre-meeting clarity test, then convert that clarity into project documents. Explain the work in plain language, identify where your explanation breaks, and write a short value statement, assumptions list, and next-step note. Carry that into kickoff as a shared definition of done, then reuse the same method when alignment drifts. The goal is not better wording alone; it is fewer scope surprises and cleaner decisions during delivery.
In client work, the Feynman Technique is not a way to sound smart by sounding simple. It is an understanding check. Can you explain the claim, the assumptions behind it, and the limits of the work in terms the client actually understands?
That distinction matters. Many project problems do not start with bad intent. They start with hidden assumptions, soft boundaries, and a version of "yes" that does not hold up once the work begins.
The useful version is simple. You take a complex idea, explain it plainly, and watch for where the explanation breaks. If you cannot state the assumptions and core claim in understandable language, you do not have shared understanding yet.
That gap is where later disputes begin. A simplified explanation can feel smooth while still leaving out an important condition, such as what data was included, what exceptions were handled, or what "done" actually meant. The problem is not simplification itself. The problem is simplification that hides a boundary.
A common misuse is treating the technique as a comfort tool. You make a hard concept sound friendly, the client nods, and everyone moves on. That helps rapport, but it may not help delivery.
| Common use | Professional use |
|---|---|
| Objective | Make the client feel comfortable |
| Output | A neat metaphor or simple verbal explanation |
| Project risk impact | Confidence without verification |
The red flag is agreement that falls apart under a concrete follow-up question. If your explanation only works at headline level, the harder-to-test parts are still likely to break.
The better move is to turn that simplified explanation into artifacts you can check later, not leave it as a one-time conversation. After you explain the work plainly, create artifacts that still hold up when memory fades:
Take an API integration. "It connects your store and CRM" is too soft. A testable version is: "This sends new order data from checkout to the CRM. It maps these fields, runs on this trigger, and does not clean duplicate records or backfill old orders." Now you can check understanding. Ask the client to describe what will happen, what will not happen, and what they would expect to see when it is working.
If their answer adds features you did not name, stop there. That is not a communication-style issue. It is a scope-boundary issue.
The same check should happen before you send a proposal. If the explanation is still loose in private, it usually gets worse under sales pressure.
Related: Thailand's Long-Term Resident (LTR) Visa for Professionals. Want a quick next step? Browse Gruv tools.
Use this as your internal quality gate before you discuss scope or price: if you cannot explain the work plainly to yourself, you are not ready to pitch it.
Put three inputs on one page: your draft solution, your assumptions, and the business result you think the client wants. Then run a quick explanation pass for about 5 to 15 minutes. The goal is not polish. The goal is to expose vague thinking early.
Write one short paragraph that includes the definition, mechanism, one simple example, one real-world analogy, and where it fails. If you cannot state the failure point clearly, you are still selling a headline, not a working idea.
Mark every place where you stumble, hedge, or use vague language. Those are the exact points most likely to break in a sales call, proposal review, or kickoff.
Expected output: a plain-language offer statement you can reuse in your proposal. Example shape: "We help your team [do concrete thing] by [mechanism]. It works when [key condition]. It does not solve [known limit]."
Once the explanation is clear, pressure-test the boundary. Ask what a reasonable client could assume from your wording that you do not intend to deliver. Give yourself permission to doubt here: question your first draft instead of defending it.
Shallow clarity is a common trap. The explanation sounds simple, so you assume the scope is clear. Usually it is not. Write one sentence that states both what is in scope and what is not.
Expected output: an explicit in-scope/out-of-scope boundary line you can carry into the proposal and statement of work. Example shape: "This engagement covers [in-scope result]. It does not include [likely adjacent assumption]."
Your pricing is easier to defend when you tie it to a checkable result, not effort alone. State the business outcome, who owns that outcome on the client side, and what evidence would show it happened.
If you cannot name the owner or evidence source, run a second pass with targeted problem-checking for 20 to 60 minutes. Explanation and problem solving work together, and you need both before pricing conversations.
| Pitch quality | Business outcome | Owner | Evidence source |
|---|---|---|---|
| Weak | "Improve reporting and visibility" | Not named | Not named |
| Better | "Reduce manual reporting with one approved reporting view" | Reporting lead | Current vs future reporting steps |
| Strong | "[Team/owner] can answer [business question] faster. Add validated impact metric after verification." | Named | Named |
Expected output: an outcome-based price justification statement that connects your fee to a result the client can verify.
If you want a deeper dive, read GDPR for Freelancers: A Step-by-Step Compliance Checklist for EU Clients.
After your internal stress test, use the same discipline with the client as a delivery protocol. The goal is simple: keep the work tied to a real problem, break it into smaller parts, and document decisions so scope questions and change requests are easier to handle.
Use this protocol at three moments: before approval, at kickoff, and when alignment starts to drift. Each moment should leave one written artifact you can reuse later.
| Stage | Objective | Core question | Primary artifact | Risk prevented |
|---|---|---|---|---|
| Step 1 Proposal | Anchor the work to a real client problem | What problem are you solving in plain language? | Plain-language value statement in the proposal or SOW | Selling an approach without a shared outcome |
| Step 2 Kickoff | Turn the promise into a shared finish line | What does done look like, and what smaller parts lead there? | Shared definition-of-done note plus a written roadmap | Scope drift, skipped dependencies, vague approvals |
| Step 3 Realignment | Diagnose and document misalignment quickly | What does each side now think happens next, and why? | Written realignment summary after escalation | Informal scope expansion and weak decision history |
Before signature, start with the client's real-world problem, not your method. Ask: what business question should this work help them answer faster, more clearly, or with less friction?
Write one short value statement in plain language. Keep the mechanism clear and the boundary visible. Example: "We will give your team an approved reporting view so they can answer [business question] without rebuilding numbers each time." If you cannot explain the problem without jargon, refine it before sending the SOW.
Place that statement near the top of the proposal or statement of work, then reuse the same wording in project notes. Your checkpoint is whether the client can repeat the value in their own words.
At kickoff, move from "why this matters" to "what done looks like." Break the larger problem into smaller parts that build on each other.
Turn the value statement into a short roadmap. Use a list, flow diagram, or simple project plan. For each part, record the output, reviewer, in-scope boundary, out-of-scope boundary, and how acceptance will be confirmed. If criteria are still being validated, state it directly: "Add validated acceptance criteria after verification."
Send a definition-of-done note after the meeting. Include the parts, decision points, known exclusions, and how out-of-scope requests will be handled. If you skip a needed topic now, it usually returns later as a detour.
When confusion or scope tension appears, stop re-explaining and diagnose the mismatch. Ask the client to describe the next step and expected result in their own words, then compare that to the value statement and definition-of-done note.
After the call, send a short realignment summary: current objective, mismatch point, what stays in scope, what changes, what needs approval, and what belongs in a separate change request. Confirm it in writing, even with a brief email reply.
You might also find this useful: How to Manage Time Zones With Clients Without Being Always On.
If your clear explanation still does not land, stop rewording and switch to diagnosis. Your goal is to identify whether the gap is in understanding, scope, timeline, pricing, or ownership, then document the result.
A simple explanation can sound complete while still being shallow, so persistent confusion needs observable checks, not more confident phrasing.
Run a quick 5-15 minute reset in a single note. Include: definition, key mechanism, one simple example, one real-world analogy, and where the explanation stops being true or complete.
Mark where you stumble or use vague language. If you cannot explain it cleanly, tighten your own thinking first. If the explanation is clear but the client struggles to apply it, move to diagnosis instead of another summary.
| Observable signal | Likely issue category | Your next action |
|---|---|---|
| They can restate the goal but not what happens next | Explanation gap | Walk through one concrete example and a written step sequence |
| Questions keep returning to what is included | Scope disagreement | Compare the request to the agreed definition of done and exclusions |
| Discussion shifts to dates, dependencies, or launch windows | Timeline concern | Reconfirm milestones, dependencies, and what shifts if an input slips |
| Discussion keeps returning to cost or "small extras" | Pricing concern | Separate current scope from added work and prepare a formal change path if needed |
Use a technical analogy when the client already knows the domain terms and only needs the relationship clarified. Switch to a plain-language metaphor when terminology is the blocker.
If both fail, stop re-explaining and run neutral checks:
If the issue appears during real-world application, schedule a targeted 20-60 minute use-case review. Trying to force that into a rushed 10-minute conversation usually leaves too little time for clarifying questions.
After the call, send a short written recap you can reuse:
Get written confirmation, even if it is brief. If the work changed, route it through formal change control instead of leaving it in recap text.
For a step-by-step walkthrough, see The 'Pomodoro Technique' for Focused Work Sessions.
The point of this method is not better phrasing for its own sake. It is to catch confusion before it reaches the client. In your next engagement, use plain-language clarity as a checkpoint before anything client-facing.
Run the explanation test before the client call, not during it. Put the concept on paper and explain it in your own words as if teaching it. Mark the places where you get stuck or slip into complex terminology. Those are your verification points. If the explanation breaks, go back to your notes, source material, or examples before you present anything client-facing.
Turn the clear explanation into a short working brief. Put the one-sentence value, the next step, and key assumptions in writing. The checkpoint is practical: can the client restate the goal and what happens next? If not, do not use "seems clear" as a green light.
Use the same test when the work changes. Restate the update in plain language, then confirm the revised next step in writing. The common failure mode is easy to spot: everyone says they understand, but no one can describe what happens next.
What to carry into your next engagement:
Use the Feynman Technique to test whether the idea is actually clear. If you also need to structure the message itself, pair it with the Pyramid Principle.
Want to confirm what's supported for your specific country/program? Talk to Gruv.
It can reduce misunderstanding risk by replacing assumed understanding with explanations you can test. The technique is a learning method: when someone explains an idea in plain language, unclear areas become easier to spot. The next move is practical: go back to the material, fill the gaps you found, and explain again in simpler terms.
The intent is different. You are testing understanding, not talking down to anyone. The method is different too: you explain the idea in simple language, use an analogy if it helps, and listen for where the explanation breaks. That process makes knowledge gaps visible quickly.
Use it whenever a concept needs to be understood clearly, especially before important decisions. The checkpoint is not "that sounded clear." It is whether the idea can be explained simply and holds up under review. | Stage | Use it when | Primary artifact or checkpoint | | --- | --- | --- | | Step 1: Choose a subject | Before you start explaining | Clear topic selection | | Step 2: Explain to a child | While simplifying the idea | Plain-language explanation (and analogy if useful) | | Step 3: Reflect on gaps | After the explanation | Specific list of unclear points to revisit |
Ask each person to explain the concept and what it means in plain language. If those explanations differ, treat that as a signal that understanding is still uneven. Then return to the source material, close the gaps, and restate the concept in simpler terms until the explanation is clear and consistent.
Chloé is a communications expert who coaches freelancers on the art of client management. She writes about negotiation, project management, and building long-term, high-value client relationships.
Educational content only. Not legal, tax, or financial advice.
Start by separating the decisions you are actually making. For a workable **GDPR setup**, run three distinct tracks and record each one in writing before the first invoice goes out: VAT treatment, GDPR scope and role, and daily privacy operations.
For a long stay in Thailand, the biggest avoidable risk is doing the right steps in the wrong order. Pick the LTR track first, build the evidence pack that matches it second, and verify live official checkpoints right before every submission or payment. That extra day of discipline usually saves far more time than it costs.
Treat the **pyramid principle for client communication** as a practical rule: state the decision first, then support it with organized proof. When a client message buries the point, misunderstandings grow and create extra back-and-forth.