I Ran 21 Miles I Was Not Ready For

A year before the race, I signed up for something I could not do.

The Big Sur 21 miler has a six hour cutoff. When I registered, the math felt generous. Six hours seemed like enough time to finish even if I walked the whole way. And the image in my head was lovely. Highway 1 on foot. A road most people only ever see through a windshield, closed to cars, mine to move down slowly with the ocean on my right.

That was the whole reason I signed up. Not a time goal. Not a personal record. I wanted to be on that road.

Then I started training, and the math fell apart.

Walking the entire course would not fit inside six hours. Not at my pace. I would have to mix walking and running, which meant I could no longer show up and see what happened. I needed a strategy. If I ran too much early, I would not have the legs to even walk at the end.

So I went looking for a plan, and I could not find one.

Every strategy I found was written for a different person. Runners chasing a finish time. Experienced marathoners managing their fifth or tenth race. Plans that assumed you could already cover the distance and were now optimizing. There was nothing for someone whose actual goal was to finish under a cutoff by combining walking and running.

I have felt this exact thing in my career, and I suspect you have too. You look for the roadmap and every version you find was built for someone with more experience, more runway, more of something you do not have yet. The advice is not wrong. It is calibrated to a different person's situation.

At some point you accept that nobody wrote the plan for your circumstances, and you build it yourself.

What I Came Up With

Mine had three parts.

Walk every uphill. Run the flats. Take time back on the downhills.

That last one goes against standard advice. Running fast downhill beats up your legs and most coaches will tell you to hold back. But I was not preserving my legs for a strong finish. I was banking minutes against a cutoff, and the downhills were the only place minutes were available to me.

Second, real food. The typical energy gels made me gag, so I tested different options on training runs until I found things my body would accept while moving, and I planned to eat every few kilometers. Six hours on the road is a long time to be running on nothing.

Third, and this turned out to matter most, I decided in advance that I would only look at two numbers on my watch. Pace and heart rate. Not the clock.

I practiced the walk-run pattern several times at around 25 kilometers. I wanted to reach 30 at least once. I never got there. Twenty one miles is about 34 kilometers, which means I arrived at the start line having never come within 9 kilometers of the distance.

I knew that. I stood there knowing my longest run was well short of what the day required, holding a strategy I had built over months and never fully tested.

So I made one more decision before the gun went off. If I had to stop somewhere in the middle, fine. Oh well. But I was not going to abandon my plan while I was still moving. Falling short was allowed. Panicking and improvising was not.

The Math I Never Did

I finished in five hours and fifty minutes.

I want to be honest about why, because there is a version of this story where I take all the credit and it would not be true. The weather that day was cloudy, cool, slightly rainy. Excellent conditions for running. If it had been hot, my strategy would not have saved me. I do not think I would have finished.

Conditions get a vote. They always do, in races and in careers. The market, the timing, the hiring freeze, the reorg, the person on the other side of the table who is having a hard week. You do not control any of it.

But here is the part I do think I earned.

I never thought about the time.

I knew where I was on the course. There were mile flags, so distance was not a mystery. What I never did was the math. This much time gone, this much course left, here is the pace I would need to hold to make the cutoff, and can legs that have never gone this far actually hold it.

Not once, over five hours and fifty minutes.

And I am fairly certain that if I had run those numbers, I would have quit. Somewhere around mile twelve the arithmetic would have added up to too much. Good weather and a working strategy and all, I still believe that calculation could have ended my race.

Pace and heart rate asked me a different question. Am I doing my job in this mile. That was a question I could answer, and answer again, and answer two hundred more times.

Three Things I Keep Coming Back To

You will move before you are ready, and that is normal.

I signed up a year out, when I was significantly less capable than the race required. That commitment is what created the training. If I had waited until I could already run the distance, I never would have registered, because I could never run the distance.

The interview you take before you feel qualified. The application you send while the gap is still open. The reach out to someone whose work intimidates you a little. Those moments are not reckless. They are how you become the person who can do the thing.

The plan has to be built for your actual situation.

