Part 1: Front-end, back-end, APIs and requirements

Module 9 · Sun 13 Sep, morning

PM tech fluency is about working well with engineers - feasibility and clarity - not coding. The flow: the user acts on the front-end (what they see) → the API carries the request (the messenger) → the back-end and database apply the rules and store the state. An endpoint is the URL the front-end calls.

• HTTP methods: GET = fetch, POST = create, PATCH = update, DELETE = remove. Class cart example: viewing a menu is GET; adding to cart is POST, and the back-end checks the important fields.
• Status codes: 200 OK, 201 created, 204 success with no content, 400 bad input, 401 not logged in, 403 not allowed, 500 server error. The code is the back-end's; what the user sees next is the PM's call.
• Clear API contracts stop front-end/back-end rework.

Functional requirements = what the system does (made testable with acceptance criteria). Non-functional requirements = how well: latency (round-trip time), availability, rate limiting (cap requests per time window, based on expected usage and risk), scalability.

PMs own product behaviour and strategy; BAs more often own requirement gathering and docs. PMs watch behaviour through events and analytics, not raw API logs. Forecast usage feature by feature. Rule of thumb: set measurable targets and design both success and failure states.