Experimental Goals

I have a complicated relationship with goals. I understand their benefits, and often use them extensively, but I also struggle with such rigid constraints. It prevents opportunities for serendipity and curiosity to carve new paths. It’s harder to explore when you’re executing on a predetermined plan. This is most noticeable with the current incarnation of goals and how we format them. From OKRs to S.M.A.R.T. goals, these formats create rigid (and sometimes arbitrary) constraints on the work. We figure that, if we can just plan out every detail in advance, it will all go swimmingly. But this is The Planning Fallacy in action.

Software development is a prime example because all software development is guesswork until you do the work. You think you know the work, but you don’t. Estimates are a mirage, a false sense of confidence masking uncertainty. But uncertainty is always there, lurking in the unknowns you can’t yet see. The only way to win is to avoid pre-planning and focus on shaping the work at the right level of fidelity. Create guardrails, but lean into the unknowns, prepare for them, and address them as they come.

In software development, the goal is completing a body of work, which is usually a feature in a product. If you’re doing it correctly, you map out the outcomes, de-risk what you can, and then let the team uncover the path through the work. If this is the lesson software development teaches, why don’t we take this approach when we set goals in general? What’s different?

There’s a tension between setting goals and learning from experimentation. If you set a goal that is detailed and rigidly defined, it makes it hard to experiment, adapt, and learn. Work expands to fill the space of our expectations, so we have to forcibly constrain the work, constantly chipping away at the scope.

The goal is meant to guide, not restrict. It sets a course, but shouldn’t detail the path. But too often we fall victim to The Goal Trap, which I define as staying committed to the wrong path instead of readjusting in a new direction. Sometimes we need to change the goal, and sometimes we need to change the path we take to get to the goal. Either way, we’re fighting a losing battle to force such rigidity.

Some of the greatest achievements in history were met not by a strict adherence to a predetermined objective, but by a continual adaptation of iterative learning fueled by a goal.

This brings us to the question I want to explore:

How can you achieve time-based goals through experimentation and curiosity?

My Current Approach

I like to draw a clear line between the high-level goals I’m working towards and the individual daily tasks I work on. To accomplish this, I break down goals into five components:

1. Quarterly goals for key areas.
2. Monthly projects for each quarterly goal.
3. Clear outcomes for each monthly project.
4. Weekly targets tied to each outcome.
5. Daily tasks tied to each weekly target.

This structure allows me to break down something big (the goal) into something small (the task). It draws a clear line between what I’m doing today, and what I’m trying to accomplish over the next 90 days. Priorities are clear.

But this requires each part higher up the chain to be accurate. Sometimes an outcome can change and the entire chain needs to be rewritten or restructured. This is not only fragile, it’s not based in the reality of work.

So how can we take the benefits of this structure and blend it with experimentation?

Before we get there, we need to examine some of history’s greatest achievements.

The Wright Brothers

The Wright brothers objective was to create a controlled, powered flying machine. The goal was clear, but the path to get there was not. It required iterative experimentation rather than a rigid plan. I can’t imagine the brothers sitting down to detail monthly projects, weekly targets, and daily tasks. Experimentation was their compass to their destination: a flying machine.

The Wrights weren’t happy with the existing data on lift and drag—key elements of flight—so they built their own wind tunnel in 1901. They tested up to 200 wing designs so they could gather accurate data and refine their designs.

For the next few years, they developed and tested three full-scale gliders. These were experiments that helped them master flight control and maneuverability. And shortly after in December of 1903, they incorporated data from the wind tunnel tests and glider iterations to achieve powered flight.

If you asked the Wright brothers what exact steps they would take to do this, they wouldn’t have known. The experiments created the path. They still had a clear goal, but the steps revealed themselves through the process.

Thomas Edison

Thomas Edison’s goal was to create an affordable, durable, and efficient electric light bulb that could be used domestically and integrated into an electrical distribution system.

