Technical literacy

What every non-coding role needs to understand about how software is built, how the web and APIs work, and how to read code and data without writing much.

Software development lifecycle

Also called SDLC

What: The stages software goes through: discovering the need, designing, building, reviewing, testing, releasing, operating and improving it.
Why: Each non-coding role plugs into specific stages. Knowing the whole cycle tells you when your input helps and when it arrives too late.

Watch out

Joining at the end, such as writing docs or planning launch content only after the code is finished.

Agile, sprints and tickets

Also called Scrum, Kanban, backlog, user story, sprint, ticket

What: A way of working in short cycles, often one or two week sprints, with work broken into tickets on a board and planned from a backlog.
Why: Tickets, standups, planning and retrospectives are how teams coordinate; you will write, comment on or be tracked through them.

Watch out

Treating the ceremonies as the goal. The point is to ship small, learn and adjust.

Client, server and the web

Also called frontend, backend, browser, client-server

What: A client such as a browser or mobile app sends requests over the internet to a server, which runs code, reads a database and sends back a response.
Why: Most product questions, bugs and docs topics make sense once you know which part runs where.
Example: A slow page could be slow code on the server, a slow database query, a large image on the client or a poor network.

HTTP methods and status codes

Also called GET, POST, 404, 500, HTTP, status code, HTTP method

What: HTTP requests use methods such as GET to read and POST to create, and responses carry status codes: 2xx success, 4xx client errors, 5xx server errors.
Why: Status codes appear in bug reports, API docs and dashboards. Reading them lets you tell a user mistake from a system failure.

Watch out

Reporting every error as "it is broken" without the status code and request that would let an engineer reproduce it.

API

Also called REST API, endpoint, web API

What: A defined way for one piece of software to ask another for data or actions, usually as HTTP requests to endpoints that return JSON.
Why: APIs are products in their own right for many companies. PMs define them, writers document them and advocates teach them.
Example: GET /v1/orders/42 might return the order with id 42; POST /v1/orders creates a new one.

JSON

What: A text format for structured data made of objects in braces, arrays in brackets, strings, numbers, booleans and null.
Why: API responses, configuration files and event data are usually JSON, so you need to read it comfortably.

JSON

{
  "id": 42,
  "status": "paid",
  "items": [{"sku": "A1", "qty": 2}]
}

Git and pull requests

Also called PR, merge request, code review, Git, pull request

What: Git tracks changes to files; a pull request proposes a change, shows the difference and lets others review and discuss it before it is merged.
Why: Reading pull requests shows you what actually changed. Writers and advocates also submit their own docs and samples this way.

Watch out

Avoiding Git because you are not an engineer; it is the everyday tool for docs as code and sample apps.

Reading code without writing much

Also called reading code

What: Following what code does by reading names, function signatures, comments, tests and pull request descriptions, and asking targeted questions.
Why: You can answer many questions yourself, check whether docs match behaviour and earn engineers' respect by asking precise questions.
Example: To learn what a config option does, search the code for its name, read the function that uses it and its test, then confirm with the author.

Basic SQL

Also called SELECT, query, SQL

What: The language for asking questions of relational databases: select columns, filter rows, group and count, join tables.
Why: Being able to pull your own numbers makes you faster and more credible, especially as a PM.

SQL

SELECT plan, COUNT(*) AS users
FROM accounts
WHERE created_at >= '2026-01-01'
GROUP BY plan;

Watch out

Trusting a number without checking what the table actually counts, such as test accounts or duplicates.

Environments, releases and incidents

Also called staging, production, feature flag, outage, incident, environment

What: Code moves from development to staging to production; feature flags turn features on for some users; incidents are unplanned outages handled urgently.
Why: Launch dates, docs publishing and announcements must line up with when code is really live for users.

Watch out

Announcing a feature that is merged but still behind a flag for most users.

Go deeper