What does it mean that find the bottleneck before optimizing?

Improving anything other than the bottleneck does not improve the system.

Example: You have been frustrated with your personal productivity for months. You spend a weekend reorganizing your note-taking system — migrating apps, redesigning your folder structure, importing templates, watching tutorials on advanced features. The new system is beautiful. You feel the rush of progress. Monday morning arrives and nothing changes. Your weekly output is the same. Your projects move at the same pace. The backlog does not shrink. Three weeks later, you run a simple diagnostic: you track where every hour goes for five consecutive workdays. The data reveals that you spend eleven hours per week in meetings that produce no decisions, no actions, and no information you could not have received in a five-minute summary. Your bottleneck was never your note-taking system. It was the eleven hours of your week consumed by meetings that serve no purpose — hours that could have been focused work, synthesis, or execution. You optimized the wrong thing. The system did not care.

Try this: Choose a system you operate that feels stuck — one where effort has not produced proportional results. It could be a creative pipeline, a fitness routine, a learning practice, or a work process. Map it as a sequence of stages, then run a five-day diagnostic. For each stage, track two things: (1) actual time spent, and (2) queue size — how many items are waiting to enter that stage at any given moment. After five days, identify the stage with the longest duration or the largest queue. Write a one-paragraph diagnosis: What is the bottleneck? How do you know? What have you been optimizing instead? What would change if you redirected that optimization effort toward the actual constraint? Do not fix anything yet. The diagnosis is the deliverable.