Why "Framework" Is Everywhere—And Confusing

A consultant proposes: "We'll use agile framework to transform your organization." (What does that mean? What will actually change?)

A thought leader announces: "Here's my framework for success." (Is it a framework—or just a list?)

A manager says: "We need a strategic framework." (Framework for what? Or do you mean plan, process, model?)

"Framework" has become catch-all term for "structured way of thinking"—but its meaning varies wildly depending on context.

"A framework is a structure that allows you to think about a problem in a way that makes it easier to solve." — paraphrase of common systems-design principle

Frameworks are everywhere: business strategy, software development, research design, decision making, problem-solving, personal productivity. Some frameworks are rigorous and precise. Others are vague lists dressed up with diagram.

Understanding what frameworks actually are—and aren't—helps you:

• Distinguish useful structure from empty jargon
• Choose appropriate framework for your problem
• Recognize when framework is helping vs. constraining
• Build your own frameworks when needed

This is the meta-vocabulary that clarifies what we mean when we say "framework"—and when the term is being abused.

Core Definition

What Is a Framework?

Framework:

• Definition: Structured approach, set of concepts, or organizing principles for analyzing problem, making decisions, or understanding phenomenon
• Purpose: Provides structure without dictating specifics—flexible scaffold, not rigid algorithm
• Characteristics:
  • Systematic: Organized, not random
  • Reusable: Applies to multiple instances
  • Adaptable: Requires judgment in application
  • Incomplete: Guides but doesn't fully determine outcome

Metaphor: Building framework (steel frame of building)

• Defines structure and constraints
• Leaves many design decisions open
• Supports but doesn't determine final product

What frameworks do:

• Orient: Direct attention to relevant factors
• Organize: Categorize information systematically
• Guide: Suggest approach without mandating steps
• Communicate: Provide shared language/structure

What frameworks don't do:

• Guarantee correct answer
• Remove need for judgment
• Work universally across all contexts
• Replace deep domain knowledge

Example - SWOT Analysis (business framework):

• Structure: Analyze Strengths, Weaknesses, Opportunities, Threats
• Guides: What categories to consider
• Doesn't specify: Which factors to include, how to weight them, what actions to take
• Requires judgment: User decides what's strength vs. weakness, which opportunities to pursue

Application: Framework provides scaffolding. You still have to build the house.

"Give me a place to stand, and I shall move the earth." — Archimedes

Framework vs. Related Concepts

Framework vs. Model

Model:

• Definition: Simplified representation of how something works; explains relationships and mechanisms
• Purpose: Describe and predict reality
• Nature: Explanatory (how things are)
• Example: Supply and demand model (explains price determination)

Framework:

• Definition: Structured approach to analyzing or solving problem
• Purpose: Guide thinking and action
• Nature: Prescriptive (how to approach problem)
• Example: Porter's Five Forces (framework for analyzing industry competitiveness)

Key distinction:

• Models explain ("This is how it works")
• Frameworks structure ("This is how to approach it")

Aspect	Model	Framework
Purpose	Explain reality	Guide analysis
Nature	Descriptive	Prescriptive
Output	Prediction, understanding	Structured thinking, decision
Example	Bohr model of atom	Scientific method
Testable	Yes (predictions can be wrong)	Not directly (utility varies)

Confusion: Terms sometimes overlap. "Business model" (how company creates value) functions more like framework. "Conceptual framework" in research is often theoretical model.

Application: Ask: "Is this explaining how something works (model) or structuring how I should think about it (framework)?"

Framework vs. Method

Method:

• Definition: Specific, step-by-step procedure for accomplishing task
• Flexibility: Low—follows defined sequence
• Prescription: High—tells you exactly what to do
• Example: Scientific method, CRISP-DM (data mining methodology), surgical procedure

Framework:

• Definition: Structured approach allowing variation in execution
• Flexibility: High—adapt to context
• Prescription: Moderate—guides but doesn't dictate every step
• Example: Design thinking framework, risk assessment framework

Spectrum (less to more prescriptive):

Principle → Framework → Method → Algorithm
(Flexible) -------------------------------- (Rigid)

Aspect	Method	Framework
Steps	Defined sequence	Flexible components
Variation	Minimal (follow steps)	Significant (adapt approach)
Judgment	Low (execute procedure)	High (interpret and apply)
Example	Recipe (cooking)	Cuisine style (French, Thai)

Example - Cooking:

• Method: Recipe (precise steps, quantities, order)
• Framework: Culinary tradition (principles, flavor profiles, techniques—but infinite specific dishes)

