TBM 354: The 4 Framework Jobs (And Why It Matters)

In a previous post, we looked at the 4 Prioritization Jobs (And Why It Matters). This post is more broadly about frameworks and framework jobs.

In the product world, we are inundated with frameworks. It can be overwhelming and it triggers the obvious question: "Surely, we’ve figured some of these things out by now, haven’t we?"

But the real problem isn’t the number of frameworks, it’s that we’re often not clear about why we’re using them. Even when a team chooses a framework thoughtfully, people may still disagree about what they’re trying to accomplish. Are they trying to teach skills? Create shared language? Bootstrap a team? Ensure quality? Without alignment on the purpose, even the best frameworks fall flat.

4 Framework Jobs

Consider these four framework jobs. While reading, consider the differences. Consider how misapplying a framework meant for X to Y might cause problems.

Framework = scaffold or practice environment

Inexperienced people use frameworks to build judgment. Sometimes, frameworks are suggested by teachers or coaches; other times, people self-impose them to create the structure for learning. Frameworks help them go through the motions, build reflexes, and develop the intuitions needed for more fluid future work. Framework = scaffold or practice environment.

I know it feels a little rigid, but following the framework helps me practice the right habits until they become second nature.

Framework = local interface (and sometimes scaffold)

Experienced people often use frameworks to speed up collaboration. They already have judgment, and while they could freestyle and co-create a new framework from scratch, they're usually comfortable using an existing one as a starting point for discussion. It saves time and helps them focus their attention on what matters. When experienced individuals are thrown together without shared history, frameworks also serve as a light scaffold — helping them practice working together until collective competence forms. Framework = local interface, and sometimes scaffold.

We all know what we're doing individually, but having a simple framework helps us align faster — and sometimes we need it to get our teamwork rhythm going too.

Framework = federated interface

Sometimes frameworks are introduced to create just enough legibility between teams with local practices. Here, it's not about experience or inexperience, and it is not about experts figuring out a common ground so they can work together. It's about evolving loose interfaces between teams or groups. The framework is a lossy abstraction by design — it simplifies and standardizes just enough to enable coordination across varied ways of working without forcing uniformity. Framework = federated interface.

Our teams each have their way of working, but the framework gives us just enough common ground to coordinate without stepping on each other.

Framework = quality assurance or job aid

Even highly experienced people sometimes use frameworks as a final checkpoint to surface blind spots, ensure quality, or maintain high standards under pressure. In these cases, the framework functions more like a trusted checklist or job aid: it doesn't teach or structure the work but helps reinforce discipline and reliability. Framework = quality aid or checklist.

I know what I'm doing, but having a checklist helps me catch the little things that are easy to miss when you're moving fast.

The Problem

The big problem occurs when teams fail to agree on why they are using a framework and then apply it out of context.

Take, for example, Teresa Torres's Opportunity Solution Tree (OST) framework. It's important to qualify the purpose: Are you using the framework as a teaching aid to explain basic decomposition, inputs and outputs, and how to distinguish opportunities from solutions? Or are you using it as a lightweight coordination tool—a quick way to create a common language between two teams? Perhaps a third reason is using the framework to train executives on the basic distinctions and create a kind of federated interface for discussion.

These are very different applications.

I see many teams completely operationalize OSTs — building entire workflows and systems around them, imagining that the framework represents a standardized way of working. In reality, OSTs are better understood as thinking tools — designed to encourage shared understanding, collaboration, and structured sense-making, not to prescribe a rigid, repeatable process.

There's an even deeper, related problem.

Within organizations, people often have vastly different views about what constitutes experience. Is the framework meant to teach, help experienced people develop collective competence, or enforce a standard way of working?

You can see this tension clearly:

1. Some people eschew frameworks as being too "process-driven," believing that team members should already have the skills and that frameworks are a "crutch" for the inexperienced.

2. Others view people as individually competent and simply need a lightweight interface to work better together.

3. Still, others want to mandate a global process without appreciating the need for local independence. In these cases, the goal often drifts from using the framework as a tool to using it as an end in itself.

I've seen leaders make serious overgeneralizations about their teams' skills—assuming they need "training wheels"—when, in fact, the bigger problem was the absence of lightweight shared language between teams, management, and leadership.

Even experienced people often need a scaffold — not because they lack individual skill, but because they need a way to act their way into something better. It's not about personal competence; it's about deciding how they want to show up together, practicing it, and building on it over time.

One of the most important values of understanding these four "jobs" of frameworks is that it surfaces the implicit assumptions people carry about their environment and each other.

Questions

Consider these reflection questions:

1. When your team last adopted a framework, did you explicitly agree on what "job" you were hiring it for? If not, what assumptions might have shaped how you used it?

2. Have you seen a framework get operationalized into a rigid process when it was originally intended as a thinking tool? What happened as a result?

3. How do different people in your organization define "experience"? How does that shape their view of whether frameworks are necessary or a "crutch"?

4. Have you experienced tension between people who see frameworks as "process-heavy" versus those who see them as lightweight aids? How was that tension surfaced or resolved?

5. Think of a framework your team uses today. Is it primarily for teaching, alignment between experienced people, federated coordination across teams, or quality assurance?

6. Is that usage obvious and agreed upon?

7. Have you ever watched a team shift from "using a framework as a tool" to "doing the framework for its own sake"? What caused that shift?

8. Where in your organization would a lightweight "federated interface" be more valuable than enforcing a unified way of working?

9. Have you seen leaders misjudge whether a team needs a scaffold for collective learning versus simply a shared language for coordination? What were the consequences?

10. When have you personally benefited from having a scaffold — even when you were already experienced? What made it feel helpful instead of restrictive?

11. After reflecting on the four framework jobs, how might you approach adopting, adapting, or retiring frameworks differently in your work?