Skip to main content
Next Step PM
Back to the library

Test · Core

Check performance and reliability

Users leave slow or unreliable products. Agree how fast and available the product must be, test that it is, and make sure the team will know quickly when it is not.

About 2-5 daysEvergreenLast reviewed 5 November 2026

Who this applies to

Skills it builds
Technical and AI fluency
PM types
All
Product types
All
Starting points
All
Ways of working
All
Experience
Intermediate (1 to 4 years)Experienced (5+ years)
Size of organisation
All

Steps, by experience

Beginner (under 1 year)

  1. Agree simple targets with engineers, for example 'pages load in under 2 seconds for most users' and 'the service is available 99.5 percent of the time'.
  2. Find out how many users you expect at the busiest times.
  3. Ask the team to test the product under that load and a bit more.
  4. Check what happens when something fails: is there a clear error message and a way to recover?
  5. Make sure alerts are set up so the team hears about problems before users complain.

Intermediate (1 to 4 years)

  1. Agree service level objectives for speed and availability.
  2. Run load and failure tests against expected peak use.
  3. Check monitoring and alerting cover the key user journeys.
  4. Decide what to fix before launch and what to accept.

Experienced (5+ years)

  1. Set objectives from the user's point of view and agree an error budget with engineering.
  2. Use the error budget to balance new features against reliability work.
  3. Plan capacity for growth and for unusual peaks.
  4. Run game days to rehearse failures.

Who can do this

Owner: Product manager

Can be delegated to

  • DevOps / SRE or Backend Engineer: Set up monitoring, alerting and load tests
  • QA / Tester: Run performance and failure test scenarios
  • Tech Lead: Agree targets and decide on fixes

Reviewed by: Tech Lead, DevOps / SRE

Tool examples

AWS
Use CloudWatch alarms on error rates and response times for the key journeys.
Azure
Use Azure Monitor alerts on error rates and response times.
Google Cloud
Use Cloud Monitoring to set service level objectives and alerts.
Vercel
Check Speed Insights for real-user page load times.

Definition of done

  • Speed and availability targets agreed
  • Load and failure tests run
  • Monitoring and alerts cover key journeys

Common pitfalls

  • Testing only with a handful of users
  • No alerts, so users find problems first
  • Aiming for 100 percent availability, which is rarely worth the cost

If you lead the team

What good looks like: Speed and availability targets are tested before launch and watched afterwards.

Ask your PM

  • Have we tested at the load we expect on launch day?
  • What happens if this goes down?

Warning signs

  • Performance is tested only on a developer's laptop.
  • There's no plan for peak demand.

Do these first

Sources