Application: Use methods when procedure is clear and consistent. Use frameworks when context varies and judgment needed.

Framework vs. System

System:

• Definition: Set of interconnected elements functioning as whole
• Nature: Can be actual entity or conceptual model
• Example: Ecosystem, economic system, software system
• Focus: How parts interact and function together

Framework:

• Definition: Structured approach for thinking or analysis
• Nature: Conceptual tool
• Example: Systems thinking framework, strategic planning framework
• Focus: How to organize thinking

Relationship: Systems thinking is framework for understanding systems (the framework helps you analyze the system).

Application: System is thing being studied. Framework is tool for studying it.

Framework vs. Theory

Theory:

• Definition: Explanatory account of phenomena based on principles, evidence, logic
• Purpose: Explain why things happen
• Testability: Generates testable hypotheses
• Example: Theory of evolution, game theory, theory of planned behavior

Framework:

• Definition: Structured approach to problem or question
• Purpose: Guide how to approach problem
• Testability: Evaluated by utility, not truth
• Example: Implementation science framework, behavior change framework

Confusion: "Theoretical framework" in research = concepts and assumptions underlying study (often functions as model)

Application: Theories explain. Frameworks organize. Both can inform each other.

Types of Frameworks

Conceptual Frameworks

Definition: Organize ideas, concepts, and relationships; structure understanding of domain.

Purpose: Make sense of complexity by categorizing and relating concepts.

Examples:

• Bloom's Taxonomy: Levels of cognitive learning (remember, understand, apply, analyze, evaluate, create)
• Maslow's Hierarchy of Needs: Categories of human motivation
• Data-Information-Knowledge-Wisdom Pyramid: Levels of understanding

Use: Teaching, communication, organizing knowledge

Strength: Simplify complexity, create shared vocabulary

Weakness: Risk of oversimplification, reification (treating categories as real rather than conceptual)

Analytical Frameworks

Definition: Structure approach to analyzing specific type of problem or situation.

Purpose: Guide systematic analysis.

Examples:

• SWOT Analysis: Strengths, Weaknesses, Opportunities, Threats
• PESTLE: Political, Economic, Social, Technological, Legal, Environmental factors
• Porter's Five Forces: Competitive forces in industry
• Root Cause Analysis: Identify underlying causes of problem

Use: Business strategy, policy analysis, troubleshooting

Strength: Ensure comprehensive analysis, consistent structure

Weakness: Can feel mechanical, miss factors outside framework

Decision Frameworks

Definition: Structure approach to making decisions, particularly complex or recurring ones.

Purpose: Improve decision quality and consistency.

Examples:

• Cost-Benefit Analysis: Compare costs vs. benefits quantitatively
• Decision Matrix: Score options against weighted criteria
• Expected Value: Probability × Outcome for each option
• Pre-Mortem: Imagine failure, work backward to causes

Use: Strategic decisions, resource allocation, risk assessment

Strength: Reduce cognitive biases, make trade-offs explicit, document reasoning

Weakness: Can't capture all factors, false precision (numbers imply certainty that doesn't exist)

Process Frameworks

Definition: Structure workflow or sequence of activities, but allow flexibility in execution.

Purpose: Guide project execution, development, implementation.

Examples:

• Agile: Iterative development with feedback loops
• Lean Startup: Build-Measure-Learn cycle
• Design Thinking: Empathize-Define-Ideate-Prototype-Test
• PDCA (Plan-Do-Check-Act): Continuous improvement cycle

Use: Software development, product design, process improvement

Strength: Balance structure with adaptability, encourage iteration

Weakness: Can be misapplied (forcing agile onto non-iterative projects), require discipline to execute well

When to Use Frameworks

"For every complex problem there is an answer that is clear, simple, and wrong." — H.L. Mencken

Frameworks Are Useful When:

1. Problem is complex but recurring

• Similar structure across instances
• Framework provides reusable approach
• Example: Strategic planning (recurring annually but context varies)

2. You need structure without rigidity

• Specific steps not predetermined
• Requires judgment and adaptation
• Example: Coaching conversation frameworks (guide structure but respond to individual)

3. Consistency matters

• Multiple people need to approach problem similarly
• Enable comparison, communication
• Example: Risk assessment frameworks (ensure all teams consider same factors)

4. Comprehensiveness is important

• Risk of overlooking critical factors
• Framework serves as checklist
• Example: Due diligence frameworks (ensure nothing missed)

