Why PMs Should Understand Load Testing

Last quarter, one of our APIs went down during a client demo. The menu service for a national restaurant chain could not handle the load. I sat in that incident review and realized I did not understand performance testing well enough to have prevented it.

Enter k6

k6 is an open-source load testing tool built by Grafana Labs. You write test scripts in JavaScript, define virtual user scenarios, and run them against your endpoints. The output gives you response times, throughput, and error rates.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 100,
  duration: '30s',
};

export default function () {
  const res = http.get('https://api.example.com/menu');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

That script simulates 100 concurrent users hitting a menu endpoint for 30 seconds. Simple, readable, and incredibly informative.

Why PMs Need This

You do not need to write k6 scripts yourself. But you need to understand the conversation. When your engineering lead says "p95 latency is 800ms under 500 concurrent users," you should know whether that is acceptable for your use case. When the client's SLA says 99.9% uptime, you need to understand what load conditions threaten that number.

What Changed For Me

After learning k6 basics, I started asking better questions in architecture reviews. I now include performance acceptance criteria in our definition of done for API work. I push for load testing in staging before release, not after an incident.

The PM who understands performance testing is the PM who prevents outages instead of writing postmortems about them. That is a meaningful difference in how your engineering team perceives you.