How to choose the next question in a hard decision, and when to stop asking

To choose the next question in a hard decision, ask the one whose answer could most change what you do, weighed against what it costs in money, time and risk. Keep every rival explanation open, including “something else.” Redraw the list after every answer. Stop only when no question left is worth what it costs to answer and the method’s other stop checks pass, and have a named person sign off before anything you cannot undo.

That is how the Of One method asks. Its three moves are Ask, Map, Move: ask the questions that could change the decision, map what you find, and make the move the map supports. This guide covers Ask: how the method picks the next question, and how it knows when to stop.

Start with your decision

You have a choice to make, a deadline, and more open questions than time. Some questions feel urgent. Some are easy to answer. Some are what everyone else asks. None of that tells you which one to ask first.

This guide carries one example the whole way through. It is invented to show the steps; it is not a real business.

The decision. A founder has six months of cash and two customers asking for new features. The founder writes most of the code and the product ships slowly. Should they hire their first engineer, and if so, as an employee or a contractor?

Think like a good doctor

of1.ai explains the method with one picture: a good doctor. It is an analogy, and it rests only on what everyone expects of one.

A good doctor keeps asking what else it could be. They order the test whose result would change the treatment. They stop testing when no result would change what they do. And they ask for your consent before anything that cannot be undone.

Of One asks the same way. Keep every explanation on the table. Run the test that would change what you do. Stop when nothing else would. Sign off before anything you cannot undo.

The map comes first

A question is only good relative to what you already know, so the method builds a map before it chooses. Its premise is that underneath every field, from a shop to a lab, a decision has the same shape: the words change, the structure underneath does not. Its design maps each field onto the same ten building blocks.

The practical way in is the eight starting questions. They are of1.ai’s own plain-language shortcut into the method’s twelve framing questions, which the skill says to ask “only at the resolution needed for the chosen mode.”

Here is the founder’s first pass, with a confidence mark on each answer.

Starting question	The founder’s answer	Confidence
Decider: who makes the decision?	The founder, who signs any offer	High
Goal: what outcome do they want?	Ship the next version without the founder writing all the code	High
Facts: what is true right now?	Six months of cash; two customers asking for features	High
Limits: what are the hard limits?	A set salary ceiling; the hire must start within 60 days	Medium
Levers: what can they actually change?	Role scope, contractor or employee, equity offered	Medium
Causes: what will shift the outcome?	Not sure why shipping is slow	Gap
Proof: how will you know it worked?	The next version ships on time, with the founder coding less than half the time	Medium
Timing: when must they decide?	Before the two customers’ renewal dates	High

Confidence stays in plain words: low, medium or high. Where you do not know, write a gap, not a guess. The method’s rule is “Do not fake numeric precision.”

Every gap gets a name

The gap on Causes is the most useful line in the table. The method writes each gap down as a named unknown, notes whether it blocks the decision and what resolving it would be worth, and never pretends a blocked decision is settled.

Naming a gap does two things. It stops you from treating a hunch as a fact. And it hands you your list of candidate questions.

The founder also writes down the rival explanations for slow shipping, and keeps all of them open:

A. Too few hands. There is more code to write than one person can write.
B. Everything waits on review. Finished work sits until the founder checks it.
C. Moving targets. The customers’ requests keep changing, so work gets redone.
D. Something else. A cause nobody has named yet.

Option D matters. Right after the question is bounded, the method’s loop declares its rival explanations, always with a slot for an unnamed one, so a surprise has somewhere to land instead of being forced into the nearest story.

The rule for the next question

For each open question, ask two things. How much could the answer change what you do? And what does it cost to get, in money, time and risk?

The skill scores unknowns on much the same terms: “which unknowns are worth resolving next, with impact, cost, time, and risk reduction.” Its question engine weighs each question against its cost, risk and delay, and adds a few more considerations: how well a question separates rival explanations, what it unlocks later, and whether it just repeats a question you already asked.

Two points keep this honest. First, a question can teach you a lot and still leave your choice where it was. In the engine’s words, “The most informative question is not necessarily the most decision-useful question.” Second, when the numbers would be made up, the method uses “bounded qualitative judgments when probabilities would be fabricated.” On paper, low, medium and high are enough.

The founder’s candidate questions, scored by hand:

Candidate question	Could it change the move?	Cost, time and risk	Verdict
What do similar engineers earn locally?	Low: the salary ceiling is already set	Low	Later
Is shipping slow because of coding time, or because work waits for review?	High: if it is review, a hire will not fix it	Low: one week of noting where work waits	Ask first
Would the two customers wait three more months?	Medium	Low cost, a small risk of sounding unsure	Ask next
Would a contractor do as well as an employee?	High	Medium: a paid two-week trial	After the first answer

The second question wins. It could flip the whole decision, and it costs one week of paying attention. It also separates explanation A from explanation B, which none of the others do.

Sometimes two questions are each better in a different way: one is cheaper, the other more decisive. The method keeps both on the shortlist rather than forcing a single rank. It also keeps an eye on “bridge” questions that score low today but open the way to a much better question tomorrow.

Redraw the shortlist after every answer

