Many people assume that growth comes from finding answers faster. But in real work, the scarcer ability is often this: before the answer even appears, to see the place worth questioning. I have repeatedly found in my reviews that my least valuable output is usually not “getting the answer wrong,” but “not asking the right question in the first place”—a vague question drags the whole discussion in a meaningless direction.

A question is not better for being bigger, nor for being sharper. A good question should bring the discussion back from vague feelings to facts, and let people know what information to fill in next, what hypothesis to verify, and what trade-offs to make. It is neither a mere “isn’t this unreasonable?” nor a way to prove that the asker is smarter.

It is an exercise in returning your attention to reality.

Record the facts first; don’t rush to a conclusion

“I think this process is terrible,” “this project is being done wrong,” “I’ve been in a bad state lately”—these remarks can be starting points for observation, but they are not yet questions that can be discussed. They mix facts, interpretations, and emotions, so others find it hard to know where to respond.

First, write things down:

  • What happened? In what context and over what time range did it happen?
  • Who is affected? Is the impact waiting, rework, error, cost, risk, or a missed opportunity?
  • What result was originally expected? Where does the actual result differ from the expectation?
  • Which facts are already known? Which are only guesses?

For example, instead of only asking “why is delivery always slow,” you can first write down: how long each of the last three requirements took from confirmation to launch; at which stages the waiting happened; what missing information caused the rework; and which people had to repeatedly confirm the same thing. Only then does the question gain a boundary: which stage mainly stretches out delivery time, and which cause should we verify first?

A good question is never a philosophy problem detached from its context. It has a concrete event you can look back on.

Use four perspectives to break “the taken-for-granted”

People easily treat the system they have long lived in as a law of nature. To spot problems, you often need to deliberately look at the same thing from a different position.

The zeroing-out perspective: pretend you are seeing it for the first time

Ask yourself: if I didn’t understand these terms, this history, and these default rules, would I still understand it? Why must it be done this way? Whom does this step serve?

Zeroing out is not denying experience; it is temporarily not letting experience skip the explanation for you. Many inefficient processes persist only because everyone who joins learns to adapt, yet no one re-examines whether they are necessary.

The user’s perspective: who is paying the cost for this design

Ask yourself: what does the person who actually has to finish the task want? What must they understand, wait for, switch between, fill in, or risk?

This rewrites “is the feature complete” into “is the task actually getting done.” The same applies to work collaboration: a status update that looks thorough does not mean the recipient can make a decision based on it.

The owner’s perspective: do goals, resources, and costs match

Ask yourself: if I had to be responsible for the outcome, what would I worry about most? Which constraints cannot be ignored? If resources were cut in half, what would still have to be done?

The owner’s perspective requires putting local good and bad into an overall trade-off. It is not about overstepping to decide for others, but about helping yourself understand why a seemingly imperfect option may still be the reasonable choice right now.

The bystander’s perspective: argue against your own narrative

Ask yourself: if I hadn’t made this, would I accept this explanation? Are there facts I have omitted, alternative explanations, or unfavorable evidence?

The hardest part of self-review is not finding an elegant justification, but allowing your own judgment to be overturned by the facts. Only by leaving room to argue against yourself can you avoid treating the conclusion as the starting point.

All follow-up questions unfold along two main lines

On the surface, questions come in countless forms; in reality, most valuable follow-up questions are doing one of two things: comparing, or seeking cause and effect.

Use comparison to find differences

Comparison keeps “good,” “slow,” “complex,” and “effective” from becoming adjectives with no standard.

  • Compared with expectations, where exactly does the present fall short?
  • Why do two types of users, two stages, or two approaches produce different results?
  • Between a case that went well and one that went poorly, what is the key difference?
  • Compared with the alternatives, what do we lack, and what costs have we avoided?

Comparison is not about finding an external benchmark to negate yourself, but about establishing a yardstick for judgment. Without a yardstick, a question is often just expressing a preference.

Use cause and effect to find leverage

Causal inquiry is not mechanically asking “why” five times in a row, but breaking a result into a chain that can be examined.

  • Which stages together produced this result?
  • Which stage is the root cause, and which is merely a surface symptom?
  • If we change this stage, will the later result actually change with it?
  • If left unaddressed, what consequences will it bring?

When the causal relationship is still unclear, the best question is not to demand an answer immediately, but to articulate the unknown clearly: what evidence are we missing? How can we verify it next time?

Compress big propositions into actionable questions

“How do we improve efficiency,” “how do we manage well,” “how do I grow”—these are all too big. They can point toward long-term exploration, but they cannot directly guide the next step.

You can compress them with a simple sentence pattern:

In what context did who run into what obstacle, causing what impact; and what do we plan to verify or change?

For example:

  • Vague question: How do we improve team efficiency?
  • Actionable question: Unclear requirement boundaries keep appearing during review, causing later rework. Is it insufficient input, absent decision-makers, or missing acceptance criteria? Which one should we verify first?

Compression is not about making the question smaller, but about giving it an opening where you can start. A good question usually has three things at once:

  1. Specific: the object, context, and time range are clear;
  2. Judgable: there is evidence, counterexamples, or at least a standard to compare against;
  3. Actionable: once answered, it leads to a verification, a trade-off, or a next step.

If a question still doesn’t meet these three points, don’t rush to find the answer. Continuing to add facts and narrow the boundary is often more effective than widening the discussion.

Question the approach, not the person

Questions create pressure, especially when they point at failure, risk, or wasted resources. Effective questioning should keep the pressure on facts, assumptions, processes, and approaches, rather than landing on someone’s character.

Instead of “why didn’t you do it well,” you can ask:

  • What are we basing this conclusion on?
  • What is the definition and baseline of this metric?
  • Is there another explanation?
  • Whose problem does this approach solve, and what costs does it introduce?
  • If resources or time shrink, which parts must be kept?

These questions won’t automatically make the discussion easy, but they let people focus their energy on the shared object to be solved. A good question can be sharp, but it shouldn’t corner the other person into a position where they can only defend themselves.

Keep a list of “unknown questions”

Answers expire; the question list is never wasted. What it records is not failures, nor to-do items, but the places not yet understood.

You can keep recording three kinds of questions:

  • Problems that keep recurring yet are always patched up temporarily by people;
  • Problems whose results look good but whose effectiveness can’t be explained;
  • Problems taken for granted whose cost and boundary can’t be explained.

Each week or each stage, pick one or two to revisit: add facts, delete pseudo-questions, extract the genuinely unknown part, then decide whether to keep observing, discuss with someone, or run a small verification.

The value of this list is not in immediately clearing every item to zero. It reminds us which places we still can’t make sense of, and which conclusions hold only for now. Only by acknowledging the unknown do we get the chance to truly widen our range of judgment.

A fifteen-minute exercise

Pick something recent that made you uncomfortable, confused, or caused repeated rework, and write down the following in order:

  1. Write only the facts: what happened? Don’t write evaluations.
  2. Write down the difference between expectation and reality.
  3. Re-describe it from any one perspective: zeroing-out, user, owner, or bystander.
  4. Write one comparison question and one causal question.
  5. Rewrite one of them as a “context—obstacle—impact—next step” sentence.

After finishing, check: is it specific enough? Can it be overturned by evidence? Would the answer change your next action? If so, this is a question worth keeping.

Asking good questions doesn’t mean you’ll never hesitate again. It just keeps hesitation from lingering in vague anxiety, and turns it into a path that can be observed, discussed, and advanced together.