How to use frameworks correctly

Frameworks are the easiest way to level up your execution — if you use them right. This post will show you how

May 21, 2025

👋 Hi, it’s Torsten. Every week or two, I share actionable advice to help you grow your career and business, based on operating experience at companies like Uber, Meta and Rippling.

If you enjoyed the post, consider sharing it with a friend or colleague 📩; it would mean a lot to me. If you didn’t like it, feel free to send me hate mail.

When you come across a new framework, what’s your immediate reaction?

Chances are, you’re not going to be excited. Many people have framework fatigue, and for good reason. For every type of problem or task, it seems like there are at least half a dozen frameworks to choose from. And on top of that, every consulting firm and influencer is trying to coin one themselves. Always claiming to be revolutionary, and always with a snappy acronym like RAPID or CIRCLES.

And even though there are so many frameworks, how often have you actually applied one of them and felt like it really solved the problem in front of you instead of just producing some pretty slides?

So I’m not surprised if you feel like you’ve had enough.

But at the same time, I’d argue that frameworks are one of the most powerful tools at our disposal. In fact, I credit a lot of my success at work to the application of frameworks.

How do you reconcile this? I think the dissonance comes from the fact that a lot of people use frameworks wrong. This article is trying to fix that.

We’re going to cover:

Why frameworks are so valuable (and you shouldn’t ignore them)
The problems with how people use frameworks
The different types of frameworks and what they’re good for
How to use frameworks effectively (incl. detailed real-world examples)

Let’s dive in.

Why frameworks are so valuable (and you shouldn’t ignore them)

In my view, frameworks provide two main benefits:

1. Frameworks make success repeatable

Using frameworks (correctly) allows you to de-risk your problem-solving. If you completely reject frameworks and wing every problem you encounter, you’ll probably get mixed results; sometimes you’ll stumble upon the right solution, and sometimes you’ll miss important things. Frameworks make it so that your success is easily repeatable.

In addition, it’s easier for others to follow along. The approach is clearly spelled out and everyone is speaking the same language, especially if they are already familiar with the same framework.

2. Frameworks provide a shortcut

At their core, frameworks are the insights and experience of some of the smartest people packaged up for you to borrow. Why would you pass up this opportunity?

You might arrive at these thoughts on your own, but using frameworks gives you a shortcut.

Sometimes, you have even been doing parts of what a framework suggests already, but having it formalized can still help “clean up” your partially-formed thoughts.

It’s no surprise that frameworks are at the core of how top consulting firms like McKinsey or BCG operate; they allow them to come in, quickly understand the core dynamics and challenges of a business, and frame clear recommendations.

The good news is: This stuff isn’t secret, and you don’t have to grind three years in consulting to learn it. That’s what newsletters are for 🙂.

The problem with how people use frameworks

Whether frameworks level up your work or give you burnout depends on how you use them. Here are the most common misconceptions I’ve observed that lead to subpar results:

Issue #1: You don’t always have to use a framework

This is a common theme especially with ex-consultants. If you’re used to thinking in frameworks, then there is an instinct to slap one on every problem you encounter.

But that’s not always needed. Good ol’ fashioned critical thinking is often more efficient; using a framework in these cases feels forced and overly academic and you might be viewed as someone who fits better into business school than a startup.

Issue #2: Frameworks aren’t a substitute for critical thinking

Many people use frameworks as a substitute for thinking through a problem on their own. They take a quick look at the situation, try to “categorize” it, and then just run through the motions of a framework they pick.

Without 1) deeply thinking through the problem first and 2) customizing the framework to the situation, this often ends up in disaster. For example, more candidates than I can count sabotaged themselves in case interviews I gave because the moment they decided on a framework to use, they got tunnel vision and stopped having a real conversation with me.

Frameworks are a great starting point, but you should never just blindly run through the motions or force it onto a problem.

It’s very similar to AI in that way: You shouldn’t outsource your thinking to AI completely, but rather use it as a help in your own reasoning process and critically engage with anything it generates.

Issue #3: Frameworks aren’t rules, they’re guidelines

Frameworks are designed so that they are comprehensive and “foolproof”. As a result, many of them have a lot of steps or components to them.

However, I’d argue that most frameworks have one or two simple key insights that create most of the value. Everything else is fluff around it.

For example, the Jobs-To-Be-Done (JTBD) framework is fairly complex and intimidating when laid out in its entirety:

