Why So Many Logic Models End Up Sitting in a Folder

Sometimes I hear a groan when I ask, “Do you have a logic model?” 

I get it. These tools are often funder requirements–created once and then rarely revisited. So it’s fair to ask: what’s the point of investing time and energy into something that often gets shelved?  

And yet, I keep coming back to a different question: What if the problem isn’t the logic model itself–but how we use it?

Many logic models don’t get used in practice, not because they are poorly designed, but because they are never integrated into how organizations actually learn, adapt, and make decisions. 

Built for Compliance, Not Use

Too often, teams spend weeks building a logic model, polishing it for a proposal or report, and then never reference it again.

They are often shaped by external requirements (e.g., funders, proposals, reporting requirements), which can make it harder for them to function as internal learning tools. 

The result is a document that is technically complete, but rarely used in ongoing decision-making.

Treated as Static Instead of Evolving

Programs change. Contexts change. Assumptions change.

But logic models are often treated as fixed artifacts rather than living frameworks.

This matters because logic models are built on assumptions about how change happens—assumptions that are rarely revisited once programs are underway.

In practice, we often learn that some of those assumptions need to be revised. But the logic model rarely evolves with that learning.

What Would a Logic Model Designed for Learning Actually Look Like?

Logic models haven’t changed much over time. Most still follow a familiar structure: inputs, activities, outputs, and outcomes. Some include assumptions, context, or impact. But the core design has remained largely static. So the question is: What would need to change for logic models to actually support learning, strategy, and decision-making?

If we redesigned logic models for learning and use, not compliance, they might function more like living strategy maps that are revisited regularly. Instead of a static table created once a year, a logic model would become a tool that evolves with practice. 

For example, some possibilities include:

Make assumptions explicit and testable. Not just listing assumptions, but naming them in a way that can be examined over time: “We believe X will lead to Y—here’s what would confirm or challenge that.”

Include signals of change, not just final outcomes. Alongside long-term outcomes, it would surface early indicators that help teams adjust course in real time.

Be structured around learning questions, not just categories. In addition to inputs → outputs → outcomes, it might also ask: What are we trying to learn right now? What decisions will this inform?

Be designed for updating, not archiving. Rather than being “finalized,” it would include built-in moments for revision such as quarterly reflection points, versioning, or structured revisiting.

Be embedded in practice, not stored in a document. Instead of sitting in a folder, it would show up in strategy meetings, reflection sessions, and continuous improvement cycles. In this version, the logic model is less a product and more a working tool for collective sensemaking.

A logic model should not be a document organizations complete. It should be a framework they return to. Its value is not in its existence, but in how often it shapes conversation, learning, and decision-making over time.