Not the situation of the person whose advice you found. If a networking approach was designed by someone who loves working a room and you do not, it is the wrong plan for you no matter how well it worked for them. If a preparation method assumes you already have two offers in hand, it is built for a level of pressure you are not under.

Borrowing a strategy built for a different person and different stakes is one of the most common reasons capable people underperform in the moments that matter most to them.

Watch the strategy, not the clock.

This is the one I want to leave you with.

The clock in a career is that running calculation about whether you are going to make it. Is this going to turn into an offer. Is this relationship going anywhere. Am I behind where I thought I would be by now. How much time do I have left to make this work.

The strategy is a different question entirely. In an interview, it is whether you are answering the question you were actually asked and telling the story you prepared. In networking, it is whether you reached out to the people you said you would reach out to.

The clock is real, and I am not going to pretend otherwise. But running that math in the middle of the effort mostly produces one conclusion, which is that there is too much left and not enough of you. Meanwhile the strategy sits right there, answerable in the current mile, entirely inside your control.

None of this means never change your plan. It means the unit of commitment is one attempt, not forever.

You will rarely have a tested strategy going in. Usually you have a few options and a hunch about which one fits your situation best. Choose that one, then hold it through the thing itself, the actual interview, the actual conversation, the actual six hours on the road. The middle is when you have the least information and the most fear, and the changes people make there are almost always panic rather than strategy.

When it is over, that is when you think. What worked. What did not. What was the weather. Change what needs changing, and hold the new version through the next attempt.

Commit, execute, review, adjust. The mistake is not sticking with an imperfect plan. The mistake is rewriting it mid-effort, or finishing and never reviewing it at all.

What I Took Home

I crossed that line 9 kilometers past anything I had ever done, with ten minutes to spare, on a road I had wanted to walk down for a year.

Not because I was ready. I was not ready. I was undertrained, holding an untested plan I had cobbled together because nobody had written one for me, prepared to fall short and doing it anyway.

You do not need certainty to start. You need a strategy you believe in and the discipline to stay with it while the outcome is still unknown.

The finish line does not need your attention right now.

This mile does.

How to Make Networking Actually Work for Your Career

You already kno;w you're supposed to network. It's the advice in every career conversation, and it's true: opportunities come through people, not applications.

And yet most of the accomplished professionals I work with quietly resist it, and many who push through feel like it doesn't work. The resistance usually sounds like:

• "I'm not job searching, so I don't need it."
• "My manager already knows what I'm doing."
• "Asking people for things feels transactional."

Every one makes sense. Underneath them is a single belief: that networking is a tool you pick up to land a big result, a job or a promotion, and ideally soon.

That's why it disappoints. Networking is slow. Trust takes time to ripen. Reach out only when you need the big thing and you're already too late, and you can hear the transaction in your own voice. So can they.

Even a promotion isn't something your manager hands you alone. One unconvinced person in the calibration room can block it. What moves it is a room that already knows your value, and that's built long before the decision.

What the long game looks like

My first industry job came after I left academia. Not a fresh grad, but with zero industry experience to draw on. The company was tiny, which I loved: I could pitch an idea Monday and ship it Friday.

But I kept wondering about what I couldn't see. How were bigger companies solving problems I'd never met? So I started reaching out to people at larger companies, not to find a job, just to learn.

One of those conversations led to a role at LinkedIn.

I didn't network to get hired. I was curious, with a specific question. The job came much later: a door I didn't know existed, opened by a relationship I'd built for another reason entirely. The payoff rarely comes from the conversation you have today. It comes from the trust that conversation starts.

So what are you networking for?

If the goal isn't "land something now," what is it? It depends where you are:

• New to a team or org: Learn the work, the challenges, the culture, where you fit. Meet the people you'll work with closely.
• Already ramped up: Understand how the parts connect to the bigger goal, so you can spot the best moves. Meet a few people on each team, even ones you don't work with.
• A senior leader: See how other orgs handle what you're facing, and bring better options back. Meet peers in similar roles elsewhere.
• Carrying a vision: Get it in front of enough people that the ones who resonate can find you. Share widely.