But in my experience, 95% of the value comes from simply shifting your mindset to start with understanding the specific “jobs” customers need done, and then working backwards from there (instead of starting with your product or service and its features).

Sometimes it even feels intentional when people make frameworks seem needlessly complex and then offer consulting services around them (*cough* OKR implementation consultants *cough*).

But just because the framework is complex doesn’t mean you have to go through all of its steps. When people do that, it’s usually a sign that they haven’t deeply understood the purpose of the framework and how to apply it. It’s like reciting a definition from a textbook instead of explaining something in your own words.

Instead, pick the pieces that provide the most value and apply the best to your situation, and tweak them as necessary to fit your needs.

The different types of frameworks – and what they’re good for

At a high level, there are two types of frameworks:

General-purpose frameworks that give you high-level structure or best practices
Prescriptive frameworks that give you detailed instructions on what to do or what to think about for a particular use case

Imagine you want to assemble a piece of furniture. The first type of frameworks are like the tools you’re using; they do a specific thing, but they can be used for a number of tasks and in different contexts (e.g. you might be able to reuse the wrench that came with your furniture for something else).

The second type of frameworks are like the instruction manual that came with it. It tells you exactly how to do things: What part goes where, and in what order you should assemble them.

Both types of frameworks are helpful, just in different ways. We’ll double-click on each category next.

1. General-purpose frameworks

These frameworks help you think through a problem — or communicate something — in a structured way. In the process, they often help you reduce a problem to its essentials.

They are highly flexible and can be applied to a wide range of topics, but you’ll have to customize them based on the situation and “build them out” yourself.

Here are some of the most helpful ones (note: all of these have done a lot of heavy lifting over the course of my career):

Framework #1: Issue tree

This is my absolute favorite general-purpose framework. The idea is simple:

You take a problem and you break it down into its subcomponents. By organizing things in a tree structure, relationships are immediately obvious.

This can be applied in a ton of different contexts. For example:

Problem solving

An issue tree helps you to list out the various levers or options you can choose from to address a problem in the business.

You start by listing out the broad categories and then fill in more detail until you reach concrete initiatives you can prioritize.

Let’s look at an example:

Imagine you are trying to increase the amount of time users spend on your app. That’s the goal you put at the top of your tree
Then, you list out the high-level options you have. In this case, you can grow your goal metric by either 1) growing the number of users, or 2) increasing the time each user spends on the app
Now, we break things out into more detail.
- New users can come from a variety of different channels
- Similarly, you can increase the time users spend by either 1) getting them to open the app more often or 2) growing the duration of each session.

By continuing this process of breaking out higher-level buckets into smaller ones, you create an issue tree step-by-step:

Investigations

Issue trees also provide an incredibly helpful structure for investigations into metric movements.

You can either do a purely mathematical decomposition of the metric you’re investigating (creating a “driver tree”), or you can create a set of hypotheses organized in tree form (called a “hypothesis tree”).

Both will yield similar results; here is an example of how you can investigate a revenue drop in B2B SaaS:

Decision-making

For recurring decisions, it can be helpful to lay out the key considerations in a tree (called a “decision tree”). The questions should be posed as “Yes” / “No” questions, and the most important considerations should be at the top of the tree.

Besides streamlining and standardizing the decision-making (e.g. when you want to delegate it to someone else) this also gives stakeholders transparency around how the decision was made.

For example, let’s say your team is regularly getting requests from stakeholders and they have to figure out whether to take them on or reject them.

A decision tree for this scenario could help set expectations:

Note: In my experience, creating actionable decision trees can be very difficult; for example, instead of simple “Yes” / “No” questions you might have to define what to do based on a spectrum (e.g. “If revenue impact >$X, then this, otherwise that”).

As a result, I’d recommend to only use this technique selectively in cases where you feel like the effort is worth it for standardization purposes.

Framework #2: MECE

MECE is more of a principle than an actual standalone framework. I think about it as a force multiplier: Once you adopt this technique, your frameworks will be 10x more impactful.

The core idea is that any time you break down a problem, that breakdown needs to result in buckets that are Mutually Exclusive and Collectively Exhaustive. This means:

None of the buckets or categories you choose can overlap (i.e. every single data point or example fits into just one bucket), and
They need to cover all possibilities.

This is especially helpful for creating clean issue trees:

I wrote an in-depth article describing how to apply the MECE principle in practice with tons of real-world examples as a guest post for Jordan Cutler ‘s High Growth Engineer newsletter; check it out here if you want to go deeper.

