Defining And Exploring Problems logo

Defining And Exploring Problems

Community
fatihguner
defining-and-exploring-problems

Teaches the discipline of correct problem definition and structured solution exploration before any evaluation begins. Covers the problem-solution firewall, root cause identification, the premortem, second-order thinking ('and then what?'), binary thinking traps, integrative Both-And options, and opportunity cost analysis through the 3-Lens Principle. Use when a team is jumping to solutions before understanding the problem, when a founder suspects they are treating symptoms rather than causes, when only two options seem to exist, when opportunity costs are unclear, or when first-conclusion bias is narrowing the solution space.

Overview

Publisherfatihguner
Repositoryforeman
Skill namedefining-and-exploring-problems
Stars
63
Forks
10
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by fatihguner on GitHub. Read the source before you install it.

Installation

Install the Defining And Exploring Problems AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/fatihguner/foreman/tree/main/plugins/foreman/skills/defining-and-exploring-problems
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/fatihguner/foreman.git /tmp/foreman
mkdir -p .claude/skills
cp -r /tmp/foreman/plugins/foreman/skills/defining-and-exploring-problems .claude/skills/defining-and-exploring-problems
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Defining And Exploring Problems in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Defining And Exploring Problems on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Defining And Exploring Problems is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Read runtime and advisory rules before applying this skill. Other Foreman layers and the catalog are in ../../content/, relative to this SKILL.md.

Defining and Exploring Problems

WRONG PROBLEM. Most failed decisions do not come from wrong answers -- they come from wrong questions. A room of intelligent people converges on a plausible-sounding problem statement within minutes, pivots immediately to solutions, and spends weeks executing against a target that was never the right one. The Clear Thinking framework calls this the social default: the collective instinct to accept the first definition everyone agrees on and move forward, because solving problems feels productive while defining them feels like stalling. The result is organisations that are perpetually busy and perpetually unimproved -- extinguishing flames that reignite because no one addressed the fire. Define the problem correctly and the solution often becomes obvious. Define it incorrectly and no amount of analytical sophistication will rescue the outcome.


The Framework

The process divides into two distinct phases -- defining the real problem, then exploring the full solution space -- and the single most valuable discipline is keeping them apart.

Phase 1: Define the Problem

The Definition Principle. Take responsibility for defining the problem yourself. Do not let someone else's framing become your framing by default. If you cannot explain the problem to a twelve-year-old without resorting to jargon, you do not yet understand it well enough to make a decision about it.

The Root Cause Principle. Distinguish the disease from the symptoms. The diagnostic question is deceptively simple: "What would have to be true for this problem not to exist in the first place?"

The text illustrates this with Downtown Dog Rescue in Los Angeles, where founder Lori Weise discovered that 30 percent of shelter dogs were owner surrenders -- families who loved their pets but could not afford to feed them. The obvious problem ("how do we get more people to adopt?") was the wrong problem. The root cause was economic hardship among existing owners. Solving for that reduced shelter intake by 75 percent at lower cost than housing the animals.

Three operational disciplines protect this phase:

  1. The Problem-Solution Firewall. Hold two separate meetings: one to define the problem, one to solve it. When both happen in the same session, type-A teams spend ninety seconds on definition and fifty-eight minutes on solutions. The question that unlocks the definition meeting: "What do you know about this problem that other people in the room don't know?" It forces participants to stop signalling with shared information and start revealing private information.

  2. The Test of Time. Ask whether a proposed solution will fix the problem permanently or merely defer it. If the problem will return, you are treating a symptom. Short-term fixes signal to others that action is being taken; they do not signal that progress is being made. Energy channelled toward short-term solutions depletes energy available for long-term ones.

  3. Write It Down. Articulate the problem statement in writing and revisit it the next day. Jargon in the description is a reliable indicator that understanding is shallow. If the statement survives overnight scrutiny and reads clearly in plain language, the definition is likely sound.

Phase 2: Explore Possible Solutions

Once the problem is defined, the temptation is to seize the first plausible solution. The framework identifies three traps at this stage, each with a corresponding countermeasure.

Trap 1: Ignoring Brutal Reality (The Stockdale Paradox). Admiral James Stockdale, the highest-ranking US prisoner of war in Vietnam, observed that the optimists -- those who kept predicting release by Christmas, then Easter, then Thanksgiving -- were the ones who died. "You must never confuse faith that you will prevail in the end with the discipline to confront the most brutal facts of your current reality." Entrepreneurs who build solutions on wishful assumptions about market timing, customer behaviour, or competitive response are running the same risk. The Bad Outcome Principle demands imagining not just the ideal future but the ways things could go wrong and how you would overcome each.