Network this way and you start to:

• See the bigger picture and bring sharper ideas.
• Read each team's real needs and align them.
• Spread the ideas you believe in.
• Become known as a leader.

That reputation opens doors later: the promotion, the recruiter, the role you want. In short, you become indispensable.

How to make it feel lighter

Here's where the dread lifts. What makes networking feel like aimless small talk, or worse, like begging, is walking in without knowing what you want from it.

The fix isn't to need less. It's to get specific. Not "land me a job," but one small, concrete thing from this single conversation: a piece of context, their take on a problem, an introduction. That clarity is what makes the time worth it, for you and for them. You leave with something real, and so do they.

Before you reach out, work through four questions.

The four-part plan

1. Purpose: why. What do you want from this? Information, influence, a decision? Think past this quarter to the relationship you want a year out.

2. People: who. Map widening circles:

• Inner org: teammates, your manager.
• Wider org: cross-functional partners and leaders, at your level and one up. (E.g. An analytics director should know the directors and VPs in product, marketing, sales, engineering, finance, legal, HR.)
• Industry: peers elsewhere, communities, people you admire, alumni.
• Adjacent: clients, vendors, former colleagues.

3. Message: what you say. Usually one of four:

• Inform: share your vision, goal, or win.
• Input: ask for their thinking.
• Information: ask for something you don't have, like context or an intro.
• Action: ask for a specific action, like make a decision.

4. Offer: what you give. Keep it two-sided. What's their challenge, and how can you help? Even small counts: useful info, an intro. Not sure what they need? Make finding out your task.

Then take one real step

A plan in your head is a wish. Close the loop: one person, one date. Not twelve. One name, one date. That's the line between thinking about relationships and building them.

If you want a space to build your plan with other accomplished professionals, and a nudge to send that first message, the Women Leaders Club is made for exactly this.

One last reframe

Your resistance isn't a flaw. It's a sign you don't want to use people, and that instinct is worth keeping. The good news: the networking that actually works asks the opposite of you. Build genuine relationships, before you need them, with people you'd want to know anyway.

You already do meaningful work. Now let the right people know you, so that when the door opens, they already see you on the other side.

Where could one curious conversation take you, if you started it before you needed anything?

The McKinsey 7-S Framework: A Simple Guide to Aligning Your Organization

Most strategies don't fail because they're wrong. They fail because the rest of the organization isn't built to support them.

You can have a brilliant plan, but if your structure, systems, and people aren't aligned with it, the plan stays on paper. This is the problem the McKinsey 7-S Framework was designed to solve.

Developed in the late 1970s by Tom Peters and Robert Waterman at McKinsey & Company, the 7-S Framework identifies seven internal elements that need to work together for an organization to succeed. It has outlasted decades of management trends because it answers a question that never goes out of style: why isn't this working the way we thought it would?

It's also a powerful way to share your vision and influence leadership. Whether you're making the case for change in your current role or walking into a job interview, the 7-S Framework gives you a structured way to demonstrate strategic thinking — to show how you see the whole organization, not just your piece of it.

What the 7-S Framework Is

The model maps seven interconnected elements of an organization. Change one, and the others feel it. The seven elements are grouped into two categories:

Hard elements (easier to identify, easier for leadership to influence directly):

• Strategy — your plan for competing and winning
• Structure — how the organization is arranged (reporting lines, departments, hierarchy)
• Systems — the daily processes and tools that get work done

Soft elements (harder to pin down, shaped by culture):

• Shared Values — the core beliefs at the center of the organization
• Style — how leadership shows up and operates
• Staff — the people and their general capabilities
• Skills — the specific competencies the organization has

Shared Values sit at the center of the model. Every other element depends on them. When values are clear and lived, the rest of the system has something to organize around. When they're not, the other six elements drift.

Breaking Down the Seven Elements

1. Strategy

Your strategy is how you plan to build and maintain a competitive advantage. It answers:

• What are we trying to achieve?
• How will we respond to competition and shifts in the market?
• How does our strategy adapt to changing customer needs?

Strategy only works when the rest of the organization is built to execute it.