Framework #3: 2x2 matrix

The 2x2 matrix is simple but powerful.

To build one, you simply choose two dimensions that are relevant for your problem (those are your axes) and two variants for each (typically along the lines of opposites like “High vs. Low”), dividing your grid into four areas.

This simple visualization comes in especially handy when you’re trying to frame problems; instead of going in circles trying to consider every nuance, you’re just focusing on the essentials.

For example:

Let’s say you want to figure out if, and how, you should use AI for a task. To simplify this decision, you could categorize tasks based on:

Whether they are mostly execution-focused or require judgment / decision-making
Whether the stakes are high or low

The resulting grid then gives you four interaction models with AI depending on the task at hand:

Framework #4: Pyramid principle

The Pyramid Principle is the most effective communication framework I know. It’s powerful for a few reasons:

It makes sure the key point of your message gets across
It helps you be perceived as a senior contributor or leader, regardless of your actual level
It can be applied to basically anything

The Pyramid Principle doesn’t tell you what exactly to say; it just tells you to start with the key insight or recommendation and then add supporting arguments and data (to the degree they’re necessary to support your point).

After an investigation, tell people whether the outage is fixed (and what you’ll do if not), then what caused it; only get into the details of your investigation if asked
Give the CEO the recommendation first, then talk about alternative options and their pros and cons
In an interview debrief, say first whether you’re for or against the hire, then list out your reasons

This is the exact opposite of the default approach many of us take; we go through our analysis and all the challenges we encountered along the way, and by the time we get to the takeaway, everybody already stopped paying attention.

Unlearning this takes some time, but it’s the most impactful change you can make to how you communicate.

Framework #5: 5 Whys

When you’re looking into problems at work, there are two common (related) challenges:

You’re fixing a symptom, but the root cause remains unaddressed
You’re completing a stakeholder’s request, but you didn’t have context on the actual problem they were trying to solve, so the result is subpar

Both issues can be addressed by asking “Why?” repeatedly.

Here’s an example:

Sometimes, three “Why?”s is all it takes

With the additional information on why things are happening, you can address the actual root cause instead of coming up with bandaid solutions for the symptoms.

For example, you could propose that Marketing should also have a target on the conversion rate of their leads.

The key with all of these general-purpose frameworks is to practice, practice, practice until they become second nature.

These days, for example, I don’t actively try to make something MECE anymore. It’s my default, and if something isn’t, it gives me mental (and sometimes physical) discomfort.

This means:

For any problem you come across, always try to uncover the “true” underlying root cause. Then, try to create an issue tree to structure the problem
Test if your framework is MECE: Brainstorm examples and see if they fit into one, and only one, of the buckets you created
Come up with 2-3 different ways to frame the problem (or parts of it) using a 2x2 matrix
Use the Pyramid Principle every time you communicate your work. Share a minimum level of supporting data; then, notice what follow-up questions people ask and anticipate these next time

2. Prescriptive frameworks for a particular use case

The first category of frameworks consisted of flexible general-purpose tools —Swiss army knives, if you will. They are incredibly useful, but their biggest advantage is also their biggest weakness: They don’t really tell you what to do — only how to do it.

As a result, there is a huge category of frameworks that cater to specific use cases and give you prescriptive, sometimes step-by-step, instructions. They are easier to use, but less flexible and often feel more “forced” when applied to a problem.

Many of these frameworks are simply more specific versions of the first category. For example, there are several well-known frameworks such as the BCG Matrix or the Ansoff Matrix that are just 2x2 matrices tailored to a particular use case. Similarly, the popular Opportunity-Solution-Tree is just a specialized version of the issue tree presented above.

The biggest mistake people make when applying these frameworks is to study them in-depth and then apply them to the letter.

As discussed earlier, this approach often creates more harm than good. Instead of just checking all the boxes, try to think of these frameworks as:

🤔 A starting point for your thinking, and
🚧 A safeguard to ensure you’re not missing an important consideration completely.

Here are some of the most helpful ones:1

Substack won’t let me create a table in the editor, so I am adding links with more detailed information on each framework in the footnotes.2

How to use frameworks effectively

The general process for using a framework effectively looks like this:

Deeply understand the problem
Decide what output you need and choose the appropriate framework
Customize the framework to your use case

Step 1: Understanding the problem

I’ve written about this in more detail here; but the gist of it is that if you don’t fully understand the problem in front of you, you can’t come up with the best solution.

As a first step, you need to understand the problem in its entirety. Then, you simplify it by focusing on the factors that matter most.

At the very least you should consider:

What is the actual problem you’re trying to solve?
- Is there an underlying root cause you can trace the problem back to? (“5 Whys” from above comes in handy here)
- What are different ways to frame this problem?
What is the cost of being wrong?
- If a decision is easy to reverse or the cost of being wrong is low, you can use a simpler, more streamlined problem-solving or decision framework (or not use a framework at all)

Once you’ve worked through enough problems, you’ll start to put them into certain “buckets” in your head. For example, after working on a few launches, any time you hear the words “new product” or “expand into new market” you might think “Oh, another launch problem; I know how to deal with that!”.

That’s perfectly fine — as long as you still go deep on the problem to see if there is anything unique about this situation.

Starting with a mental model based on experience is great, but no two problems are 100% alike, so you still need to go through the next steps to pick and customize the right framework instead of copy-pasting what you did last time.

Step 2: Deciding what output you need and choosing the right framework

Not every framework does the same thing.

Some frameworks change your thinking or help you view a problem in a novel way
Some create clarity on process or roles and responsibilities, or they give you a standardized process you can follow
Others help you compile a list of experiments to try or areas to investigate

As a result, you need to work backwards: Decide first what you need, and then pick the framework that will be the most helpful in producing that.

For example, let’s say you need to make a decision. Which framework you should use depends on your needs:

Step 3: Building out your problem-solving approach iteratively

Most problems are too complex to solve them end-to-end by applying a single framework or analysis. As a result, you’ll have to pick a starting point and then iterate from there.

This can mean using a formal framework as a basis and adding some custom problem-solving on top, or it can even mean combining multiple frameworks.

For example: Imagine you want to figure out how to improve profitability for a business.

As a first step, you could create a tree that breaks out profits into revenue and cost, then cost into the individual fixed and variable cost components etc. This will give you a good idea of the different drivers you could optimize
However, you still need to brainstorm concrete initiatives to actually drive improvements
And as a third step, you’ll need to decide which ones you should focus on. For this prioritization exercise, you could then plot the different initiatives into a 2x2 matrix with expected impact on one axis and effort or time to impact on the other

A hands-on example of frameworks in action

Now, to make it really tangible what effective use of frameworks looks like in practice, I’ll go through a real-life example. I’ll focus on an interview case I used to give since in these situations I was able to see how somebody solves a problem end-to-end.

However, all of the points I’m making here apply equally to problems you’re solving on the job.

The question I would give candidates was along the lines of:

“Imagine you’re on the BizOps team and working with the Head of Customer Support. The team is heading towards their annual peak season and they want to make sure they’re prepared. Specifically, they want to avoid building up a ticket backlog.
How would you approach this problem?”

There were three types of candidates:

Approach #1: Straight into execution (no framework)

Many candidates would immediately start brainstorming concrete things they could do. For example, they’d throw out ideas like “We could use AI to automate a lot of the tickets" or “We should improve training and create better templates for common problems”.

While some of the ideas were actually pretty good, they weren’t structured in any way.

This always caused one or several of the following issues:

The lack of structure meant they would run out of ideas a few minutes into the case
They didn’t ask for more context, so a lot of the ideas were fairly generic and it was unclear which ones would be most impactful to the team’s specific situation
It wasn’t clear if they had actually solved the problem since they didn’t have a structured way to tie their ideas back to the “zero backlog” goal

Approach #2: Going through a generic framework from A to Z

The second type of candidate would think for a moment, maybe ask a clarifying question or two, and then announce which framework they would use.

The frameworks they chose were typically generic ones that provided a broad structure for their brainstorming. For example, several candidates chose the “3P Framework”, which allowed them to group their ideas into People-, Process- or Product-related ones.

While this gave more structure compared to the first group of candidates, the approach still had major issues:

Organizing ideas by qualitative buckets still didn’t help us understand if, and how, we’d get ticket backlog to zero
Candidates usually went through their entire framework, wasting valuable time and making it feel like they were checking the boxes rather than solving a problem
The rigid structure of the frameworks made a real conversation difficult, and candidates usually struggled to incorporate any new information they learned along the way

Approach #3: Developing a custom framework on the spot

The most successful candidates all took the time to deeply understand the problem and then tailor their approach to it.

In this case, they would realize that preventing a backlog meant the support team’s capacity during peak season had to equal the time required to solve all the tickets that come in on a given day.

