Everything the user sees and touches: the pages, buttons, text, and layout running inside their browser or app.
Why it exists
Data sitting on a server is invisible until something turns it into a screen the user can actually see and touch, and that rendering has to happen on the user's own device, not on the server. The frontend exists to be that layer: it draws the pages, reacts to every tap and click, and packages what the user does into requests to send back. Because it runs on the user's device and holds no data of its own, it is fast to change and safe to experiment on, but it can never be the place you enforce a rule or keep a secret.
How it actually works
The frontend is the part of your product that lives on the user's device. It draws the screen and reacts to taps and clicks. When you change a button colour or move a menu, that is frontend work.
On its own the frontend has no memory and no data. It shows whatever it is given and sends whatever the user does back to the server.
A senior PM walks you through it
A junior PM, stuck
A customer sent a screenshot of the Ilish Bhaji Thali showing an Order button when it was sold out. My lead asked whether the screen drew it wrong or was handed wrong data. I did not know there was a difference, let alone how to tell which one it was.
There is a difference, and it decides which team fixes it. The screen is just the frontend wearing data: every pixel traces back to a field in the response. This is the menu response that fed that screen, with each field lined up to what it becomes on the card. Read it and you can say, from the data alone, whose bug it is.
GET /api/products response, one item, mapped to the menu card
Response body, one product
1{
2"id":"p_1046",
3"name":"Ilish Bhaji Thali",
4"price":360,
5"in_stock":false
6}
Click a step to see the lines it points at.
Mistakes I've seen
Assigning a visual bug to the backend because pricing feels like server work. Read the field first: if the response said false and the screen still showed Order, no backend change fixes it.
Searching the JSON for the words on screen. "Sold Out" is not in the data; it is the frontend's translation of in_stock: false, so looking for the label and finding nothing proves nothing.
Trusting the screenshot over the response. Screens cache, so the customer may be seeing an old menu; pull the actual response the app got before deciding whose bug it is.
Calling a formatting problem a data problem. 360 with no taka sign is a frontend display fix; 360 when it should be another number is a backend data fix. Different tickets.
Say: "The response has in_stock false, so the data was right, the card drew an Order button anyway. This is a frontend bug." You read the field behind the pixel and routed it. That is the frontend-versus-data skill.
Where a PM meets this
Frontend changes are visible, quick to demo, and easy to A/B test, which is why they often feel "cheap" even when they are not.
When a user sends a screenshot of something looking wrong, the frontend is usually the first suspect.
Hear it in a meeting
"That's just a frontend change, we can ship it without touching the backend."