You finish your proposal. You write up the solution. Then someone says "add an FAQ section" so people can understand it better.

So you think of a few obvious questions. You write quick answers. You attach it to the end of the document.

The FAQ becomes an afterthought. A courtesy. Documentation.

I write the FAQ before I finalize the solution.

Not after. Before.

The FAQ isn't for the reader. It's for me. It's the tool I use to pressure-test my own thinking before I walk into the room.

You can't write an FAQ without deeply understanding your solution.

Try it. Pick any proposal you're working on. Start writing questions someone might ask. You'll immediately find gaps—things you assumed, things you glossed over, things you hoped nobody would ask about.

The act of anticipating questions forces you to think through dimensions you would have skipped.

If you can't write a good FAQ, your solution isn't ready.

When you walk into a room with a proposal, people will have questions. Some will be hostile. Some will be genuinely curious. Some will be testing whether you've thought things through.

An FAQ doesn't just answer questions—it signals that you've considered the dimensions. Even when your answer is "we don't know yet" or "we're still figuring this out," the fact that you anticipated the question builds confidence.

The message: "I've thought about this from multiple angles. I'm not winging it."

This saves enormous time. Instead of spending the meeting surfacing questions, you spend it on the ones that actually matter.

To write a good FAQ, you have to put yourself in other people's shoes.

Each perspective reveals different concerns. Each concern stress-tests a different part of your solution.

This is what makes solutions anti-fragile. Not just surviving scrutiny—but getting stronger because you've already absorbed the pressure before it hits.

Step 1: List your stakeholders

Who will read this? Who will be affected? Who has veto power? Who will execute?

Step 2: For each stakeholder, ask: "What would make them nervous?"

Don't write the easy questions. Write the uncomfortable ones.

Step 3: Answer honestly.

Some answers will be confident. Some will be "we don't know yet." Some will be "this is a risk we're accepting."

All of these are fine. What's not fine is pretending the question doesn't exist.

Step 4: Let the FAQ change your solution.

This is the key step.

If you write a question you can't answer well, that's a signal. Maybe your solution has a gap. Maybe you need to do more work. Maybe you need to change the approach.

The FAQ isn't just documentation—it's a feedback loop.

Here's where most people get stuck: coming up with good questions is hard. You know your solution too well. You're blind to your own assumptions. The questions that would challenge you don't occur to you—precisely because they challenge you.

This is where AI becomes incredibly useful. Not for generating your solution—that's not the smartest use. But for generating questions about your solution? It's brilliant.

Here's why it works: even if the AI hallucinates or asks something irrelevant, it's still just asking you a question. You decide whether the question matters or not. You decide whether to answer it. There's no risk—only upside.

The prompt I use:

"Here's something I'm proposing: [paste your solution] Take on the persona of an experienced business mentor and leader. Ask me frequently asked questions that I need to answer about this so that I've taken care of making this anti-fragile."

Then just answer the questions that come through. Some will be obvious. Some will be irrelevant. But a few will hit blind spots you didn't know you had.

The AI doesn't need to be right. It just needs to ask. You do the thinking.

The earlier you write it, the more useful it is.

An FAQ written after you've committed is just documentation. An FAQ written while you're still forming the solution is a thinking tool.

I was working on a new process rollout. I thought I had it figured out.

Then I sat down to write the FAQ.

Question 3: "What happens if the system goes down during peak hours?"

I didn't have a good answer. I had assumed the system would be stable. I hadn't thought through the failure mode.

That one question changed the entire rollout plan. We added a manual backup process. We trained the team on it. When the system did go down two weeks later, we were ready.

The FAQ caught what I would have missed.

Stop thinking of FAQs as "frequently asked questions."

Think of them as "questions I need to answer before anyone asks."

The FAQ is not for your audience. It's for you.

It's a forcing function that makes your thinking sharper, your proposals stronger, and your execution more anti-fragile.

Do you use FAQs this way? What other thinking tools do you find useful?

~Discovering Turiya@work@life