A client says, "make it faster." The developers nod, get to work — and two weeks later ship something that's technically "faster," but not what the business actually meant. Nobody lied. It's just that "faster" isn't a task, it's a feeling, and anyone handed that feeling without specifics fills in the rest themselves.
"Faster" means at least four different things
When a business says "faster," the dev team hears one of at least four different requests, and each one leads to completely different work:The page loads faster for the user (frontend performance, time to interactive).The backend processes a request faster (query optimization, caching, indexes).New features ship faster (deployment frequency, CI/CD).The team responds to bugs or requests faster (process, not code).A developer handed an abstract "faster" picks one of these directions at random — often the one that's easiest to demonstrate as "done," not the one that actually hurts the business the most.
Without a number, "faster" can't be done or verified
"Make it faster" has no completion criterion. How much is enough? 10%? Twice as fast? Without a threshold, the team doesn't know when to stop, and the client doesn't know whether they got what they paid for. Both sides end up relying on a subjective feeling — and that feeling is always better after an optimization than before, regardless of how much the numbers actually changed.Compare that to: "The cart page must load in under 2 seconds at p95 for 95% of users on 4G." That's a requirement you can implement, measure, and close.
Optimization without a target usually hits the wrong thing
The classic scenario: a team gets "make it faster," looks at the system, and spots a few obvious improvement points — a heavy SQL query, an unoptimized bundle, a slow third-party API. They optimize whatever is technically easiest to fix, not what the user actually feels. The product gets faster in the profiler and stays exactly as slow for the client, because the real bottleneck was somewhere else entirely.
What to ask instead of "make it faster"
Three questions turn a vague request into an executable one:Which specific user scenario is slow — not the system in general?How slow is it right now, and what number counts as "fast enough"?Which matters more — response speed right now, or stability under load later?The answers to those three questions are the actual spec. Anything a team gets without them is a guess that will need redoing once it turns out "faster" meant something else.
Speed is always a trade-off, never a free gift
One last point that often gets lost: making something faster is rarely free. Caching adds invalidation complexity. Precomputing eats memory. Parallelizing makes debugging harder. A good dev team doesn't just execute "make it faster" — it shows exactly what a specific speed gain will cost, and lets the business decide whether that trade-off is worth it."Make it faster" sounds like a task, but it's really a feeling the team has to decode on your behalf. The best results go to whoever replaces the adjective with a specific scenario, a threshold, and a definition of done — before anyone starts writing code.