Performance is almost never a product team’s top architectural concern. Most of the time it isn’t even in the top three. When a product manager defaults to “make it faster” as the answer to everything, what they’re really saying is that nobody on the team has done the work to figure out which architectural characteristics actually matter for the system being built.

Cars on many highways are often limited to ~100km/h. A car that does 200km/h is not twice as useful on that road. Imagine if that car had skipped airbags, climate control, and a quiet cabin to get there. The trade was made. Nobody named it.

That is what most “performance” asks look like inside product teams.

The framework product teams ignore

Mark Richards and Neal Ford’s Fundamentals of Software Architecture gave the industry a clean vocabulary for this in 2020 and the framework has aged well. Architectural characteristics, the “-ilities”, are the non-functional qualities a system has to satisfy to be considered successful. Performance is one of them. So are scalability, evolvability, observability, security, modularity, fault tolerance, maintainability, deployability, and testability.

Richards and Ford make two arguments that get forgotten almost the moment people put the book down. First, an architectural decision cannot be made without naming the characteristics the system has to support, ranked. Second, you can’t optimise for everything. Their phrasing of the goal is precise: not the best architecture, the least worst one.

That means picking the three or four characteristics that matter most for this system, and accepting that the others get worse. The architect’s job is to surface the trade and document it. The product team’s job is to weigh in on the ranking, because the ranking flows from business priorities, not engineering taste.

“Make it faster” skips all of that.

What product teams are usually missing

A 2026 NFR checklist published in May by Forasoft put a number on the gap. Non-functional requirements account for 30 to 60% of total project work but receive about 5% of the brief. Retrofitting compliance characteristics into a system that wasn’t designed for them costs roughly three times what designing them in would have. Accessibility added late takes 6 to 10 weeks and $25-60k for a mature product. Designed in from day one, it’s closer to two weeks.

Those are characteristics nobody asked about because the brief didn’t have a slot for them. Performance was in the brief. Security, accessibility, observability, and evolvability mostly weren’t.

The shape of the problem is consistent. The product team asks for the characteristic they can feel from the outside (speed) and ignores the ones that determine whether the team can ship the next ten features without rewriting the system (modularity, evolvability, deployability), whether the team can debug production at 3am (observability), and whether the system survives the next regulator’s email (security, compliance).

When “make it faster” is actually a UX problem

The other half of the laziness is that most user-perceived slowness is not a raw throughput problem. It’s a UX, caching, or observability problem.

The 2025 Web Almanac performance chapter (published January 2026, last updated May 2026) shows what actually causes Core Web Vitals failures. 77% of mobile pages now get a good Interaction to Next Paint score. The failures concentrate around fixable UX patterns: 62% of mobile pages don’t set dimensions on at least one image, 87% use web fonts but only 15–16% preload them, and 40% of mobile pages run non-composited animations. None of those are throughput problems. All of them are felt as “the site is slow.”

Skeleton screens cut perceived load time by 20 to 30% compared to spinners without making the system one millisecond faster. Optimistic UI updates make a save feel instant when the server round-trip hasn’t happened yet. A 200ms API call with a loading spinner feels slower than a 600ms one with optimistic feedback and a skeleton.

When product asks for “faster”, what they often mean is “the experience feels janky.” The fix is rarely throughput. The fix is a designer and a front-end engineer working on perception. The engineering team that goes straight to caching layers and database indexes when the real fix was a skeleton screen has wasted a sprint and added complexity to maintain forever.

The diagnostic that actually works

The right response to “make it faster” is one question: faster at what, measured how, for whom, and at what cost to the other characteristics?

Faster checkout latency under load is a scalability problem. Faster initial render is a UX and asset-loading problem. Faster recovery from a deploy gone wrong is an observability and deployability problem. Faster onboarding for new engineers is a maintainability and modularity problem. Different jobs. Different fixes. Lump them under “performance” and the team chases the wrong one.

Lauren M.’s March 2026 piece on shipping performance work without premature optimisation gives the rule that should be table stakes: profiling evidence before optimisation PRs. If the trace can’t explain the change, the change doesn’t ship. The corollary is that the product team should be able to state the metric, the target, and the user impact in plain language before engineering touches anything. If they can’t, they don’t have an optimisation request. They have a vibe.

What to do this week

Three moves if your team defaults to “make it faster”.

Run the characteristics conversation. List the ten “-ilities” that matter for your system. Force the product team to pick the top three. Watch what they argue about — that’s the conversation you’ve been missing. The system you actually need will not have performance at number one. It will have evolvability, observability, or modularity at number one and performance somewhere in the middle.

Separate the perception ask from the throughput ask. Every “it feels slow” complaint gets a UX investigation and a backend investigation, not just a backend one. The UX fix is usually cheaper, faster to ship, and doesn’t cost you another architectural characteristic to deliver.

Make trade-offs explicit in the brief. If a feature requires sacrificing observability for raw speed, write it down. If a system needs to be evolvable and that means it’s not the fastest, write that down too. Architectural characteristics that don’t survive into the product brief don’t survive into the product.

The teams that ship sustainable systems don’t have a performance obsession. They have a characteristics conversation. The teams that ask “make it faster” as the universal ask are usually the same teams asking “why does every release break something different” six months later.

If your team can’t name the top three architectural characteristics for the system it’s building, talk to us.

Sources