The Experiment Layer

Every planning framework you've ever used gives you two things: a goal and a way to measure whether you hit it. OKRs give you Objectives and Key Results. SMART goals pack the goal and the measure into one tightly worded statement. EOS gives you Rocks and a Scorecard. The goal is on the left. The measure is on the right. The gap between the two is on you.

That gap is where plans die. Not because the goal was wrong, and not because the measure was unclear. They die because nobody defined the path between the two. The team walks out of the offsite with a clear destination and a clear scorecard, and then spends the next twelve weeks inventing the route as they go. Some of what they try works. Some doesn't. Nobody tracks which is which, because the framework never asked them to.

GEMs fills that gap with experiments.

What an experiment is in GEMs

An experiment is a hypothesis-framed bet. It's not a task. It's not a project. It's a specific idea you believe might move you toward your goal, stated clearly enough that you can test it and learn from the result.

The format is simple: “We believe that doing X will produce Y.”

That sentence does something important. It puts the why in front of the what. “Hire two enterprise sales reps” is a task. “We believe that adding dedicated enterprise sales capacity will convert the pipeline we're building” is a hypothesis. The first one gives you a to-do. The second one gives you something to test.

This framing matters more than it looks like it should. When you frame an initiative as a hypothesis, three things change.

First, the team starts thinking about why, not just what. Before you commit resources to an experiment, you have to articulate what you believe will happen. That forces a conversation about assumptions that most planning frameworks skip entirely.

Second, outcomes become learning, not just results. When the experiment runs, you're asking a clear question: did the hypothesis hold up? The answer is always one of three things. The hypothesis held: what you tried worked the way you expected. The hypothesis did not hold: what you tried didn't produce the result you expected. Or the result was inconclusive: you don't have enough signal yet to know. All three are useful. None of them are failures.

Third, the team gets permission to stop. If you've committed to a project, stopping feels like failure. If you've committed to testing a hypothesis, stopping when the hypothesis doesn't hold is just good science. This is the subtle but powerful shift that makes experiment-driven planning feel different from task-driven planning. You stop carrying dead weight.

How experiments connect goals to measures

In GEMs, the flow is always Goal → Experiments → Measures. The arrows matter. You start with the goal: a directional, outcome-oriented statement of the future you want to create. Then you brainstorm the experiments: the ideas you believe might move you toward that goal. Only then do you define the measures: the recurring indicators that tell you whether the experiments are working.

This sequence is deliberate. Most frameworks ask you to define the goal and the measure at the same time, which turns goal-setting into a measurement exercise. You spend the offsite arguing about what's measurable instead of dreaming about what's possible. GEMs separates the two so you can think about the goal without the constraint of the measure, and then think about the measure without the distraction of the goal.

The experiments live between them. They are the implementation layer. They are the answer to the question every team asks after the offsite and nobody says out loud: “but what do we actually do on Monday?”

How experiments cascade

In a leadership team, the company sets one or more goals. That goal doesn't get rewritten as it moves through the organization. What cascades are the experiments.

The company-level strategic experiments become team-level goals. Each team asks: given this strategic experiment, what can we try that would move it forward? Those team-level experiments are specific to what that team knows how to do and what they have the capacity to test. An engineering team runs different experiments than a sales team, even when both are working toward the same company goal.

This is how alignment works in GEMs. Not by cascading and rewriting goals at every level until nobody can trace them back to the original intent. By keeping the goal whole and letting the experiments do the branching.

For a deeper look at how GEMs compares to OKRs, SMART goals, and EOS Rocks, see GEMs and What You Already Use → . For how the experiments connect to the full planning rhythm, see The Planning Rhythm →.