Trap 2: Binary Thinking. When only two options present themselves -- launch or don't, hire or don't, pivot or don't -- it is almost always a sign that the problem's dimensions have been prematurely reduced. The framework calls this "stopping thinking" disguised as clarity.

The antidotes:

SafeguardMethod
The 3+ PrincipleForce at least three credible options before evaluating any. If only two exist, develop a third. Even if the third is never chosen, the work of generating it deepens understanding.
Remove an OptionImagine each existing option is off the table. "What would I do if staying were not possible?" or "What would I do if leaving were not possible?" The constraint forces creative reframing.
Both-And ThinkingRather than choosing between X and Y, ask whether a solution exists that combines the best elements of both. Roger Martin calls this integrative thinking. Isadore Sharp built the Four Seasons by combining the intimacy of a small hotel with the amenities of a large one -- a Both-And solution that the industry's binary framing had made invisible.

Trap 3: Invisible Opportunity Costs. Every option chosen is an option forgone. Charlie Munger's observation -- "Intelligent people make decisions based on opportunity costs; it's your alternatives that matter" -- is simple to state and routinely ignored in practice.

The 3-Lens Principle structures this analysis:

  • Lens 1: Compared with what? The direct comparison most people default to.
  • Lens 2: And then what? The second-order consequences -- what happens after what happens next. This is where second-order thinking separates competent decision-makers from exceptional ones.
  • Lens 3: At the expense of what? The hidden costs in time, energy, relationships, and foregone alternatives that never appear on a spreadsheet.

Andrew Carnegie demonstrated all three lenses when, as a young railroad employee, he ordered burning of train cars blocking the entire system rather than spending days salvaging cargo. The visible cost (destroyed cargo) was dwarfed by the invisible cost (days of system-wide shutdown). His boss made the approach standard procedure.

Most entrepreneurs default to Lens 1 because it deals in direct, visible costs -- the numbers that appear on a spreadsheet. Lens 2 and Lens 3 require imagination: the ability to trace consequences forward in time and to see what is absent rather than what is present. Charlie Munger's observation bears repeating: "Intelligent people make decisions based on opportunity costs; it's your alternatives that matter." The quality of the decision depends on the quality of the alternatives considered, and alternatives cannot be considered if they remain invisible.