The goal is clear, and it even includes specific outcomes tied to the work:

• Affordable
• Durable
• Efficient
• Domestic Use
• System Integration

But Thomas Edison didn’t start by writing out all of the steps. He didn’t know! He had to lean into experimentation as the compass to the goal. He used trial and error rather than theoretical calculations. He famously said:

I haven’t failed—I’ve just found 10,000 ways that won’t work.

The iterative process allowed him to refine the designs based on practical results rather than rigid planning. Experiment, learn, iterate.

Pixar

Fast-forward a little over a century and we see a similar pattern with Pixar, the well-known animation studio that is now part of Disney. Pixar’s overarching goal is to produce emotionally engaging, visually stunning films. In order to achieve this, it requires continual iteration, constant refinement, and adapting to new innovations in technology.

Pixar creates over 4,000 storyboard drawings per film. They review each storyboard, revise it, and incorporate revisions into the next one. They use proprietary software and rigging to add control points for movement, allowing animators to experiment with realistic motion. And they experiment with new tools, which continue to evolve and change their process.

Through this approach, they’ve created groundbreaking films and changed how animation and storytelling are done across the industry. They set a new standard. But it didn’t start with rigid steps—just iteration.

The Time Constraint

But what about time? While Pixar is working against deadlines for films, the Wright brothers and Thomas Edison surely felt less time pressure—certainly not like we do in the working world of the 21st century. Yes, but software development is obsessed with time. “How long do you think that will take?” is the most frequently asked question I’ve heard in my career. And I’m sure this isn’t the only domain where that’s true.

The secret to delivering software on time is to fix the scope (the work), but vary the time. You complete the work in the given time constraint, but the solution that comes out the other end may be different than you expected. It still solves the core problem, but with trade-offs.

You can’t deliver any work on time without trade-offs. And trade-offs can’t be made without clear decisions. And clear decisions—good decisions, I’ll say—can’t be made without experimentation, iteration, and refinement. If you can’t build something because there’s more work than you have time for, the path forward is to try something—ideally, lots of somethings. This is what prototypes, demos, and fast replications of solutions are for. This is why the Wright brothers built their own wind tunnel, and why Pixar uses proprietary software and rigging to experiment with motion. Speed of iteration is the key to quality. The faster you iterate, the faster you find the path forward.

Room for Innovation

When you stick to rigid plans and fixed timelines, you limit your ability to innovate. Without fail, the more openness I leave in the solutions for software projects, the more creativity, ingenuity, and elegance in the solution. The rougher the sketch, the better the result. While constraints breed creativity, rigidity restricts innovation.

This is like those cooking shows where the chefs get a limited and unlikely pairing of ingredients, and then have a short amount of time to prepare a dish. They’re operating within fixed constraints (ingredients and time), but without rigidity. They can cook the ingredients however they want, combine them in novel ways, and iteratively experiment with their existing knowledge base to create something inventive.

Stephen King doesn’t create an outline, a plot, or even a theme before writing. He creates a situation, puts his characters in it, and lets the story unfold as they navigate through it, word by word. The situation is the constraint, but there’s no rigidity to limit the story. If there were, he wouldn’t have such a prolific career, replete with new and intriguing stories. Hell, he wouldn’t be able to write novels—the very definition of something new.

The giant caveat here is the requirement of craft. You can’t operate fluidly within creative constraints without a strong command of your craft. When I get elegant solutions to complex problems—prompted by a simple and rough sketch—it only works when the work is completed by someone who cares about the craft. They engage critical thinking and continual iteration to reach the best possible outcome within the given constraints. This is what the Wright Brothers, Thomas Edison, Pixar, great chefs, and Stephen King share: craft.

A New Way

Returning to the question I set out to answer:

How can you achieve time-based goals through experimentation and curiosity?

Answering a question with a question: What if you set a goal with the right constraints, but remove the rigidity common in modern goal-setting practices?

