Make it, learn from it

Earlier this week, a client sent me this message:

“Can we update how this option is labeled? Some customers pick the wrong one because they think the current label only applies to a specific trim level.”

Simple enough request. Change a label, close the ticket.

But before I touched anything, I took a few minutes to look at why customers were confused.

Turns out the upstream supplier had quietly changed how they organized their product catalog. They merged several distinct categories into a much smaller number. The label my client noticed was just the most visible symptom. There were likely others.

So instead of making one label change and moving on, I spent a bit of time checking whether the same consolidation had happened across the rest of the catalog. It had. In several places.

That extra twenty minutes of looking around before acting saved us from one round of follow-up fixes after another that would have shown up one confused customer at a time.

That’s a long way of saying: requests that land in your inbox rarely show the entire picture.

If you own the business systems for your company, you already know this. It can feel you’re constantly reacting to problems you didn’t create, with not nearly enough information and not nearly enough time.

You’re asked to make decisions and changes in an environment where you cannot possibly know everything up front.

The question is not, “Which framework should I use?” It’s: How do we work when we won’t have the full picture at the start?

A better name for what you already do

A lot of the noise around methods and frameworks assumes you can choose the “right” process and then everything will be fine.

In reality, you’re doing something far more interesting:

You’re uncovering how things actually work by changing the system and watching what happens.

There’s a pattern to that:

You accept that you don’t know every workflow, edge case, or downstream impact on day one.
You look for ways to learn quickly instead of pretending you have all the answers.
You aim for a real outcome (fewer errors, smoother onboarding), not just “ticket closed.”

That way of working that I call make it, learn from it.

When you work this way, you quietly ask yourself a handful of questions every time someone asks for a change:

Do we understand the outcome we’re trying to deliver?
What will be different for the business if we do this? How will we know this worked?
In the label example, the real outcome wasn’t an updated label. It was customers choose the right option without confusion.
Will this request actually move us toward that outcome?
Does this new field/report/automation help reduce errors, speed things up, or make work easier?

What do we not know yet?
Whose workflow does this touch that we haven’t talked to? Where might this create new problems downstream? What are the unintended consequences?
This is the question that turned a label fix into a full catalog review. One change in how a supplier organized their data rippled into multiple places; none of which were visible from the original request.
What is the smallest change we can make to learn?
Can we try this with one team first? What can we change to see if behavior changes before we commit to a big redesign?

You don’t need to show these questions to anyone and you don’t need a workshop.

Use them as a quiet filter in your own head.

Over time, that set of questions changes how you respond to “quick” requests, implement changes, and helps you decide when to say “yes” and when to say “not now.”

Why this matters if you own the systems

Most growing businesses get trapped in a loop.

From the outside, it looks like progress—new tools, new modules, more integration.

From the inside, people still work around the system instead of with it.

If I had just changed the label and moved on, that’s exactly what would have happened. A few weeks later, a different label would have surfaced the same confusion. Then another. Each one looking like a new problem, each one actually the same upstream change nobody had fully mapped.

If you’re the person who owns those systems, you’re in the best position to break that loop—not by adding more processes, but by changing how you think about the work.

When you default to make it, learn from it, a few things shift:

Your stakeholders stop measuring you by tickets closed and start noticing when problems actually go away.
Project conversations move from “when will it be done?” to “what will be different when it is?”
You have a better story to tell when you need to say “not now” to a request.

You’re still configuring tools, designing workflows, and handling requests.

But you’re doing it in a way that acknowledges reality. You’ll never know every downstream impact on day one, so you might as well get good at learning as you go.

A small move to try this week

Pick one request from your queue, ideally something more involved than “change this label.”

Before you touch anything, answer these two questions:

What outcome are we actually trying to create with this change?

Not add field X or update this label. Something that leads to a meaningful impact for your organization, such as “reduce manual rework on invoices, cut down on missed follow-ups, or make onboarding faster for new reps.

What don’t we know yet that could make this change land wrong?

Is there an upstream system, supplier, or integration that might have changed? Whose workflow does this touch that you haven’t talked to yet? That second question is the one that turns a label fix into a real improvement and saves you from cleaning up the same problem three times in a row.

Use that as your plan.

You don’t have to make a big show of it.

You don’t have to convince anyone of a new philosophy.

Just make one deliberate shift: make it, learn from it.