The premortem -- Stoic in origin (Seneca's premeditatio malorum), psychological in modern formulation -- complements the three lenses by forcing explicit attention to downside scenarios. The text cites venture capitalist Josh Wolfe: "Failure comes from a failure to imagine failure." The premortem is not pessimism. It is preparation. The hardest setbacks to recover from are the ones that were never anticipated, because they arrive when no contingency exists and emotion fills the vacuum that planning should have occupied.


Prompts

Prompt 1 -- Root Cause Diagnosis:

"I am dealing with the following problem: [describe situation]. Apply the Root Cause Principle. Ask 'What would have to be true for this problem not to exist in the first place?' Work backward from symptoms to underlying causes. Identify at least three possible root causes, rank them by likelihood, and suggest how to test which is the real one."

Prompt 2 -- Binary Thinking Breaker:

"I am choosing between [Option A] and [Option B] for my [stage] startup in [sector]. Apply the 3+ Principle, the Remove-an-Option safeguard, and Both-And integrative thinking to generate at least three additional options I have not considered. For each new option, explain what it reveals about the problem that binary framing conceals."

Prompt 3 -- Second-Order Consequence Map:

"I am considering [decision] for my company. Apply the 3-Lens Principle: (1) Compared with what alternatives? (2) And then what -- trace second-order and third-order consequences for each option over 6, 12, and 36 months. (3) At the expense of what -- identify hidden opportunity costs in time, capital, team focus, and optionality. Present findings in a structured table."

Prompt 4 -- Problem-Solution Firewall:

"My team has converged on this problem definition: [problem statement]. Before we move to solutions, stress-test this definition. Is it addressing a root cause or a symptom? Does it use jargon that masks shallow understanding? Would it pass the Test of Time -- would a solution to this problem fix things permanently or merely defer them? Rewrite the problem statement if the original is flawed."


Use Cases

SaaS Founder Treating Churn Symptoms

A Series A SaaS company in the HR-tech space sees monthly churn rising from 3 percent to 5 percent. The leadership team convenes and within minutes converges on "we need better onboarding." Resources shift to redesigning the first-week experience. Three months later, churn is unchanged. The problem was never onboarding -- it was that the product lacked a critical integration with the payroll system that mid-market customers (the fastest-growing segment) required. The team had treated the most visible symptom (users leaving after month two, which "looked like" an onboarding problem) rather than applying the root cause question: "What would have to be true for these customers not to leave?" Writing out the problem statement would have surfaced the jargon problem immediately -- "onboarding friction" is a label, not a diagnosis.

Pre-Seed Founder Stuck in Binary Framing

A solo founder with a working prototype for a supply-chain visibility tool faces what feels like a binary choice: accept a $150K angel investment at unfavourable terms or bootstrap with consulting revenue. The 3+ Principle generates three additional options: a revenue-based financing arrangement, a strategic pilot with a logistics company that would fund development in exchange for exclusivity, and a Both-And approach -- accepting the angel but negotiating a smaller cheque alongside a paid pilot. The third option, invisible under binary framing, provides capital, validates the product, and creates a reference customer simultaneously.

Growth-Stage E-Commerce Company Ignoring Opportunity Costs

A D2C brand generating $12M in annual revenue is evaluating whether to build an in-house fulfilment centre. The team focuses almost exclusively on Lens 1 (build vs. outsource cost comparison). Applying Lens 2 ("And then what?") reveals that in-house fulfilment requires hiring a warehouse operations team, which diverts leadership attention from product development during a critical expansion window. Lens 3 ("At the expense of what?") surfaces the real cost: the two planned product launches that would be delayed by six months because the founder's bandwidth is consumed by logistics. The Lens 3 cost exceeds the Lens 1 savings by a factor of four.

Validation-Stage EdTech Founder Solving the Wrong Problem

A founder building an AI tutoring platform observes that user engagement drops sharply after the first session. The team diagnoses the problem as "weak onboarding UX" and spends six weeks redesigning the first-session flow. Engagement does not improve. Applying the root cause question -- "What would have to be true for this problem not to exist?" -- reveals that the issue is not onboarding but content: the platform's practice questions are calibrated for grade-level students, but the actual users are adult learners preparing for professional certifications. The problem was never "how do we make the first session stickier?" but "are we serving the users who are actually showing up?" Writing the problem statement in plain language would have exposed the mismatch immediately: "Users leave after one session" describes a symptom. "Our content does not match the needs of the users who find us" describes a cause. The six weeks spent on onboarding redesign cannot be recovered.


Anti-Patterns

Confusing speed with competence. Entrepreneurs wear rapid decision-making as a badge of honour. There is a difference between moving quickly on reversible decisions (which is wise) and collapsing the problem-definition phase because it feels unproductive (which is reckless). The social default rewards the appearance of decisiveness. The market rewards the reality of solving the right problem.

Anchoring on the first credible problem statement. The first person in the room to articulate a plausible diagnosis often sets the frame for everyone else. Once a problem is named, the team shifts to solution mode and rarely revisits whether the name was accurate. Treating the first lens into an issue as the definitive lens is the single most common source of wasted organisational effort.

Applying the framework to trivial decisions. Not every decision warrants root cause analysis and three-lens evaluation. Using heavyweight problem-definition for reversible, low-consequence choices is its own form of poor judgment. Reserve this discipline for decisions where the cost of solving the wrong problem is high.

Mistaking Both-And thinking for lack of conviction. Integrative solutions can look like indecision to team members accustomed to binary framing. A founder who says "we are doing both" needs to articulate why the combination is strategically coherent, not merely a failure to choose.

Falling in love with the root cause analysis process. Definition is not an end in itself. The purpose of separating definition from solution is to improve the quality of the solution phase, not to defer it indefinitely. If you have been defining the problem for weeks and cannot articulate it in two sentences of plain language, the process has become a refuge from action. The framework is blunt about this: "There is no purpose to knowing what you should do and not doing it."

Ignoring opportunity costs because they are invisible. Most people focus exclusively on direct costs -- the money, the time, the effort that a decision requires. Hidden costs -- the forgone alternatives, the deferred projects, the relationships not maintained -- never appear on a balance sheet and therefore never enter the analysis. The 3-Lens Principle exists precisely to make these invisible costs visible, but it requires discipline to apply consistently when the visible costs are already demanding full attention.


By Stage

StageFocusKey Difference
IdeaFounder defines the problem they are solving for customers -- the root cause behind the pain they intend to address.The most common error is building a solution to a problem no one actually has. Root cause analysis is applied to customer pain, not internal operations.
ValidationTesting whether the defined problem matches real customer behaviour.The 3-Lens Principle reveals opportunity costs of pursuing one customer segment over another. Premortems expose assumptions baked into the MVP hypothesis.
Early TractionDistinguishing growth problems from product problems. Churn, slow sales cycles, and support ticket volume are symptoms that can point to very different root causes.The problem-solution firewall becomes an operational discipline for the leadership team -- separate meetings for diagnosis and action.
GrowthMultiple fires burn simultaneously. The temptation to treat symptoms intensifies because there is never enough time.Second-order thinking becomes critical: every resource allocation decision forecloses other options. Opportunity cost analysis scales with the complexity of the business.
ScaleOrganisational complexity makes root causes harder to identify. Information is filtered through multiple layers before reaching decision-makers.The Root Cause Principle must be paired with high-fidelity information-gathering -- going to the source rather than relying on abstractions that have passed through several management layers.

A recurring pattern across stages: the earlier a problem is correctly defined, the cheaper it is to solve. At the idea stage, redefining the problem costs a conversation. At growth stage, it costs a quarter's roadmap. At scale, it costs a reorganisation. The compounding cost of solving the wrong problem is the strongest argument for investing disproportionate time in the definition phase -- particularly when the social default is screaming that you should be doing something rather than understanding something.

The premortem -- imagining what could go wrong before it does -- scales differently across stages as well. At the idea stage, the relevant premortems are existential: "What if no one wants this?" At early traction, they become operational: "What if our biggest customer churns?" At scale, they become systemic: "What if the regulatory environment shifts?" The habit of anticipating failure is the same; the scope of the anticipation widens with the complexity of the business.


Output Template

markdown
# Problem Definition and Solution Exploration

## Problem Statement (Plain Language)
[Two sentences maximum. No jargon. If a twelve-year-old cannot understand this, rewrite it.]

## Root Cause Analysis
- **Visible symptom(s):** [What is being observed]
- **Root cause hypothesis:** [What would have to be true for this problem not to exist]
- **Test of Time check:** Will solving this root cause fix the problem permanently? [Yes/No + reasoning]
- **Validation method:** [How we will confirm this is the real root cause, not another symptom]

## Solution Space (Minimum 3 Options)

| Option | Description | Second-Order Consequences (Lens 2) | Hidden Opportunity Costs (Lens 3) |
|--------|-------------|-------------------------------------|-----------------------------------|
| A | [description] | [and then what?] | [at the expense of what?] |
| B | [description] | [and then what?] | [at the expense of what?] |
| C | [description] | [and then what?] | [at the expense of what?] |
| Both-And? | [integrative option combining elements] | [and then what?] | [at the expense of what?] |

## Binary Thinking Check
- Are we framing this as only two options? [Yes/No]
- If yes, what would we do if Option A were impossible? Option B?
- What integrative Both-And option exists?

## Recommendation
[Which option best addresses the root cause, survives the Test of Time, and has the most favourable second-order consequences relative to opportunity costs]

Related Skills

  • Thinking, Fast and Slow -- Covers the cognitive biases (anchoring, availability, confirmation) that distort the problem-definition phase.
  • Decision-Making Under Pressure -- Addresses the speed-versus-accuracy trade-off when time is scarce; complements the problem-solution firewall with reframing techniques.
  • Evaluating and Deciding -- The natural sequel: once the problem is defined and the solution space explored, this skill covers criteria weighting, margin of safety, and execution.
  • Stoic Problem-Solving -- Marcus Aurelius's reverse clause and creative reframing of obstacles; a philosophical complement to the structural approach presented here.
  • Scenario Planning -- Extends the Bad Outcome Principle into a formal methodology for imagining multiple futures and stress-testing strategies.
  • Systems Thinking -- Provides the analytical lens for tracing root causes through feedback loops and emergent behaviour in complex systems.
  • Strategic Questioning -- The leadership practice of leading through questions rather than answers shares the same premise: better questions produce better solutions.

Frequently asked questions

What does the Defining And Exploring Problems AI skill do?

Teaches the discipline of correct problem definition and structured solution exploration before any evaluation begins. Covers the problem-solution firewall, root cause identification, the premortem, second-order thinking ('and then what?'), binary thinking traps, integrative Both-And options, and opportunity cost analysis through the 3-Lens Principle. Use when a team is jumping to solutions before understanding the problem, when a founder suspects they are treating symptoms rather than causes, when only two options seem to exist, when opportunity costs are unclear, or when first-conclusion...

Why use Defining And Exploring Problems on TypingMind?

Because you install it once and use it with any model. Defining And Exploring Problems is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Defining And Exploring Problems in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/fatihguner/foreman/tree/main/plugins/foreman/skills/defining-and-exploring-problems. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Defining And Exploring Problems?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Defining And Exploring Problems?

As many as you like. As long as a model supports skills, you can use Defining And Exploring Problems with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Defining And Exploring Problems AI skill free?

Yes. It is published on GitHub by fatihguner under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