This would apply appropriate constraints to stimulate creative solutions, operate within the practical constraint of time, and give space for exploration, experimentation, and iteration.

Sounds perfect, right?

Let’s revisit the original goal structure I use today, and see if we can keep the good parts (constraints) while removing the not-so-good parts (rigidity).

Goals

The top-level unit is still the goal. But instead of defining it with a rigid path, what if we posed a question instead? A great question is the perfect framing device for goals. Our goal is still clear, but reframing it as a question encourages different thinking. It creates room for exploration.

I’ll give you an example. I’m working on renewing a contract for a project. I’ve done this many times before. I know the playbook, and it would be easy to list out the steps ahead of time. But I’d also lose out on new and better solutions—that room for innovation—with such rigid steps.

So instead of stating the objective of renewing the contract as the goal, we ask a question:

What is the most effective way to secure renewal?

This may seem small, but the question invites, whereas the objective dictates.

Now we’re thinking. That’s good.

Projects

The next layer down from the goal is a project. But instead of another rigidly defined unit of work, we test out a hypothesis. What can we falsify and verify against our question representing the goal for renewal?

The stakeholders on the project want to see their spend go down in the next contract, which could come from product revenue or other sources. Again, this is where creative thinking and exploration is helpful.

And now our hypothesis is born:

If we present a sales model that demonstrates how we can generate revenue from paying customers and reduce monthly costs over the 12-month renewal period, they will be more likely to commit to renewal.

This is the first part of the project. The next part is the appetite, which is the amount of time we want to spend validating the hypothesis.

We’re going to give this two weeks to work on a solution, present it to the client, and validate whether this approach works. If it does, then we move forward. If not, we learn and readjust.

It’s all learning.

And this is just the first hypothesis. Test as many as is required to answer the larger question within the time constraint (appetite).

Outcomes

The outcomes define the success criteria for testing the hypothesis. They should also be questions to guide learning.

In this case:

• Do they see revenue generation as a compelling reason to renew?
• Does showing a cost-reduction model change perception of the value?
• What objections or questions arise from stakeholders?

Converting outcomes from rigid checkboxes to fluid questions influences a new way of making progress. It’s about learning, not falling into The Goal Trap to mindlessly appease a spreadsheet.

Targets

In order to answer those questions and, ultimately, validate our hypothesis, we need to run tests. That’s where the targets come in. These are small tests you can run within a week to help answer the questions posed by the outcomes.

If we want to answer Do they see revenue generation as a compelling reason to renew?, then we need to design a simple experiment to test.

For example: Create a simple revenue model in a spreadsheet showing potential customer revenue over 12 months. Talk to the customer, get feedback, and iterate.

Tasks

Tasks are the smallest unit of work. These are the daily outputs that help you climb the ladder from tasks to targets to outcomes to projects to goals. When you structure it this way, there’s a clear path from what you work on at the task level, and the larger goal you’re working towards.

The model still fits, but now it’s driven through experimentation, not rigidity. And your tasks can be tactical, practical, and clear. The experimentation in higher layers drives execution here.

Experimental Direction

Experimentation, guided by a clear goal, leads to outsized results. When you know where you’re headed, but leave yourself open to new possibilities, serendipitous discoveries guide innovation. And when you’re innovating, you’re thriving—you find novel solutions to complex problems, feel more engaged in your work, and unlock opportunities you could have missed.

Let’s look back at the question this all started with:

How can you achieve time-based goals through experimentation and curiosity?

Start with the goal, but pose it as a question. What are you trying to answer? Let that guide you as you state a hypothesis, define your learning criteria, and then test it. Each step is a learning, whether it’s valid or invalid—it keeps you moving forward. In this mode, you’re keeping structure without the rigidity; you’re staying focused through adaptability; you’re growing and evolving, one experiment at a time. The Wright Brothers, Thomas Edison, Pixar, and countless others have worked this way to achieve big things, and so can you. The only way to learn is by doing.