2. Structure

Structure is the architecture of your organization: who reports to whom, how teams are divided, where decisions are made.

• Is decision-making centralized or decentralized?
• How do departments coordinate?
• Where are the formal and informal lines of communication?

A structure that worked at 10 people often breaks at 50. A structure that supports innovation can be the wrong fit for scale.

3. Systems

Systems are the processes and tools that keep daily work moving — financial systems, HR processes, communication platforms, project management workflows, decision protocols.

• What systems do we rely on most?
• How are they monitored?
• Where are the bottlenecks?

Outdated systems quietly drain energy from every other part of the organization.

4. Shared Values

Shared Values are the core beliefs and standards that guide behavior. Not the values posted on the website — the ones actually lived day to day.

• What do we genuinely stand for?
• What does our culture reward and tolerate?
• How strong and consistent are these values across the organization?

When shared values are vague or contradicted by behavior, every other element gets harder to align.

5. Style

Style refers to leadership and management approach. It includes how leaders communicate, make decisions, and handle conflict.

• Is leadership collaborative or directive?
• Do teams actually function as teams, or are they groups in name only?
• How effective is leadership at modeling what's expected?

Style shapes culture more than any mission statement.

6. Staff

Staff is about the people in the organization — who's there, what roles exist, and where the gaps are.

• What roles and specializations do we have?
• What positions are missing?
• How are we developing the people we have?

Staff decisions shape what the organization is capable of becoming.

7. Skills

Skills are the specific capabilities the organization is known for — what it actually does well.

• What are our strongest competencies?
• Where are the skill gaps?
• How do we monitor and grow skills over time?

Skills and Staff sound similar but answer different questions. Staff is who you have. Skills is what they can do.

When to Use the 7-S Framework

The framework is useful any time you need to understand how the pieces of an organization fit — or why they don't. Common applications:

• Improving performance in a team or company that feels stuck
• Implementing a new strategy
• Navigating a merger, acquisition, or major restructure
• Onboarding new leadership
• Diagnosing why change efforts keep stalling
• Aligning a fast-growing team that's outgrown its original setup
• Making the case for change to senior leadership in a structured, credible way
• Preparing for a leadership interview, where you want to demonstrate strategic thinking about the organization you're hoping to join

It works at the organization level, but also at the level of a department, team, or project.

How to Apply It

Here's a practical sequence:

Step 1: Start with Shared Values. Are they clear? Are they consistent with your current strategy, structure, and systems? If not, name the gap.

Step 2: Examine the hard elements. Look at Strategy, Structure, and Systems together. Do they reinforce each other, or are they pulling in different directions? A growth strategy paired with a structure built for stability is a common mismatch.

Step 3: Examine the soft elements. Style, Staff, and Skills. Do they support what the hard elements are trying to do? A strategy that requires bold decision-making won't work under a leadership style that punishes risk.

Step 4: Identify the misalignments. Where are the contradictions? Where is one element undermining another?

Step 5: Adjust and reassess. Change one element, and the others shift. This is iterative, not linear. Expect to circle back.

A simple way to track alignment: list the seven elements in a grid and check whether each pair supports the other. Mismatches are where the work is.

A Quick Example

Imagine a small company of five people. The founder's values shape everything. Strategy is clear. Structure is informal but functional. Systems are off-the-shelf and adequate. Everything aligns because it's small.

Now imagine that company at 30 people, selling into new markets. The original strategy has evolved, but the structure hasn't. New hires don't fully understand the founding values. Systems built for five people are buckling. The skills that made the early team successful aren't the skills needed now.

Nothing is broken on its own. But the pieces no longer align. A 7-S analysis surfaces this — not as a list of problems, but as a pattern. From there, the leader can make targeted changes: clarify values for new hires, evolve the structure, upgrade systems, build the missing skills.

That's the value of the framework. It turns a vague sense that something is off into a specific, addressable picture.

A Few Honest Limitations

The 7-S Framework is a diagnostic tool, not a prescription. It tells you where things are out of alignment. It doesn't tell you what to do about it. Two organizations with the same misalignments may need very different solutions depending on context, history, and people.

