Don't Optimize What You Haven't Built Yet

A system has to exist before real optimization can begin.

Planning matters. Strategy matters. But if you keep improving an untested plan before anything is operating in the real world, optimization can quietly turn into procrastination.

That's closely connected to Progress Beats Perfection Every Time. There's a point where more polishing produces less value than putting something useful into the world and learning from what actually happens.

The answer is usually to start smaller. How Small Systems Create Big Results explains why large goals don't require a giant operating system on day one. Build a small piece that performs the core job, make it work, then add the next piece.

This is also how my systems have evolved over time. In What I Learned From Building Systems for My Life, I explain that useful systems get tested, refined, simplified, and expanded through experience. They don't arrive fully mature.

And eventually you have to move before every question has been answered. Stop Waiting Until You Feel Ready makes the same point from another angle: action creates the feedback that helps you decide what actually deserves improvement.

The question for this lesson is: Am I improving a real system, or polishing something that has not proven it works?

In This Lesson

·        Why optimizing too early can become a form of procrastination

·        How big complicated systems usually grow from smaller systems

·        Why complexity makes it harder to focus on the next useful step

·        The correct order: plan, build, test, observe, then optimize

·        Why real-world feedback tells you which parts actually matter

·        How to build the simplest version that performs the core job

·        Why small systems can stack into a much larger result

·        How mature systems reveal real bottlenecks and friction

·        Why evidence is more useful than imagined problems when deciding what to improve

Watch the video or read the complete transcript below.

Don't Optimize What You Haven't Built Yet

(Transcript edited for clarity.)

Hi, I'm Wes. Welcome to Don't Optimize What You Haven't Built Yet.

And this is really going to be a discussion about putting things in the right order.

And I've fell into this trap many times. One of the big reasons I fall into this trap is I really like to learn. I like to research.

I like to plan. I like the strategy. And I'm usually talking about business here, but it can also be about success in your life or creating systems for success in your life.

So it can work anywhere, but usually I'm thinking about this in some way about making money or business, entrepreneurial life.

But with Don't Optimize What You Haven't Built Yet, the trap I fall into is I want to create the plan. And I want the strategy to be perfect.

And I just want to get it all great and then attack it.

But it reaches a point where if I haven't built it yet or started taking action yet, then optimizing reaches a point where it's just procrastination.

If you keep optimizing before you've actually started or before you've actually built something, then you're not getting any closer to what you're trying to reach.

Another way to say this is build before you optimize.

And here's the question for you to think about through this episode: Am I improving a real system or polishing something that is not proven it works?

That's a good question.

When you design a system for whatever it is, when you design a system, you want to design the best system you can. You want to give it the best chance to work. We all do.

We're talking about success here, right? That's what I talk about all the time. We're trying to succeed somewhere in our life. We're trying to make some area of our life better.

So we're trying to create systems that help us make things better, that reach the success we want.

That's the whole thing about Your Life Systems, is finding, developing, creating systems and workflows to become more successful.

So the question again: Am I improving a real system, which means do I already have a system in place, or am I polishing something that is not proven it works?

So systems so often appear to be complicated.

We think about, I want to achieve this huge goal. So our mind tells us, well, since it's such a big goal, it's going to have to have a big complicated system.

And while that might be true, the fact is most big complicated systems start with very small systems, and then you add on to them, and you expand them, and you make them better.

And they become big complicated systems over time. They don't usually start that way.

Because here's what happens. Let's say, and I know a lot about building systems, and I've got a lot of experience with it.

Even someone that has as much experience as me, if you create a system that's too complex before you put it into practice, it becomes harder to get started.

And it becomes more daunting or overwhelming as you're trying to get started, because instead of focusing on the next small step or the next several small steps, your attention keeps getting pulled to the big thing, the big system, the big goal.

It's good to think about your big goals, but also if your system is too big and complex, it's hard to not focus on, oh, I've got to do this huge thing, and this huge thing needs to get done.

And it pulls your focus away from the things, creating the small things that are going to work, that once you can make them work, they're going to bring you closer to the bigger things automatically.

So again, am I improving a real system, one that already is in play, even if it's a small one, or polishing something that is not proven it works?

Don't try to fix your systems before you test your systems, whatever systems they are.

And if you're struggling with a big system, start breaking it down into smaller systems, and then master a small system, then master another small system, with all these small systems or steps bringing you closer to whatever your big goal is.

Optimization only matters after something exists and produces a result you can observe.

Now I said at the beginning of this, this is really about putting things in the correct order.

So I said optimization only matters after something exists and produces results you can observe.

So the correct order is not optimize first.

The correct order is to do the best you can. Put the best plan in place possible, then start taking action, small steps, small systems within that plan.