After a week, the founder’s notes (still invented) show that most finished work sat for days waiting for review. Coding time was not the main gap.

That one answer changes every row. Explanation B moves up. A moves down but stays on the list. The contractor question drops sharply, because a contractor would add more work to the same review queue. A new question appears: which changes truly need the founder’s review?

This is the method’s rule: “After each answer, recompute the landscape.” Its engine puts it more fully: “Every answer changes the state and therefore changes the question landscape.” Yesterday’s best question can be today’s waste of time.

When questions stop moving the decision, change tactics

Suppose the founder then asks two more versions of “how much time do I spend reviewing?” The answers barely move anything. That is a stall.

The method treats a stall as a signal to change the kind of question. When recent questions make too little progress, it “must change operators,” moving among:

Measurement: count something you have only estimated.
Causal contrast: ask why this happened here rather than there, or now rather than before.
Intervention: change one thing on purpose and watch what happens.
Source change: ask someone who sees the problem from a different place.
Model expansion: look for an explanation outside the current list.
Adversarial review: ask who benefits from a particular answer, or how the evidence could mislead.
Scale change: zoom in to one part, or out to the bigger picture.
Frame revision: check whether you are solving the right problem.

Repeating yourself does not count as progress. The protocol counts asking the same question in new words as a failure, unless new evidence, a new source of answers or a changed condition makes it truly different.

The founder switches to an intervention. For two weeks, they review only changes that touch billing or security. They also try a frame revision: perhaps the real decision is what to stop doing, and who to hire comes second.

When to stop asking

Most people stop when they feel sure. The method stops only when nothing still locks the answer. Its protocol blocks release while, among other things:

a question is still worth more than it costs;
an unknown that blocks the decision is neither resolved nor accepted by a named person;
a cause the decision rests on has not been traced down to solid ground (see Why until bedrock);
a contradiction that could change the decision is still open;
the decision is still too fragile, or more information could still materially improve it;
or the required challenge checks lack real answers.

Those checks are causal depth, frame challenge, model expansion, adversarial review, source independence, and a stopping counterexample: the condition that would reverse the decision, and the cheapest safe test for it. Mentioning a check does not count; it needs a qualifying answer with evidence. The Kill tests guide covers them.

The method also caps the number of rounds. Reaching that cap requires a reframe, an escalation, or a named person accepting the remaining risk on the record.

In the example, the two-week change shortens the wait for review. Stopping counterexample: if shipping slows again while review stays limited, the review explanation was wrong, and the decision reopens. The founder settles on a paid contractor trial for one scoped piece of work now, and holds the employee offer until the trial ends.

When the method stops, it writes down what it still does not know, what evidence would reverse the decision, and what new fact would reopen it. New facts later patch only the part of the map they touch.

Accepting a gap on the record

Some gaps cannot be closed in time. The founder cannot know yet whether both customers will renew even if the next version ships on time.

The method allows a gap that blocks the decision to stay open only if a named person accepts it, in a record that states their role and authority, a bounded scope and rationale, when the acceptance starts and expires, the evidence behind it, and the conditions that reopen it.

For the founder, that is one short note:

Who accepts: the founder, who makes the decision.
The risk: renewals are uncertain.
Scope: this hiring decision only.
From and until: today until the first renewal date.
Evidence: neither customer has said yet whether they will renew.
Reopen if: either customer asks for a price change.

Sign off before anything you cannot undo

Every move on the map carries a note on how reversible it is. The contractor trial is easy to end. A signed employment offer is much harder to take back.

The skill requires human review for decisions in areas such as legal, medical, financial, safety, employment and money. So the employee offer waits at a gate: the founder signs it by name, after reading the named gaps and the reopening conditions.

If you build AI assistants

The same rule gives an assistant a clear job: name the gaps, rank the questions, ask one, redraw, and repeat. The stop decision sits outside the assistant’s own say-so. The protocol is blunt: “Persuasive prose, confidence, elapsed effort, a plausible explanation, or a pass tag cannot authorize completion.”

The method comes with its own toolkit for this: a runtime that selects each question, records every answer with its source, and checks the stop conditions before any answer is released. An assistant cannot accept a risk on a person’s behalf; that record needs a named human.

The repo is open about what is still unproven. At its current freeze, 52 of the 90 predeclared benchmark runs are completed and locally reviewed, no aggregate scoring has been completed, and it says: “No performance or superiority claim is supported by this in-progress state.”

Do it today

Write the decision in one sentence, with a date.
Answer the eight starting questions. Mark each answer high, medium or low, and leave a gap where you do not know.
Turn every place you do not know into a named gap. List the rival explanations, and add “something else.”
For each candidate question, write how much the answer could change what you do, and what it costs in money, time and risk.
Ask the top question. Update the map. Redraw the list.
If recent questions change nothing, switch tactics from the list above.
Stop when no question is worth its cost, every blocking gap is closed or accepted by a named person, and the other stop checks above have real answers. Write down what would reopen the decision, and sign before anything you cannot undo.

The /ask/ tool walks you through the eight starting questions and, by a simple rule of its own, flags which open gap to ask about next. The full method is on the method page. Next, see what the answers become in What goes on a decision map.