Splitting a tangled problem into smaller questions

A tangled problem feels hard for one reason: its parts are knotted together, so no single piece seems possible to start. The way out is to make the knots visible. List what you do not know, group the questions that depend on one another and then choose the first question to answer. Each step is small enough to do in a single sitting, and together they turn a fog into a sequence of answerable questions.

This works best once the problem has been defined in plain words. Splitting an unclear problem only produces a longer list of unclear questions. When you know what the problem is and how you will recognize a solution, the questions become easier to write and easier to sort.

List what you do not know yet

Start by writing every question the problem raises, including ones that seem obvious or awkward. Include unknowns about facts, causes, options, costs, deadlines and constraints. A question written as a full sentence, such as "How many orders arrive in a typical week?", is easier to act on than a vague topic such as sales. Aim for a list you can see on one page, even if it runs to twenty or thirty items.

Mark each question by type. Some are facts you can look up or measure. Some need an estimate because the answer will not be exact. Others need a decision, which cannot be settled by searching at all. The distinction matters because a fact can often be checked quickly, while a decision requires a choice. Sorting the list this way often shows that many questions are quicker to settle than they first appeared.

Tangled problems often look bigger than they are because several kinds of unknown are mixed together. Questions about the past are usually answered by records, questions about the future need estimates, and questions about preferences need someone to decide. Separating these kinds makes each one easier to handle.

Write each question in a consistent format so the list is easy to compare. A question that begins with what, how many or when is usually easier to check than one that begins with why, which tends to open a broad discussion. Keep the why questions, but mark them as broader so they are not mistaken for quick checks. Include the questions you suspect are already answered, too. Confirming them takes little time, and it removes a source of doubt that can otherwise slow every later step.

Group related questions and map dependencies

Next, group questions that belong together. Questions about the same part of a system, the same person or the same time period usually form a cluster. Look also for dependencies, where one question cannot be answered until another has been answered. If question B needs the result of question A, draw an arrow from A to B on the list or write A above B so the order is visible.

A simple grouping test is to ask whether two questions would be answered by the same source or the same conversation. If they would, they probably belong together. A cluster with many dependencies has to be handled in order, while a cluster of independent questions can be handled in any order or by different people at the same time. Seeing both kinds of cluster helps you plan the work realistically.

Estimate the effort for each cluster roughly, using labels such as quick, half a day or a week. You do not need precision. The estimate shows which clusters will take the most attention and whether part of the work can be handed to someone else.

Watch for loops. Occasionally two questions depend on each other, which means neither can be answered first in its current form. When that happens, rephrase one of them with an explicit assumption, answer the rephrased version and check the assumption later. This keeps the work moving without pretending the loop does not exist.

Choose the question to answer first

Choose the first question by looking for the one that enables the most other questions and can be answered with the least effort. A question near the start of a dependency chain often gives the most progress for the time spent. Avoid starting with the most interesting question if it depends on several unknowns, since it tends to stall and leaves the rest of the list untouched.

Suppose a team cannot publish its monthly newsletter on time. Its questions might include how long each step takes, who approves drafts and whether the recipient list is current. The question about how long approval takes depends on another question. The team cannot time an approval until it knows who gives it, so "who approves drafts" goes first and "how long approval takes" follows it on the list. The recipient-list check depends on neither question, so it can be done at any point and can wait.

Give that first question a set period, such as one focused session, and stop when the period ends. If the answer is not in reach, record what you found and what made it difficult. That record often reveals a new question worth asking.

Once you have a first answer, update the list. Some questions will disappear, others will split into smaller ones, and new ones will appear. Treat the list as a working document and return to it after each answer rather than planning the whole sequence in advance. A plan revised after each result usually beats a long plan written before anything has been learned.

A practical closing habit is to write the next question at the top of the page before you stop working. The next session then starts with a question rather than a blank page, and the tangle stays manageable as you go. When the remaining questions are small enough to act on, the problem is no longer tangled, and the work has become a sequence of steps.