It's also a snapshot. Organizations are dynamic, and alignment is never permanent. The framework is most useful when revisited periodically — especially during growth, change, or strategic shifts.

Final Thought

The 7-S Framework endures because it reflects something true about organizations: success isn't about getting one thing right. It's about getting many things to work together.

When strategy, structure, systems, values, style, staff, and skills reinforce each other, performance follows. When they contradict each other, no amount of effort in one area will fix what's misaligned across the others.

This is also why the 7-S Framework is such a useful tool when you're trying to influence others. Walking into a leadership meeting — or an interview — with a 7-S lens shows you understand how organizations actually work. You're not just pitching an idea. You're showing how the pieces fit.

If something in your organization feels stuck, the 7-S Framework is a good place to start asking why.

Analytics Frameworks That Actually Help You Think

There is a moment every analyst knows. You've spent three days on an analysis, the SQL is clean, the charts look great, and you walk into the room ready to present. Then someone asks: "Wait! Is this actually the question we needed to answer?"

That moment is what frameworks prevent.

Frameworks are not bureaucracy. They are thinking tools, ways of organizing your work before you touch data, so that when you do, you're solving the right problem in a defensible way. This guide covers three phases of analytical work, defining the problem, deciding what to measure, and prioritizing your workload, and introduces the frameworks that make each phase rigorous.

Part 1: Defining and framing the problem

The most expensive mistake in analytics is answering the wrong question precisely. Before writing a single query, you need to understand what problem you're actually solving and for whom.

MECE principle

What it is: MECE stands for Mutually Exclusive, Collectively Exhaustive. It is a principle for breaking any problem into categories that do not overlap (mutually exclusive) and together cover everything (collectively exhaustive). Developed at McKinsey by Barbara Minto in the late 1960s, it is the foundation of structured thinking in consulting and equally powerful in analytics.

How it works: Before diving into data, draw out the possible explanations for the problem you're investigating. Check two things: first, that no explanation falls into two buckets at once (no overlap); second, that all possible explanations are covered (no gaps). If both conditions hold, your structure is MECE.

When to use it: Use MECE whenever you're trying to diagnose why something happened: a metric drop, a revenue shortfall, a spike in churn. It is also essential when building metric trees or designing dashboards, where you need to ensure that sub-metrics add up cleanly to a top-line number without double-counting.

A common pitfall: teams often group causes by the department that owns them (marketing, product, engineering) rather than by logical structure. This produces categories that overlap and miss edge cases. MECE forces you to think structurally, not organizationally.

Reference: Wikipedia — MECE principle

Issue tree (logic tree)

What it is: An issue tree is a visual problem-structuring tool that applies MECE logic recursively. You start with a big question at the top: "Why did revenue drop?" and branch it into sub-questions, each of which is narrower and more testable. You keep branching until you reach leaf nodes specific enough to be answered with data.

How it works: There are two types of trees. A "why tree" is used for root cause analysis: you ask "why?" at each level until you hit a testable cause. A "how tree" is used for solution design: you ask "how could we fix this?" and branch into options. The branches at every level must be MECE.

When to use it: Use an issue tree at the very start of any complex analysis, before writing any code. It is especially valuable when a stakeholder has come to you with a vague problem ("sales are down, figure out why") and you need to structure the space of possible explanations. It also forces you to have explicit conversations about scope — some branches may be out of scope or owned by another team, and it's better to surface this early.

Issue trees are also useful in stakeholder presentations. Walking someone through a tree makes your reasoning transparent and gives them a natural place to add context or redirect your focus.

Reference: CaseBasix — Issue tree guide

5 Whys

What it is: A root cause analysis technique developed as part of the Toyota Production System. You take a problem statement and ask "why?" five times in succession, with each answer forming the basis for the next question. The goal is to move past symptoms to underlying causes.

How it works: Start with the observable problem: "DAU dropped 12% this week." Ask why. "Because new user activation fell." Ask why again. "Because the onboarding email sequence stopped sending." Ask why. "Because an API credential expired." Ask why. "Because there was no alerting on credential expiry." Ask why. "Because we never set one up." Now you have a root cause — and a specific action to take.

