# Structured Problem Solving > The structured problem solving method used in strategy work, applied to any messy business question. Produces a closed problem statement, a mutually exclusive and collectively exhaustive tree, a day-one hypothesis written to be attacked, a workplan where every analysis is one that could change the recommendation, ghosted exhibits before the analysis is built, and a synthesis written answer first with titles that carry the argument. Enforces the standard that no claim reaches the page without a number, a source, or a visible label saying it is an assumption. Use this skill whenever someone asks to think through a problem, structure an argument, compare options, build a recommendation or a business case, size something, work out why a metric moved, or says their chief executive asked them to look into something, to have a view by Friday, or to work out what is going on with a number. Trigger on any vague business question, which is exactly what it exists to structure. - Skill: `ingridleiria/structured-problem-solving` (Agent Skill) - Install (CLI): `npx skillmds@latest add ingridleiria/structured-problem-solving` - Raw SKILL.md: https://api.skillmd.com/api/skills/ingridleiria/structured-problem-solving/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ingridleiria (https://skillmd.com/u/ingridleiria) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ingridleiria/structured-problem-solving --- # Structured Problem Solving A leader asks a vague question. Three weeks later a document arrives that describes the situation in careful detail, sizes four things nobody asked about, and stops short of an answer. The decision is then taken in the meeting anyway, on instinct, by whoever speaks with most confidence. The three weeks bought nothing except the feeling that the question had been taken seriously. The cost is rarely the analyst time, though that is real. The cost is that the next vague question goes to someone else, or to nobody, and the organisation quietly learns that asking for analysis delays decisions rather than improving them. The opposite failure is cheaper to spot and just as expensive: an answer produced in an afternoon with no structure behind it, confidently delivered, which nobody can check and which falls apart the first time a chief financial officer asks how the number was built. This skill is the thinking layer the rest of the operating work sits on. The craft is not the frameworks. It is the sequence: find the real decision, structure the problem before touching data, commit to an answer early so the work has something to attack, and then spend effort only where the result would change what you recommend. ## When to use this, and when not to Use it when the question is open and the answer matters: why a metric moved, whether to enter a market, whether a cost line is fixable, what to do about a competitor, how big something could be, whether a plan holds. Use it when the request arrives as a topic rather than a question. Use it when several people already have strong and incompatible views, because the structure is what makes the disagreement locatable. Do not use it when the decision has already been taken and the analysis is being commissioned to justify it. Say so instead; that conversation is short and saves weeks. Do not use it when the answer is a single data pull with no judgement in it, which belongs in `spreadsheet-analysis-workbook` or `revenue-analysis-workbook`. Do not use it to gather external facts, which is `market-research` for markets and competitors and `external-insights` for a specific company or person. Do not use it to run the work once the decision is made, which is `program-management`. The boundary with `decision-memo` matters most. This skill produces the analysis and the argument. `decision-memo` is the one page that carries a choice to a named decider with a date. Most substantial pieces of work use both, in that order. ## What you need before starting **The decision and the decider.** One name, and what they are choosing between. Missing: ask directly, in those words. If nobody can answer, that is the finding, and it changes the work from analysis to getting the decision rights settled. **What would change their mind.** Missing: ask it as a question, "if the numbers came back the other way, what would you do differently". If nothing would, the decision is already made and the honest contribution is to say so rather than to build the analysis that dresses it up. **The deadline and what it is attached to.** A board meeting, a renewal, a hiring decision. Missing: propose a date and say what depends on it. Work without a date expands until it is a description. **The constraints already fixed.** A budget cap, a hiring freeze, a commitment made to a customer, a preference the chief executive has expressed in a way nobody will contradict. Missing: ask, and ask a second person. Analysis that ignores a fixed constraint is theatre, and doing it anyway costs credibility that is needed later. **Access to the underlying numbers.** The finance system, the customer database, the warehouse, or the person who exports from them. A connected reporting tool or database is useful here for pulling the raw series rather than a summary somebody prepared for another purpose. Missing: work from whatever exists, state the vintage of every figure, and never quote a number to more precision than its source supports. If nothing is available, invert the analysis and work in the "what would have to be true" mode described in step 5. **Whatever has already been done.** Half-finished models, an old board paper, a team member's analysis from last year. Missing: ask twice, because the second answer is usually where the previous attempt turns up. Repeating work that already exists is the most avoidable waste in this discipline. ## The method ### 1. Find the decision Nobody wants analysis. They want to stop being unsure about something they have to do. Before anything else establish: who decides, what they are choosing between, by when, what they are afraid of, and what would change their mind. That last question is the important one. If nothing would change their mind, the decision has already been made and the honest contribution is to say so rather than to build the analysis that dresses it up. Also establish the constraints already fixed. Analysis that ignores a fixed constraint is theatre. ### 2. State the problem as one question One sentence, closed, with a decision attached and a time bound. "Should we move support to a follow-the-sun model before the next renewal cycle" is a problem statement. "Support coverage" is a topic, and topics produce documents rather than decisions. The classic frame for setting it up in writing is situation, complication, question. The situation is what everybody already agrees on. The complication is what changed to make it a question now. The question follows from the complication and should feel inevitable by the time the reader reaches it. If the question does not follow from the complication, one of the two is wrong. Test the statement: is it specific, is the answer measurable, is it actionable by the person deciding, and is it bounded in time. A problem statement failing any of these will produce work that cannot conclude. ### 3. Structure before you gather Break the question into parts before looking at any data. Three kinds of tree, chosen by the shape of the problem. **The driver tree** decomposes a number into what arithmetically produces it. Profit into revenue and cost, revenue into volume and price, volume into customers and frequency. Use this whenever the question is about a metric moving. It is the least arguable structure because arithmetic guarantees completeness, and it points straight at where the movement actually came from. **The issue tree** decomposes a decision into the questions that must be answered to make it. Each branch is a question, each level answers how or why for the level above, and a branch is finished when it can be settled with evidence somebody could actually get. **The hypothesis tree** starts from a proposed answer and decomposes it into the things that would have to be true for it to hold. Use this when there is enough experience in the room to have a real view, which is more often than people admit. The choice rule: if the question is about a number that changed, use a driver tree. If the question is a decision with several defensible answers and no strong prior, use an issue tree. If somebody credible already has a view, use a hypothesis tree and test their view first, because it is either right, in which case you are finished early, or wrong in an instructive way. Whichever you use, the branches must be mutually exclusive so that work is not duplicated and effects are not double counted, and collectively exhaustive so that the answer cannot be hiding in a gap. Both matter, but exhaustive matters more: overlapping branches waste effort, missing ones produce a wrong answer. Two warnings. A structure that is neat but does not correspond to how the business actually works is decoration, and it is recognisable because every branch has exactly three sub-branches. And a borrowed framework is not a structure. Reaching for a named framework before understanding the problem is the most common substitute for thinking in this discipline. ### 4. Write the day-one answer Before the work starts, write the answer you would give if forced to answer this afternoon, in one sentence, with the reasoning. Then treat it as something to be destroyed rather than defended. This feels wrong and it is the single highest-leverage habit in the method. A stated hypothesis makes the work directed: every branch becomes a test rather than an exploration, and it becomes obvious which analyses are irrelevant. Without it, work expands to fill the time and arrives at a description. The discipline is falsification. For each branch ask what evidence would prove the hypothesis wrong, and go and look for that first. Confirmation is cheap and available for any hypothesis. If the hypothesis survives a serious attempt to kill it, it is worth recommending; if it dies in week one, that is the fastest possible outcome, and the next hypothesis is usually better because it was written by someone who now knows more. Say out loud how confident you are and on what basis. Hypothesis, working answer, and conclusion are different states and should not be reported in the same tone. ### 5. Prioritise by what would change the answer Not every branch deserves work. For each one ask: if this came out at the extreme of its plausible range, would the recommendation change? If no, it does not need analysis, it needs a stated assumption and a footnote. Order the remaining branches by how much they move the answer against how hard they are to settle. Do the high-movement, low-effort ones first, because they often collapse the tree, and a branch that resolves the question makes three others unnecessary. Where a branch cannot be settled with available data, invert it: instead of asking what is true, ask what would have to be true for the recommendation to hold. Then judge whether that is plausible. "This works if we can hold churn under three percent, which we have never done" is a real finding and it took an afternoon, not a month. ### 6. Ghost the exhibit before doing the analysis For each analysis, sketch the chart or table you expect to produce, with the axes labelled and the shape you think the result will take. Then ask what you would conclude if the result came out the other way. If the answer is the same either way, do not do the analysis. This one habit removes most wasted work. It also surfaces, before the effort, whether the data you would need actually exists. Keep the exhibits plain. Monochrome first, series separated by marker shape and dash pattern rather than by colour, legend outside the plot area, and an accent colour used once, on the series carrying the finding. A chart that only works in colour will be printed, photocopied, or projected badly at exactly the moment it matters. Then write the workplan: for each branch, the analysis, the source, the owner, the end product, and the date. The end product is a specific exhibit, not "research". ### 7. Analyse with proportion Start with the back of the envelope. Get the order of magnitude before the decimal places. A calculation on one page that lands within twenty percent of the right answer, done today, is worth more than a model finished in three weeks, and it tells you whether the precise version is worth building. Triangulate anything important with a second method built from different inputs. Where two independent approaches agree you can move on; where they diverge, the divergence is usually the insight. Sanity check everything against something known: a comparable company, last year, a physical constraint, a per-head figure a person in the business would recognise. Numbers that survive no reality check are how a wrong answer travels a long way. Do not report more precision than the inputs support. A market sized to the nearest million from three assumptions is a claim about the assumptions, and stating it as 47.3 million dollars invites a conversation about the wrong thing. ### 8. Synthesise, do not summarise A summary says what was found. A synthesis says what it means together, and it is where most of the value in the work is either created or lost. Build the answer as a pyramid. One governing statement at the top, which is the answer to the question, supported by a small number of arguments that do not overlap and together are sufficient, each supported by evidence. Read upward and each level should answer "why should I believe that". Read downward and each level should answer "so what". Group either deductively, where each point leads to the next and the conclusion follows, or inductively, where several findings of the same kind support one statement. Do not mix them inside one group; that is what makes an argument feel slippery without the reader being able to say why. Apply the so-what test to every finding, repeatedly, until it reaches something actionable. "Churn is 4 percent monthly" becomes "churn is concentrated in accounts under ten thousand dollars a year, which are also the accounts we onboard without a human", which becomes "the cheapest lever available is onboarding, not the product roadmap". The first version is a fact, the last is a recommendation, and the distance between them is the work. ### 9. Write answer first The recommendation is the first sentence. Then the reasoning. A reader who agrees can stop; a reader who disagrees now knows exactly what to argue with. Background before the answer is a habit borrowed from academic writing and it does not survive contact with a leadership team's calendar. Titles carry the message. "Revenue by segment" is a label; "Growth is entirely in mid-market, and enterprise has been flat for six quarters" is a finding. A reader who reads only the titles, in order, should get the argument. If they do not, the argument is not there yet. The executive summary stands alone and is written last. Situation, complication, the answer, the two or three things it rests on, and the ask. The elevator test: the whole answer in thirty seconds, out loud, without notes. Failing it usually means the governing statement is not settled, and no amount of formatting fixes that. ### 10. Attack it before someone else does Write the strongest objection a sceptical executive would raise, in their words, and answer it inside the document. If the objection survives the answer, change the recommendation rather than the wording. Then check for the failures this way of working is prone to: analysis that could not have changed the recommendation; a framework applied instead of thinking; branches that are neat rather than true; false precision; a recommendation that is not a decision anyone can take; a single option presented as a choice; risks described as "execution risk" rather than as specific things that could happen; and vocabulary doing the work of evidence. Alignment, synergies, holistic, best in class, unlock, and drive impact are all banned unless attached to a number or a mechanism. ## Worked example **Situation.** Meridian Freight Systems, a 220-person logistics software business, had seen gross margin fall from 71 percent to 63 percent across five quarters while revenue grew from 39 million dollars to 48 million dollars. All figures in this example are US dollars. The chief executive asked the chief of staff to "look into margin" ahead of a board meeting nineteen days away. The finance team had already produced a variance pack that showed cost of goods sold rising faster than revenue, which everybody had read and nobody could act on. **Task.** The board would be asked in that meeting to approve a plan that assumed a return to 70 percent gross margin within four quarters. The real question was whether that assumption held, and if not, what to change. Good meant an answer the chief financial officer would defend under questioning, delivered before the pack went out, which was eleven days away rather than nineteen. **Action.** The decision was found first, and it was not the one in the request. The chief executive did not want an explanation of margin. She wanted to know whether to sign the plan as written, and she said that the thing that would change her mind was evidence that the margin loss was structural rather than a phasing effect. That reframed everything: a phasing story meant sign the plan, a structural story meant rebase it. The problem statement became: does the fall from 71 to 63 percent reflect a permanent change in delivery cost per unit of revenue, or a timing effect that reverses without intervention, and which levers close the gap by the fourth quarter of next year. Because the question was about a number that moved, the structure was a driver tree. Cost of goods sold, 17.8 million dollars in the trailing twelve months, split four ways: hosting and infrastructure 3.4 million, customer support 4.1 million, implementation and delivery labour 7.9 million, third-party data fees 2.4 million. The day-one answer, written before any data was pulled, was that usage-based hosting costs had grown faster than the contracts that generated them, because two large customers had moved to high-volume plans priced before the current infrastructure costs. That hypothesis was plausible, widely held in the leadership team, and wrong. The wrong turn worth recording: two days went into scoping a per-tenant hosting cost model, which would have taken a further eight or nine working days and required a data engineer who was already committed elsewhere. Ghosting the exhibit killed it. The sketch was a bar chart of hosting cost per tenant against contract value, and the question asked before building it was what would be concluded if the chart came out flat. The answer was uncomfortable: hosting was 3.4 million dollars of 17.8 million, so even a 30 percent overrun on the whole line explained about 1.1 points of margin against a gap of 8 points. The analysis could not have changed the recommendation whichever way it came out. It was abandoned on day three. Attention moved to the branch that was arithmetically capable of carrying the answer. Implementation and delivery labour had gone from 3.1 million dollars to 7.9 million dollars while revenue grew 22 percent. Two analyses settled it, both done in a day and a half. The first was delivery hours per new contract by quarter, which rose from a median of 210 hours to 470. The second was the mix of contract types: the bundled fixed-fee offer introduced eighteen months earlier now carried 61 percent of new bookings, and it included implementation with no hour cap. A third analysis, a comparison of delivery hours by customer segment, was ghosted and skipped because both possible outcomes led to the same recommendation. Triangulation came from outside finance: the head of delivery kept a staffing spreadsheet showing billable utilisation falling from 74 percent to 51 percent over the same period, because the team was absorbing work that had previously been billed. Two independent routes to the same finding. The synthesis had one governing statement: the margin loss is structural, it sits almost entirely in uncapped implementation delivery inside the bundled offer, and the plan's 70 percent assumption does not hold without repricing that offer. Three supporting arguments, each with one exhibit. The strongest objection, written in the chief financial officer's voice, was that delivery hours would fall naturally as the product matured. It was answered with the quarterly trend, which was still rising in the most recent quarter, and with the observation that the two largest implementations were both on the newest product version. **Result.** The plan went to the board rebased, with gross margin assumed at 67 percent rather than 70, and with a repricing of the bundled offer to include a 250-hour implementation cap as the named lever. The board approved it with one change: they asked for the cap to be tested on new logos for two quarters before being applied at renewal. Two quarters later gross margin was 66.8 percent, consistent with the rebased plan and short of the original assumption. Whether the repricing closes the remaining gap is not yet known; the first cohort of capped contracts was too small to read. What is known is that the board did not approve a number the business could not deliver. The work took nine working days including the abandoned hosting model. Without the ghosting step it would have taken about eighteen and produced a chart explaining one point of eight. ### A second scenario, where it goes differently The same chief of staff was asked six months later whether the company should open a delivery office in a second country. There is no number that moved, no arithmetic decomposition, and almost no internal data, because the company has never done it. The structure changes to an issue tree with four branches: is there enough demand in the region to sustain a team, can the delivery skills be hired at a cost that improves the margin picture rather than worsening it, what the entity and compliance overhead costs in the first two years, and what breaks in the operating model when delivery is not co-located. Three of those four cannot be settled with data the company holds. So the method inverts, as step 5 allows. Instead of asking what is true, the work asks what would have to be true: the region needs to produce at least 2.4 million dollars of delivery revenue by year two to cover the fixed overhead, which means roughly fourteen new mid-market contracts, against a current run rate in that region of two a year. That is the finding, and it took four days rather than nine. What changed is not the sequence. It is that the evidence available cannot support a confident recommendation, so the deliverable is a set of conditions and a threshold rather than an answer, and the document says so in its first sentence. Presenting a confident recommendation from that evidence base would have been the failure. ## Output The working artefacts, in order, then the document. **Problem definition block**, agreed with the sponsor before any analysis: ``` DECISION: [what is being chosen between, and by whom] DECIDER: [one name] BY: [date, and what it is attached to] WOULD CHANGE THEIR MIND: [the evidence that would move them] FIXED CONSTRAINTS: [budget, commitments, stated preferences nobody will contradict] QUESTION: [one closed, time-bound sentence] SITUATION: [what everyone already agrees on] COMPLICATION: [what changed to make this a question now] DAY-ONE ANSWER: [the answer if forced to give one today, in one sentence] CONFIDENCE: [hypothesis / working answer / conclusion] because [basis] WHAT WOULD DISPROVE IT: [the evidence to go and look for first] ``` **Workplan table**, one row per branch that survived prioritisation: | Branch (as a question) | Would an extreme result change the recommendation? | Analysis | Source | Owner | End product (the exhibit) | Due | |---|---|---|---|---|---|---| Branches that answer no to the second column stay in the table with the stated assumption written in the analysis cell, so it is visible that they were considered and dropped rather than missed. **Ghost exhibit**, one per analysis, before it is built: a sketched chart or table with axes labelled, the expected shape, the title as a finding rather than a label, and one line saying what would be concluded if the result came out the other way. **The document**, in this order: 1. Governing statement, one sentence, first line of the page. 2. Two or three supporting arguments, each as a title that states a finding. 3. Evidence under each, with the source and the vintage. 4. The strongest objection, in the sceptic's words, and the answer. 5. What we do not know, limited to unknowns that would change the answer. 6. The ask: what decision is needed, from whom, by when. Everything else is an appendix. Where the output is a choice for a named decider, hand it to `decision-memo` in that format rather than reformatting it here. ## Failure modes **The framework reached for before the problem is understood.** Recognisable because the structure would fit any company in any industry. Fix by decomposing the actual arithmetic or the actual questions, then checking whether a named framework happens to match. **The tidy tree.** Every branch has three sub-branches and the levels are all the same depth. Real businesses are lumpy. Fix by testing each branch against someone who does the work: ask them where the money actually goes and see whether your branches appear in the answer. **The day-one answer defended instead of attacked.** Recognisable when every completed analysis supports the original hypothesis. Fix by assigning the falsifying evidence first, and by writing down in advance what result would kill it. **Analysis that could not have changed the recommendation.** The most expensive failure and the easiest to prevent. Recognisable in hindsight because the finding appears in an appendix and is never referenced. Prevent it with the ghosting step. **Precision that outruns the inputs.** A number carried to three significant figures from two assumptions. Recognisable because the discussion becomes about the number rather than the decision. Fix with ranges and a stated confidence. **The summary wearing a synthesis costume.** Recognisable because the section titles are labels, and reading only the titles gives you a table of contents rather than an argument. Fix by rewriting every title as a sentence with a verb in it. **Vocabulary standing in for evidence.** Alignment, synergies, unlock, best in class. Recognisable by deleting the word and seeing whether the sentence still says anything. Fix by attaching a number or a mechanism, or cutting the sentence. ## Edge cases **The decision has already been taken.** Say so in the first conversation, offer to write the announcement or the rationale instead, and do not run the analysis. The alternative is spending three weeks producing a document whose conclusion was fixed on day one, which everyone in the room will recognise. **The answer is needed today.** Compress to steps 1, 2, 4, and 9. State the problem, write the day-one answer, do one back-of-the-envelope calculation on the branch that could carry the whole answer, and deliver it labelled as a hypothesis with the two analyses that would confirm it. A labelled hypothesis delivered on time beats a conclusion delivered late. **No usable internal data.** Invert every branch into "what would have to be true", set thresholds, and judge plausibility against the closest comparable you can find. The deliverable is a set of conditions, not a recommendation. **The question is two questions.** Recognisable because the answer changes depending on which one you emphasise. Split them, answer the one the decider needs first, and say explicitly that the second is deferred and why. **The person who owns the data does not want the answer found.** Recognisable when requests take three weeks and arrive aggregated. Escalate the access, not the analysis, and in the meantime build the estimate from a second source so the absence of cooperation does not stall the work. Say in the document which figures came from a secondary route. **The real problem is a people problem.** A structure will not fix a disagreement between two leaders about who owns something. Name it plainly in one line, hand the decision-rights question to whoever can settle it, and analyse only the part that is genuinely a question about the business. ## Quality bar - The decision, the decider, and what would change their mind are written down before any analysis begins. - The problem is one closed, time-bound question, and the complication makes it inevitable. - The structure exists in writing before data is gathered, and its branches neither overlap nor leave gaps. - A day-one answer was written, and the first evidence sought was the evidence that would kill it. - Every analysis in the document would have changed the recommendation if it had come out the other way. - Important numbers are triangulated by a second method built from different inputs and sanity checked against something known. - The titles alone, read in order, carry the argument. - Every claim has a number, a source, or an explicit label saying it is an assumption. ## Adapting this to your context The worked examples, the vocabulary and the pyramid write-up come from commercial strategy work delivered to a leadership team on a horizon of days to a few weeks. The sequence generalises; the evidence conventions do not. - **The decision, the decider and the date.** Where the decider is a board, a committee or a regulator, replace the single name with the body, and replace what would change their mind with the published criteria that body applies. - **The evidence standard.** In business, a triangulated estimate with labelled assumptions is enough. In clinical, regulatory, legal and academic work it is external and prespecified, so the ghost exhibit becomes a registered analysis plan rather than a sketch. - **Order of magnitude before decimal places.** Wrong wherever the decision turns on a threshold, a safety margin or a covenant. There the precision comes first and the range has to be defensible. - **The banned vocabulary.** Alignment, synergies and unlock are commercial filler. Every field has its own; find the words that survive deletion without changing the sentence, and ban those instead. - **What not to change.** Every analysis would have changed the recommendation had it come out the other way, and every claim carries a number, a source, or a visible label saying it is an assumption. ## Related skills `decision-memo` takes the output of this method and turns it into the one page that carries a choice to a named decider with a date and a default. `market-research` supplies the external sizing and competitive evidence that fills branches this method identifies. `external-insights` supplies the same for a single company or person. `executive-briefing` compresses the finished argument for someone walking into a meeting cold. `board-deck` is where a substantial piece of this work usually lands. `program-management` runs the initiative once the decision is taken. `meeting-to-decisions` catches the decisions that get made in conversation rather than through this method, and feeds the same log.