And then you have something that exists. Then you can start testing. You start getting feedback, and that helps you by producing results that you can see.

You observe the results, and then you can use those results to evaluate, and adjust, and adapt.

Premature optimization adds complexity before you know which parts matter.

You don't want to overcomplicate things when you're looking for success or building systems.

You can get more complicated later. Don't try to overcomplicate at the beginning or over-optimize at the beginning.

First of all, you usually don't know what needs to be optimized.

And if you don't know what needs to be optimized, that's what you need to figure out first.

How do you do that? You break it down. Small, small steps. Small system.

You take action, you get feedback from that, you observe what you learned, you learn which parts matter, and then you have something concrete to work on optimizing.

That goes back to get it in the right order.

Do the best plan you can, start taking action, get feedback, then you start optimizing.

Then you can optimize each step along the way and make each step as good as you can with real feedback, real-world feedback.

Build the simplest version that can perform the core job.

Whatever you want to accomplish, I talk about it all the time, break it down into small steps or small systems possible.

Then create or build the simplest form, or simplest system, to get that done or to bring you closer to that.

And then do that.

Get the feedback and optimize it if you need to.

Usually, if you've done a good job of breaking it down small enough and started with a small enough system or a small enough step, you're not going to have to optimize that much.

Every once in a while maybe, but it's probably going to work.

Then you start adding the next thing on. It's like building blocks.

You build one system onto the other, or one step onto the other, and you see all I'm doing are these small steps.

But if you stack enough of those small steps or small systems, this small bit starts stacking up, and it gets huge.

And all of a sudden you realize you're at your goal, at your big goal, or you're halfway to the big goal with just doing these small steps.

And that's when you start seeing things that you can quickly optimize after taking action, after building.

Then you can start optimizing from facts, from real-world feedback that you've got, that you have received, and that gets you closer and closer as you move along.

Now, run it long enough to find the real bottlenecks and friction points.

When you start stacking these small systems or small steps, things can be going great for a while, and you're stacking up the little ones, and it's growing bigger and bigger.

Then you can start seeing where there's friction or where the bottleneck is.

We often talk about bottlenecks in business problems.

When something's not working well from a mature system, or a system you've been using quite a while, you start looking for bottlenecks.

What's the bottleneck here?

And a bottleneck simply means it's slowing things down, or it's keeping you from reaching the full potential in the business, things like that.

And often, if you can identify the bottlenecks, then you can start creating small systems or steps around those bottlenecks to remove the bottleneck.

Think of, you're trying to get all this water into a bucket, and you've got a funnel. And the funnel has a small, small hole in it.

So only so much can go through at one time.

If you make that hole bigger, more gets through at one time. Or if you completely remove it, then a lot more gets through at one time.

That's simply what a bottleneck means.

Usually, again, I think about this in terms of business.

Often, if you can identify the bottleneck, then you can optimize around that bottleneck, hopefully remove the thing completely.

But even if you can't remove the bottleneck, maybe you can create systems or build solutions that widen the bottleneck so that more can get through.

So you can increase profitability or sales or whatever you're working on.

Improve based on evidence instead of imagined problems.

Now again, this is an order. Remember, I said don't optimize what you haven't built yet.

So when you improve based on evidence, you're improving based on facts or real-world feedback, right? Not an imagined problem.

It's good to foresee possible problems and have plans for them.

But so often, when we imagine a problem, it doesn't become a problem. There's something else that replaces it or takes care of it that we didn't understand or we didn't see.

Now again, this is a fine line.

You do need to foresee possible problems, bottlenecks, things like that, and try to deal with them beforehand if you can.

But you don't want to invest so much time and energy in an imagined problem or a potential future problem that it takes you away from making the steps you need to get to whatever your goal is.

Get the system working first, and then improve it later or make it elegant later.

Without the system in action, you're not optimizing with the most information you can get.

When you take action, when you put the system in, when you build it first, start taking action.

Then you start getting real-world feedback, and that gives you the most information you can have when you're ready to start optimizing.

So again, the main point today and this episode is make sure you're doing things in the right order.

And that's why build before you optimize.

Make sure you have the right thing in place to start optimizing, and make sure you're getting the right amount of data, real-world feedback back.

So when you start optimizing it, you can do it with the best facts that you have available.

Then optimize it, test again, keep working on the system, get more feedback.

This is Wes, Your Life Systems. Please subscribe. Hope this helps.

What's Next?

·        Choose one system, business idea, or project you're still polishing before testing.

·        Define the simplest version that can perform the core job.

·        Build or run that version before adding more complexity.

·        Collect real feedback from what actually happens.

·        Identify the first genuine bottleneck or friction point.

·        Optimize that specific problem, then test again before changing something else.

If you found this helpful: