Fact-Based Thinking: how we adapt The McKinsey Way for decisions that actually solve the problem

What counts as a "fact" in this framework

Fact-Based Thinking comes from The McKinsey Way by Ethan M. Rasiel, which describes how McKinsey & Company structures its consulting work. We adapted the idea for our context: a digital agency that needs to decide quickly, but also needs decisions to hold up later.

The starting point is the hypothesis. A hypothesis is a structured guess about what's true, set up specifically so it can be tested against real data. The data that tests the hypothesis falls into two categories:

Qualitative data comes from observation, interviews, and contextual collection. It answers "why" and "how" questions, and it captures nuance that numbers can't.

Quantitative data comes in numerical form with a clear source. It answers "how much" and "how often," and it scales the qualitative observations into something measurable.

The short version of how we define a fact: data with a traceable source and reasoning that holds together when examined. Anything missing one of those two halves isn't yet a fact, it's an opinion or an assumption.

How SUFFIX applies Fact-Based Thinking in practice

The framework only matters if it changes day-to-day work. Here's how the three practices show up across our projects.

Research: where we go to find data

Every piece of data we use needs to come from somewhere we can name. Credible source, clear attribution, supporting evidence elsewhere. Anything less is "people say" or "everyone knows," which sound like facts but aren't. If we can't say who "people" are or how many "everyone" is, the data doesn't qualify.

The tools we use depend on what kind of data we need:

Social Listening Tools for sentiment and behavior on the open web. Social media, community groups, forums. We look at what the audience is actually saying, how often, and with what emotional tone. Useful when the question is "what do real users feel about this?"

Research Databases like Statista and Euromonitor for industry-level data that's been collected, cited, and cleaned. Market size, trend lines, demographic statistics. These work when we need numbers with the credibility to defend in a client conversation.

Analytics Tools like Google Analytics and Hotjar for behavioral data on a specific digital product. Where users drop off, where they stop scrolling, which elements get ignored. Useful when the question is about a specific website or application rather than the broader market.

Choosing the right tool depends on the question. Using behavior data to answer a brand sentiment question, or sentiment data to answer a conversion question, produces noise rather than signal.

Fact and bias check: testing the data before trusting it

Finding data is half the job. Validating it is the other half, and the one most teams skip when they're moving fast.

We use a simple three-step framework to test whether data is real or just feels real:

Volume. Is this mentioned by enough people to suggest a pattern, or is it a handful of vocal individuals? A few loud voices can sound like consensus when they aren't.

Context. Are the people saying this actually the target audience? A complaint from someone outside the target demographic is a data point, but not necessarily a signal for the project.

Contradicting data. Is there evidence pointing the other way? If 100 users complain about a feature and 1,000 use it daily without complaining, the complaint is real but probably not the whole story.

A concrete example: we observed that some users were posting about a client's app being too complex. With only a handful of mentions, that's likely individual bias, not a pattern. But when the same complaint appears across multiple channels, with consistent wording, and from users who clearly fit the target audience, it crosses into fact territory. We also actively look for the opposite signal: how many users describe the app as easy to use? Looking at both sides produces a fact that's actually useful, not one that confirms what we already wanted to believe.

Track record: writing things down so they don't drift

SUFFIX defaults to written communication tools across the team. Not because we dislike conversation, but because writing creates a record we can return to. Time-stamped, searchable, and unambiguous in a way memory isn't.

This matters because the work we build on doesn't come from what people remember about a meeting last month. It comes from what was actually said and decided, captured at the time. Project discussions, problem-solving sessions, idea proposals, everything goes into writing.

In client meetings, we listen to the problem first and then present facts: statistics, sources, references that hold up. That keeps the conversation grounded in reality rather than impression. In internal meetings, we schedule ahead of time precisely so the team has space to gather the facts before discussing. Meetings that start from prepared evidence are dramatically shorter and more useful than meetings that start from "what do we all think?"

We believe work grounded in fact produces results that actually solve client problems. That's the core argument for going through the discipline of this framework, even when it slows things down at the start.