When to use it: The 5 Whys is best for fast, tactical root cause analysis on a specific anomaly — a metric that suddenly moved, an alert that fired, a report that broke. It is less suited to complex, multifactorial problems (where an issue tree is better), but for single-cause failures it is remarkably efficient. Run it in a short meeting with the right people in the room rather than alone at a desk.

Reference: MindTools — 5 Whys

McKinsey 7-S framework

What it is: A model developed at McKinsey that maps an organization across seven elements: Strategy, Structure, Systems, Staff, Skills, Style, and Shared Values. All seven are interconnected, changing one affects the others.

How it works: The framework is used to diagnose why an organization is performing below expectations, or to assess readiness for a change. Each of the seven elements is evaluated for its current state and its alignment with the others. Misalignments are where performance problems hide.

When to use it: Use 7-S when your analytics work is diagnosing an organizational problem, not just a metric problem. For example, if you've been asked to understand why a new data strategy isn't taking hold, or why two teams that merged are underperforming, 7-S prevents you from looking only at systems and data when the real issue may be skills, structure, or shared values. It is especially relevant for senior analysts and analytics leaders who work at the intersection of data and organizational change.

Reference: McKinsey 7-S framework

Part 2: Deciding what to measure

Once the problem is framed, the next challenge is choosing what to measure. This is harder than it sounds. There are always more things you could track than you should track. The frameworks in this section help you cut to the metrics that actually matter.

North Star metric framework

What it is: The North Star Metric (NSM) is a single number that best captures the core value your product delivers to customers. The North Star framework, popularized by Amplitude and widely used in product-led companies, builds a complete system around it: the NSM at the top, 3–5 input metrics below it that teams can directly influence, and guardrails that prevent gaming.

How it works: Identify one metric that, if it moves up, you are confident the business is delivering more value to customers, and that will, over time, drive revenue and retention. Below it, identify the levers: what inputs drive the NSM? Each input should have a team owner and be measurable. Spotify's NSM is "time spent listening." Slack's is "messages sent per team." Facebook's is "daily active users."

When to use it: Use the North Star framework when a team or organization is suffering from metric sprawl: everyone is tracking different numbers and there's no shared definition of what winning looks like. It is also the right starting point when standing up a new analytics function or joining a new company: before building any dashboards, identify the North Star and its inputs. This grounds all subsequent work in what actually matters.

Avoid using it for one-off analyses. The North Star is a strategic alignment tool, not a diagnostic one.

Reference: Amplitude — North Star metric

HEART framework

What it is: Google's framework for measuring the quality of user experience. HEART stands for Happiness, Engagement, Adoption, Retention, and Task Success. For each dimension, teams define Goals, Signals, and Metrics, the GSM process, to turn abstract UX aspirations into trackable numbers.

How it works: Choose one or two HEART dimensions that matter most for your product or feature. For each, define the goal (what are you trying to achieve?), the signal (what user behavior indicates progress toward that goal?), and the metric (how do you measure that signal at scale?).

• Happiness: user satisfaction, NPS, perceived ease of use
• Engagement: frequency of use, sessions per week, content interactions
• Adoption: new users of a feature, upgrades, first-time actions
• Retention: return rate, renewal rate, churn
• Task Success: completion rate, time on task, error rate

When to use it: HEART is most useful when you are working on product analytics, UX research, or any analysis where the quality of the user experience is what you're trying to improve. It is particularly valuable when product and design teams struggle to agree on what to measure, HEART provides a shared vocabulary. It is also a strong framework for feature launches, where you need to evaluate success across multiple dimensions, not just a single conversion metric.

Reference: heartframework.com

AARRR (pirate metrics)

What it is: A funnel framework created by Dave McClure of 500 Startups in 2007. AARRR maps the full customer lifecycle into five stages: Acquisition, Activation, Retention, Referral, and Revenue. Originally designed for startups, it is now used broadly in product, growth, and marketing analytics.