They would then figure out that to solve this problem, they would 1) first need to forecast the expected number of tickets during peak season and compare that to the team’s current capacity to understand the potential gap, and then 2) evaluate the potential levers they have to plug that gap:

⬇️ Reduce the # of tickets the team will receive during the peak period
⬆️ Increase the # of tickets solved per hour
⬆️ Increase the total # of hours worked

Most candidates that got to this point would then realize that this type of problem is an ideal fit for an issue tree and would start building one out.

While you’re building out an issue tree, it can be helpful to apply other frameworks to brainstorm ideas. For example, some candidates used the 3P framework mentioned above to brainstorm initiatives specifically to reduce the number of tickets (the right branch in the tree).

Prescriptive frameworks aren’t bad per se; it’s just that they are rarely the right first step in solving a problem.

Finally, once the issue tree is built out, what’s left is to prioritize the most promising levers to plug the expected capacity gap. To do this, you could use a framework like Meta’s traffic light matrix to compare your options across multiple dimensions (e.g. expected impact, time to implement, what would happen after the peak season is over etc.).

It doesn’t really matter what exact approach you choose; but the strongest candidates all had a structure for evaluating their options in a principled way.

The bottom line is: There isn’t just one right way to solve a problem. However, there are key considerations that you need to think through to get to a robust solution. And whether — and how — you use frameworks plays a big role in how easy it will be to do that.

TL;DR

I’ve relied heavily on frameworks throughout my career. Without them, it would have felt like I had to reinvent the wheel for everything I’ve been doing.

As with everything in life, frameworks aren’t inherently good or bad. They’re just a tool, and whether they level up your execution or result in generic output that misses the mark depends on how you use them.

Hopefully, this article helps you unlock their value and turn them into a competitive advantage.

P.S. Given the sheer volume of examples I had to whip up for this post, I’m sure I made a mistake somewhere. Hit me up if you find something and we can nerd out about frameworks.

💼 Featured jobs

Ready for your next adventure? Here are some of my favorite open roles, brought to you by BizOps.careers (sorted from early to late stage):

Writer: Chief of Staff, CRO | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: SF, Chicago | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: Flexible | 🚀 𝗦𝘁𝗮𝗴𝗲: Series C | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: ICONIQ, Radical Ventures

Airbnb: Programs and Business Operations Lead | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Remote | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $164k - $204k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 10+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Public

📚 What I enjoyed reading recently

How custom GPTs can make you a better manager by Hilary Gridley / Claire Vo: A highly actionable deep dive into how to leverage AI to scale yourself as a manager
Math to Evaluate Sales Reps & GTM by OnlyCFO: A brief, helpful overview of efficiency metrics for sales reps
AI's Missing Multiplayer Mode by Charlie Guo: A brief preview of what more collaborative AI tools might look like in the future
How to use the AI-boom to level up in your career and land a job by Sophie and Jordan Cutler: Practical tips on how to leverage AI with concrete prompt examples. Most of it is helpful to engineers and non-engineers alike
An analytical guide to people-watching in NYC by Joe Hovde: It’s people watching season, and this is your guide to NYC’s best spots

There are way too many frameworks to list here given this post is more about how to apply frameworks rather than a comprehensive repository. However, if there’s interest, I might create a structured framework repository in the future. Shoot me an email if you’d find that helpful

Jobs To Be Done: https://jobs-to-be-done.com/jobs-to-be-done-a-framework-for-customer-needs-c883cbf61c90

Working Backwards: https://www.aboutamazon.com/news/workplace/an-insider-look-at-amazons-culture-and-processes

CIRCLES: https://www.lewis-lin.com/decode-and-conquer

Ansoff Matrix: https://en.wikipedia.org/wiki/Ansoff_matrix

AARRR (Pirate Metrics): https://amplitude.com/blog/pirate-metrics-framework

Opportunity Solution Trees: https://www.producttalk.org/2023/12/opportunity-solution-trees/

RAPID: https://www.bain.com/insights/rapid-decision-making/

SPADE: https://coda.io/@gokulrajaram/gokuls-spade-toolkit

Meta Traffic Light: https://naomi.com/the-traffic-light-approach-to-problem-solving-7b3d6e42acc2

OKRs: https://www.whatmatters.com/

MBO / S.M.A.R.T. Goals: https://en.wikipedia.org/wiki/Management_by_objectives

4 Comments

Ready for more?