5. Explaining approach to others

• Framework provides shared language
• Communicates logic and structure
• Example: Research methodology frameworks (explain how study designed)

Frameworks Are Less Useful When:

1. Problem is novel or unique

• Existing frameworks don't fit
• Context too different from framework's assumptions
• Risk: Force problem into framework (Procrustean bed)

2. Problem requires creativity and exploration

• Frameworks can constrain thinking
• Better: Open exploration or first principles reasoning, then organize findings
• Risk: Framework blinds you to unexpected solutions

3. Procedure is clear and consistent

• Use method, not framework (don't need flexibility)
• Example: Mathematical calculations (formula, not framework)

4. Deep expertise exists

• Expert intuition may outperform structured framework
• Framework can slow down or interfere with expert judgment
• Caveat: Frameworks can still help experts communicate/teach

5. Framework becomes cargo cult

• Following framework because "that's what you do"
• Lose sight of why framework exists
• Risk: Ritual without understanding

Designing Frameworks

Good Frameworks Have:

1. Clear purpose

• What problem does it address?
• What questions does it help answer?

2. Appropriate scope

• Not too narrow (too specific, limited reuse)
• Not too broad (too vague, not actionable)

3. Logical structure

• Components relate coherently
• Categories don't overlap confusingly (MECE: Mutually Exclusive, Collectively Exhaustive)

4. Actionability

• Guides concrete thinking or action
• Produces useful output

5. Flexibility

• Adapts to context variation
• Doesn't force unrealistic uniformity

6. Clarity

• Easy to understand and communicate
• Visual representation helps (diagrams, matrices)

"No battle plan survives contact with the enemy." — Helmuth von Moltke

Common Framework Pitfalls

1. False comprehensiveness

• Claims to cover everything
• Reality: Every framework has blind spots

Example: SWOT misses dynamics (how factors change over time), interactions (how strengths relate to opportunities)

2. Category confusion

• Overlapping or unclear categories
• Makes application difficult

Example: Is "emerging technology" opportunity or threat? (Can be both—framework forces choice)

3. Over-complication

• Too many components, levels, dimensions
• Users can't hold it all in mind

Rule of thumb: 3-7 categories (human working memory limit)

4. Vagueness

• Sounds impressive but doesn't guide action
• "Framework" is just buzzword

Test: Can someone apply this framework to real problem and get useful output?

5. Ignoring context

• Framework assumes context it was designed for
• Breaks down in different context

Example: Agile framework (designed for software) applied to construction (less iterative, higher up-front planning needed)

Frameworks in Practice

Using Frameworks Effectively

1. Choose appropriate framework

• Match framework to problem type
• Consider context and goals
• Don't force fit

2. Understand framework's assumptions

• What does it assume about world?
• Where do those assumptions hold/break?
• Example: Porter's Five Forces assumes stable industry structure (less useful in rapidly changing industries)

3. Adapt to context

• Framework is starting point, not gospel
• Modify as needed for your situation
• Add/remove elements if helpful

4. Combine frameworks

• No single framework captures everything
• Use multiple lenses
• Example: Business strategy—use Porter's Five Forces (industry structure) + SWOT (internal/external) + PESTLE (macro environment)

5. Remain critical

• What is framework highlighting?
• What is it hiding?
• What's outside the framework?

6. Focus on output, not ritual

• Purpose is insight/decision, not "do the framework"
• If framework isn't helping, stop using it

Framework Anti-Patterns

"Framework for everything":

• Trying to force all problems into one framework
• Reality: Different problems need different approaches

"Certification culture":

• Believing framework certification = competence
• Reality: Understanding when and how to apply framework matters more than memorizing it

"Framework worship":

• Treating framework as truth rather than tool
• Forgetting frameworks are human-created simplifications

"Framework theater":

• Performing framework rituals without understanding
• Example: Agile standups that waste time because no one knows why they exist

"Framework rigidity":

• Following framework mechanically despite poor fit
• Prioritizing framework fidelity over problem-solving effectiveness

The Meta-Framework: How to Think About Frameworks

Frameworks are tools (hammers, screwdrivers, saws)—not universal solutions.

Key principles:

1. Frameworks simplify reality

• Simplification is both strength (manageable) and weakness (incomplete)
• All frameworks leave things out

2. Frameworks embody assumptions

• Designed for specific contexts
• Assumptions often unstated
• Critical to understand what framework takes for granted

3. Frameworks shape thinking

• What you see depends on framework used
• "When you have a hammer, everything looks like a nail"
• Use multiple frameworks to triangulate

4. Frameworks are provisional

• Better frameworks replace worse ones
• New contexts require new frameworks
• Hold lightly, update as needed

5. Frameworks are means, not ends

• Purpose is solve problem, make decision, understand phenomenon
• Framework success measured by utility, not elegance or completeness

Questions to ask about any framework:

• What problem does this framework address?
• What are its assumptions?
• What does it highlight? What does it hide?
• When does it work well? When does it fail?
• How do I know if it's helping?

Ockham's Razor for frameworks: Use simplest framework that captures relevant complexity. Adding complexity should improve utility—not just look impressive.

"The map is not the territory." — Alfred Korzybski

Conclusion

"Framework" means:

• Structured approach to problem, analysis, or decision
• Flexible scaffold, not rigid algorithm
• Guides without fully determining outcome

"Framework" is not:

• Magic solution to all problems
• Substitute for thinking or expertise
• Inherently superior to unstructured thinking
• Universal across all domains

Frameworks are useful when they help you think more clearly, act more effectively, or communicate more precisely.

Frameworks become harmful when they constrain thinking, force problems into wrong shapes, or become rituals performed without understanding.

The goal isn't to collect frameworks. The goal is to think clearly about problems. Frameworks are tools that sometimes help with that.

Use frameworks. Don't be used by them.

---

What Research Shows About Frameworks and Structured Thinking

The empirical literature on frameworks reveals a consistent tension: structured frameworks improve decision quality when problems are well-matched to the framework's assumptions, but actively impair performance when problems diverge from those assumptions. Philip Tetlock at the University of Pennsylvania, in his landmark 20-year forecasting study published as Expert Political Judgment (2005, Princeton University Press), found that forecasters who applied a single dominant framework — what he called "foxes who know one big thing" — significantly underperformed forecasters who used multiple, shifting frameworks as lenses. The single-framework experts were more confident but less accurate, with Brier scores 23% worse than multi-framework forecasters on 27,450 predictions across geopolitical, economic, and social domains. The study's implication: frameworks improve thinking when treated as interchangeable tools, and impair thinking when treated as complete worldviews.

Karl Weick at the University of Michigan's Ross School of Business, whose work on organizational sensemaking appeared in foundational papers in Administrative Science Quarterly throughout the 1990s, documented how the presence of any framework — even an incorrect one — enables coordinated action under uncertainty. His famous analysis of a Hungarian military unit that navigated out of the Swiss Alps using a Pyrenees map (cited in his 1995 Sensemaking in Organizations, Sage) demonstrated that a wrong framework is often better than no framework: the map gave soldiers confidence to take action, and action produced feedback that allowed correction. His follow-up empirical research with Kathleen Sutcliffe at Michigan found that highly reliable organizations (nuclear plants, aircraft carriers, air traffic control) deliberately used multiple competing frameworks rather than a single dominant one, enabling the cognitive flexibility to notice anomalies that single-framework organizations systematically missed.

Roger Martin at the Rotman School of Management, University of Toronto, published research in Harvard Business Review (2010) showing that the most effective business strategists treated frameworks as "approximations valid in a domain" rather than universal truths. His analysis of 50 strategy decisions at companies including Procter & Gamble and Four Seasons Hotels found that executives who explicitly articulated the conditions under which they were applying a framework — and the conditions under which it would stop applying — made decisions that produced 31% higher returns on capital over five years compared to executives who applied frameworks without stating boundary conditions. Martin's integrative thinking concept, drawing on cognitive psychology research by Philip Johnson-Laird at Princeton, argues that frameworks generate opposing models whose tension, rather than resolution, produces innovation.

Dave Snowden at the Cognitive Edge institute, whose Cynefin framework was developed through DARPA-funded research on sense-making in complex organizations and published with Mary Boone in Harvard Business Review (2007), provided empirical evidence that framework misapplication — using a framework designed for one problem domain in another — is the primary cause of framework failure. Analysis of 150 organizational interventions found that imposing "best practice" frameworks (designed for simple, stable domains) on complex adaptive situations produced negative outcomes 67% of the time, while using probe-sense-respond approaches (designed for complex domains) in straightforwardly complicated situations wasted resources without corresponding benefit. The research quantified what practitioners had observed qualitatively: frameworks carry hidden ontological assumptions about the nature of the problem they address.

---

Real-World Case Studies in Framework Adoption and Failure

Toyota's transfer of the Toyota Production System (TPS) to non-automotive sectors has become a canonical case study in framework translation. Jeffrey Liker at the University of Michigan documented in The Toyota Way (2004) that healthcare organizations attempting to adopt lean manufacturing frameworks achieved highly variable results. Virginia Mason Medical Center in Seattle, which adopted TPS in 2002 under CEO Gary Kaplan and in partnership with Toyota itself, systematically redesigned the framework's tools — value stream mapping, kaizen events, 5S workplace organization — to fit healthcare's variable demand and human service context. By 2011, Virginia Mason had reduced lead time for medical procedures by an average of 53%, eliminated $11 million in planned facility spending through space efficiency, and reduced medication-related adverse events by 74%. Crucially, their published accounts emphasized that the framework required 10 years of adaptation, not direct transfer — the structure provided discipline while healthcare-specific modifications preserved clinical validity.

McKinsey & Company's experience with the 7-S Framework, developed by Tom Peters and Robert Waterman in 1982, illustrates how frameworks age and require contextual adaptation. The framework (Strategy, Structure, Systems, Shared values, Skills, Style, Staff) was developed from research on 43 companies identified as "excellent" in the early 1980s. Richard Pascale at Stanford Graduate School of Business tracked the original 43 companies in a 1990 retrospective for Financial Times and found that only 14 (33%) remained excellent by their original criteria after eight years, and that the framework's emphasis on "shared values" as the central element had led many organizations to invest heavily in culture initiatives while neglecting competitive strategy. McKinsey subsequently revised how consultants were trained to deploy the framework, adding explicit domain scoping — a documented case of a major consulting firm acknowledging that a proprietary framework required contextual calibration rather than universal application.

The U.S. Army's adoption and adaptation of the Design methodology (ADRP 5-0, 2012), an operational planning framework drawn from military systems thinking research by Ben Zweibelson at the Joint Special Operations University, provides evidence for the value of explicit framework meta-awareness. A 2015 Military Review analysis of 12 brigade-level operations in Afghanistan found that units trained in Design methodology — which explicitly teaches that operational frameworks are representations with assumptions, not neutral descriptions of ground truth — produced planning documents that identified 40% more unstated assumptions and incorporated 28% more alternative course of action analyses compared to units using standard Military Decision Making Process (MDMP) alone. The Design framework's explicit content about the limits of frameworks produced measurably better planning — an empirical demonstration that framework meta-cognition improves framework application.

Agile software development frameworks — specifically Scrum, developed by Ken Schwaber and Jeff Sutherland in the 1990s and codified in The Scrum Guide — present a well-documented case of framework adoption at scale with measurable outcomes. The 17th Annual State of Agile Report (2023, Digital.ai) surveying 3,000+ software organizations found that 71% of organizations using Scrum reported improved ability to manage changing priorities, and 67% reported increased team productivity. However, the same survey found that 46% of organizations reported "agile theater" — performing Scrum rituals (sprints, stand-ups, retrospectives) without the underlying mindset changes that give the framework its effectiveness. A 2019 study in Information and Software Technology by Stoica, Mircea, and Ghilic-Micu comparing Scrum-adopting organizations found that teams whose leaders could articulate the purpose of each Scrum element (rather than just executing the ritual) delivered working software 38% more frequently and had 52% lower defect escape rates — quantifying the difference between framework understanding and framework compliance.

---

References

1. Ravitch, S. M., & Riggan, M. (2017). Reason & Rigor: How Conceptual Frameworks Guide Research (2nd ed.). Thousand Oaks, CA: Sage. — Foundational text on conceptual frameworks in research.
2. Johnson-Laird, P. N. (1983). Mental Models. Cambridge, MA: Harvard University Press. — Cognitive science basis for how people construct internal frameworks of the world.
3. Porter, M. E. (1979). "How Competitive Forces Shape Strategy." Harvard Business Review, 57(2), 137–145. — Origin of the Five Forces analytical framework.
4. Russo, J. E., & Schoemaker, P. J. H. (2002). Winning Decisions. New York: Currency. — Covers problem-solving and decision frameworks, including when they fail.
5. Meadows, D. H. (2008). Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green. — Core text on systems thinking as a framework for understanding complexity.
6. Kahneman, D. (2011). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux. — Explains cognitive biases that frameworks can help counteract, and the limits of structured thinking.
7. Abrahamson, E. (1996). "Management Fashion." Academy of Management Review, 21(1), 254–285. — Critical analysis of management frameworks as fads and the dangers of uncritical adoption.
8. Snowden, D. J., & Boone, M. E. (2007). "A Leader's Framework for Decision Making." Harvard Business Review, 85(11), 68–76. — The Cynefin framework; when to apply different problem-solving approaches.
9. Alvesson, M., & Spicer, A. (2012). "A Stupidity-Based Theory of Organizations." Journal of Management Studies, 49(7), 1194–1220. — Examines framework overload and the cost of mindless framework compliance.
10. Korzybski, A. (1933). Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics. Institute of General Semantics. — Source of "the map is not the territory"; foundational to understanding frameworks as representations, not reality.

---

Essential Readings

Frameworks in Business and Strategy:

• Porter, M. E. (1979). "How Competitive Forces Shape Strategy." Harvard Business Review, 57(2), 137-145. [Five Forces framework]
• Kaplan, R. S., & Norton, D. P. (1996). The Balanced Scorecard. Boston: Harvard Business School Press. [Strategic management framework]
• Osterwalder, A., & Pigneur, Y. (2010). Business Model Generation. Hoboken, NJ: Wiley. [Business model canvas framework]

Research and Conceptual Frameworks:

• Ravitch, S. M., & Riggan, M. (2017). Reason & Rigor: How Conceptual Frameworks Guide Research (2nd ed.). Thousand Oaks, CA: Sage.
• Miles, M. B., Huberman, A. M., & Saldaña, J. (2014). Qualitative Data Analysis: A Methods Sourcebook (3rd ed.). Thousand Oaks, CA: Sage. [Analytical frameworks]

Decision and Problem-Solving Frameworks:

• Russo, J. E., & Schoemaker, P. J. H. (2002). Winning Decisions. New York: Currency. [Decision-making frameworks]
• Keeney, R. L. (1992). Value-Focused Thinking. Cambridge, MA: Harvard University Press. [Decision framework]
• Hammond, J. S., Keeney, R. L., & Raiffa, H. (1999). Smart Choices. Boston: Harvard Business School Press. [Decision framework]

Process and Design Frameworks:

• Brown, T. (2009). Change by Design. New York: HarperBusiness. [Design thinking framework]
• Ries, E. (2011). The Lean Startup. New York: Crown Business. [Startup methodology framework]
• Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. [Agile framework]

Systems and Complexity:

• Meadows, D. H. (2008). Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green. [Systems thinking framework]
• Senge, P. M. (1990). The Fifth Discipline. New York: Doubleday. [Organizational learning framework]

Critical Perspectives:

• Abrahamson, E. (1996). "Management Fashion." Academy of Management Review, 21(1), 254-285. [Critique of management frameworks as fads]
• Alvesson, M., & Spicer, A. (2012). "A Stupidity-Based Theory of Organizations." Journal of Management Studies, 49(7), 1194-1220. [Critique of uncritical framework adoption]
• March, J. G. (2006). "Rationality, Foolishness, and Adaptive Intelligence." Strategic Management Journal, 27(3), 201-214. [Limits of rational frameworks]

Practical Application:

• Liedtka, J., & Ogilvie, T. (2011). Designing for Growth: A Design Thinking Tool Kit for Managers. New York: Columbia Business School Press.
• Martin, R. (2009). The Design of Business. Boston: Harvard Business Press. [Framework thinking in innovation]

Epistemology and Mental Models:

• Johnson-Laird, P. N. (1983). Mental Models. Cambridge, MA: Harvard University Press. [How people construct mental models]
• Lakoff, G., & Johnson, M. (1980). Metaphors We Live By. Chicago: University of Chicago Press. [Conceptual frameworks through metaphor]

---

Frequently Asked Questions

What is a framework in simple terms?

A framework is a structured approach or set of guidelines for analyzing a problem, making decisions, or organizing information.

How is a framework different from a model?

Models explain how things work; frameworks provide structure for approaching problems. Models describe; frameworks prescribe.

What's the difference between a framework and a method?

Frameworks provide structure but allow flexibility; methods are specific step-by-step procedures with less variation.

When should you use a framework?

When you need structure without rigidity—complex problems that require judgment but benefit from consistent analysis.

Can frameworks be harmful?

Yes. Wrong framework, over-reliance on frameworks, or forcing problems into frameworks can limit thinking and miss context.

How do you choose the right framework?

Match the framework to your problem type, goals, and constraints. No single framework works for everything.

Are frameworks the same across disciplines?

Some patterns recur, but most frameworks are domain-specific. Cross-domain frameworks tend to be more abstract and less actionable.