Toolkit

The Inspector

Every browser ships a hidden window that shows the real traffic behind any page. Engineers live in it. It is the single most useful tool a non-technical PM can pick up, and there is nothing to install.

What this is

Right-click any page and choose Inspect, or press F12. A panel opens showing the requests the page made, the errors it logged, and the live HTML behind it. It is built for engineers, it works on every website, and opening it changes nothing.

Why a PM opens it

Triage with evidence: a 500 is the backend, a 401 is auth, no request at all is the frontend. That reading decides who gets the ticket.
Verify a feature really works, not just that it looks right on screen.
Answer a data question straight from the JSON a call returns.
Find the one slow call dragging a page down.
Confirm a tracking event actually fired when you clicked.

Anatomy of one request

Open the Network tab and click a single request. Every request has the same parts. Learn them once and you can read any of them.

Method: GET reads, POST creates or changes. Tells you if the action is safe to repeat.
Path: Which endpoint was called, for example /api/orders.
Status: 200 worked, 401 not logged in, 404 not found, 500 the server broke.
Time: How long the round trip took. This is where slow pages show themselves.
Headers: Extra info sent with the request, including the Authorization header that carries who you are.
Payload: The body you sent on a POST, for example the items and total on an order.
Response: What the server sent back, usually JSON. The answer your screen is built from.

Now you do it

These buttons fire real requests at the same routes the store uses. Run each one, then open the inspector and read what you made. The requests also appear in your browser own DevTools.

Run a search GET /api/search
Log in POST /api/auth/login
Place an order POST /api/orders (needs the token from login) (log in first)

Now open your browser DevTools (F12), Network tab, filter to Fetch/XHR, and run a task. You will see the identical request there.

Then answer, from what you see:

What status did the order return, and why 201 rather than 200?

It returns 201 Created. 200 means the request succeeded; 201 is the more specific success that says a new thing (your order) was created on the server. The family is the same (2xx worked); the exact code tells you what kind of success it was.

Where does your identity travel on the order request?

In the Authorization header, as a Bearer token you got back from login. Open the order request, look at its headers, and you will see it. That token, not your password, is what proves who you are on every request after login.

Do it for real

Open Chrome, press F12, click the Network tab, and set the filter to Fetch/XHR so you see data calls rather than images and scripts. Reload a page and watch the requests arrive.

Homework: pick a site you use every day, open the Network tab, do one action, and name the method and status of the request it fired. That is the whole skill.

Honesty note: the inspector on this site shows the real fetches this app made. Real DevTools shows those same requests. Nothing here is staged.

Related concepts

API Status codes JSON Bug severity and triage Browser DevTools

Next: How code ships