How it works: For each of the five stages, identify the key metric your business should be tracking:

• Acquisition: how are users finding you? (organic search, paid ads, referrals)
• Activation: are new users having a meaningful first experience?
• Retention: are activated users coming back?
• Referral: are happy users telling others?
• Revenue: are you monetizing effectively?

The power of AARRR is that it makes leak points visible. If acquisition is high but activation is low, your onboarding is broken. If activation is strong but retention is weak, the product isn't delivering lasting value.

When to use it: Use AARRR when you need to understand the health of a customer lifecycle end-to-end, or when stakeholders are debating where to invest. It answers the question: "Which stage of the funnel is our biggest bottleneck?" It is especially useful in growth analytics, marketing analytics, and early-stage product analytics. For more mature products with complex user behaviors, the North Star framework and input metric trees tend to be more useful.

Reference: Amplitude — Pirate metrics

OKR framework

What it is: Objectives and Key Results — a goal-setting framework developed at Intel by Andy Grove and popularized globally by investor John Doerr, who introduced it to Google in 1999. An Objective is a qualitative, ambitious goal. Key Results are 2–5 specific, measurable outcomes that define what achieving that objective looks like.

How it works: At the company level, leadership sets 3–5 Objectives for the quarter or year. Each Objective has 2–5 Key Results with clear numerical targets. Teams cascade their own OKRs to align with company-level ones. Analytics teams typically own the measurement of Key Results, they are the ones who instrument, track, and report on whether KRs are being achieved.

When to use it: OKRs are the bridge between analytics work and strategic impact. Use the OKR framework when you need to connect your analysis to something leadership cares about, or when stakeholders are pushing back on why a piece of analysis matters. If you can point to the Key Result your work is measuring or influencing, the conversation changes. For analysts specifically, OKRs are also a useful prioritization filter: if a request doesn't connect to any active OKR, it probably shouldn't be at the top of your queue.

Reference: WhatMatters.com — OKRs explained

DIKW pyramid

What it is: A model that maps the hierarchy from Data to Information to Knowledge to Wisdom. Originally articulated by Russell Ackoff, it describes the journey from raw, unprocessed facts through progressively higher levels of meaning and applicability.

How it works: Data is raw facts with no context (a server log entry). Information is data organized to answer a question (daily active users this week). Knowledge is information understood in context (DAU is declining because of a specific onboarding change). Wisdom is knowledge applied to make a better decision (we should roll back the change and redesign the flow).

When to use it: DIKW is most useful as a communication tool. When non-technical stakeholders ask "why do we need an analytics team?" or "why can't we just look at the numbers ourselves?", DIKW explains what analysts actually add — they turn data into wisdom. It is also a useful self-check for analysts: ask yourself where on the pyramid your current deliverable sits. A report that stops at "information" leaves the hardest work to the reader. A good analyst pushes toward "knowledge" and, ideally, toward "wisdom."

Reference: Wikipedia — DIKW pyramid

Part 3: Prioritizing what to work on

Analytics teams are always overloaded. Requests come from every direction: product, marketing, finance, leadership, and they all feel urgent to the person asking. These frameworks give you a systematic, defensible way to decide what deserves your time.

RICE scoring

What it is: A prioritization framework developed by Sean McBride at Intercom. RICE stands for Reach, Impact, Confidence, and Effort. It produces a single numerical score for each initiative, making it possible to compare very different types of work on the same scale.

How it works: Score each initiative on four factors:

• Reach: how many people will this affect in a given time period? (measured in number of users, customers, or events per quarter)
• Impact: how much will it affect each person? (3 = massive, 2 = high, 1 = medium, 0.5 = low)
• Confidence: how confident are you in your estimates? (expressed as a percentage, e.g. 80% = 0.8)
• Effort: how much work does it require? (measured in person-months)

The formula: RICE score = (Reach × Impact × Confidence) ÷ Effort

Higher scores mean better return on time invested. Rank all initiatives from highest to lowest, then apply judgment on top.

