Why most teams under-test load
A realistic load profile (ramp shapes, think times, user mix, burst behavior) takes an experienced performance engineer hours to write. Most teams don't have that engineer on tap, so they run a flat ramp that resembles no real traffic, pass it, and call the launch de-risked. The first realistic load their system meets is production's.
From intent to configuration
Intent-Based Load Testing starts from the sentence you would say in the planning meeting: "test checkout with Black Friday traffic: a sharp evening spike on top of steady daytime load." The engine translates that intent into a concrete configuration (ramp profile, concurrency levels, duration, and behavior mix), which you review and edit before anything runs.
The generated config is a starting point that encodes load-testing practice, not a black box: you see every parameter, adjust it, and keep it. And like the rest of our performance engine, results come back with P50/P95/P99 and Apdex, with export paths if you outgrow the UI.
The manager's math
The cost of an unrealistic load test is invisible until launch day, and then it is very visible. If describing your feared traffic in one sentence produces a reviewable test in minutes, the excuse for not load-testing before the next launch is gone.