When to use it: Use RICE when you have a backlog of competing requests and need a transparent, data-driven way to sequence them. It is particularly valuable when different stakeholders are each convinced their request is the priority — RICE gives you a neutral framework to have that conversation. Importantly, RICE scores should inform decisions, not make them. Dependencies, timing, and strategic context all belong in the final call, layered on top of the score.

Reference: Intercom — RICE framework

OEC (Overall Evaluation Criterion)

What it is: A framework developed by Microsoft's experimentation team for defining, before a test runs, what a successful experiment looks like. The OEC is a composite metric or set of metrics that captures the goals of an experiment in a single evaluation framework.

How it works: Before launching an A/B test, teams define the OEC: the primary metric the experiment is trying to move, a set of guardrail metrics that must not degrade, and the statistical thresholds required to call a result significant. This is done before seeing any data, preventing the common trap of testing many metrics and reporting whichever ones happened to move.

When to use it: Use OEC whenever you are running a controlled experiment. The discipline of defining the OEC forces alignment between analysts, product managers, and engineers on what they're trying to achieve — often revealing disagreements that are much better surfaced before the test than after. It is especially important for organizations that run many experiments simultaneously, where without pre-registration of metrics it is easy to cherry-pick results.

Reference: Analytics Toolkit — OEC

PDCA cycle

What it is: Plan-Do-Check-Act: a four-stage iterative cycle developed by quality management pioneer W. Edwards Deming, widely used in lean manufacturing and continuous improvement. In analytics, it maps directly to the hypothesis-test-learn loop.

How it works:

• Plan: define the hypothesis, the metric, and the method. What change are you testing, and what does success look like?
• Do: implement the change or run the analysis.
• Check: evaluate the results against your success criteria. Did the metric move as expected? Are there confounders?
• Act: based on the results, standardize the change (if it worked), abandon it (if it didn't), or redesign and loop again.

When to use it: PDCA is most useful as a team operating rhythm, a shared mental model for how analysts and product teams work through improvement cycles. It is particularly valuable in experimentation-heavy environments, where the risk is running many tests but not building cumulative learning. The "Act" step is often skipped under time pressure; PDCA makes it explicit that acting on results, even a decision to stop, is a required part of the process.

Reference: ASQ — PDCA cycle

Jobs-to-be-Done (JTBD)

What it is: A framework developed by Clayton Christensen that shifts the analytical lens from "what are users doing?" to "what are they trying to accomplish?" The core idea is that customers don't buy products: they hire them to do a job. Understanding the job clarifies what to measure and what to build.

How it works: Through qualitative research (interviews, observation), teams identify the "job" a user is trying to accomplish: the functional goal, the emotional motivation, and the social context. These jobs become the anchor for metric design. Instead of measuring "feature usage," you measure whether users are successfully completing their job.

When to use it: JTBD is particularly powerful when quantitative data gives you "what" but not "why." If your metrics show that users are churning after step 3 of onboarding, JTBD research tells you what job they were trying to do and why the product failed to help them do it. It is also valuable when teams are debating which features to build — JTBD grounds those conversations in user intent rather than feature requests. For analysts, JTBD is most useful as a complement to quantitative work, not a replacement for it.

Reference: Christensen Institute — Jobs-to-be-Done

How to choose: a quick guide

The frameworks above are most useful when matched to the right moment in your work. Here is a simple way to think about which one to reach for:

You have a vague problem and need to structure it: Start with an issue tree built on MECE logic. Use 5 Whys if the problem is a specific metric anomaly. Use McKinsey 7-S if the problem is organizational.

You need to decide what to measure: Start with the North Star metric to establish the single most important outcome. Use AARRR if you're analyzing a customer lifecycle. Use HEART if you're evaluating a product or feature from a UX perspective. Use OKRs to connect your metrics to company strategy.

You need to run or evaluate an experiment: Define the OEC before the test runs. Use PDCA to structure the full iteration cycle.

You need to explain the value of your analysis: Use the DIKW pyramid to frame your work as moving from data to wisdom — not just reporting numbers.

You have more work than time: Score everything with RICE, filter first by OKR alignment, then apply judgment on top.