Roadmaps

Value, usability, feasibility, viability — the four ways an idea fails, and who on the team owns each one.

A free book on fixed time, variable scope: shaping work before it is bet on, and why unbounded projects run over.

How to keep an outcome, the opportunities under it and the solutions you are testing visible in one structure.

The paper behind HEART — how to pick UX metrics that connect to goals instead of counting whatever is easy.

The method-selection map: attitudinal vs behavioural, qualitative vs quantitative, and where each method sits.

Which activity fits which phase of a project — useful when you have to justify a method to a stakeholder.

Research practice written for teams under delivery pressure, including recruiting and research with people who are not online.

Open, closed and hybrid sorts, and what each one tells you about naming and grouping.

The ten heuristics, each with examples. Still the fastest way to turn a vague concern into a named problem.

Hick's, Fitts's, Jakob's and the rest — the psychology behind interface decisions, one page each with the original sources.

Discover, define, develop, deliver — from the organisation that named it, rather than a redrawn version of the diagram.

A reading order for IA: structure, labelling, navigation and search, with the research methods that inform each.

What actually belongs in a journey map, and why one without a stated scenario and persona is decoration.

Platform conventions from the platform owner — the reference to check before inventing a pattern on iOS.

The Android counterpart, and a worked example of a design system: tokens, components and the reasoning under them.

Filterable success criteria with techniques. The normative source, not a blog's summary of it.

Component-by-component: what each pattern must do for keyboard and screen-reader users, with the markup.

The full book, free to read — where the atoms/molecules/organisms vocabulary comes from and how to apply it.

Type decisions argued from readability rather than taste: measure, spacing, scale and when defaults are fine.

Free run-sheets for the meetings design work actually depends on: kickoffs, critiques, retros and stakeholder alignment.

How design fits into agile delivery in practice — roles, ceremonies and where a designer's work meets a sprint.

How to run a critique that improves the work instead of relitigating taste — structure, roles and what to ask for.

Primary resources on OKRs from the source that popularised the format — for writing goals a design team can be held to.

Client, server, packets, DNS and hosting in one walkthrough — the plumbing every later topic assumes.

The free, canonical Git book. Chapters 1–3 cover everything a day-to-day workflow needs.

An interactive sandbox for branching and merging — where Git's mental model actually clicks.

What a package manager is actually managing — registries, package.json and the lockfile.

Why semantic markup is the cheapest accessibility work you can do, with the elements that carry meaning for free.

The mental model for flex containers and items — main axis, cross axis, and how sizing actually resolves.

A structured course on responsive layout, viewport units and media queries, not just a single article.

The language reference to keep open in a tab — closures, prototypes and the DOM APIs, explained rather than just listed.

A free, structured path through the language from fundamentals to browser APIs — good as a first read-through, not only a reference.

The official handbook. Read "Everyday Types" and "Narrowing" before anything else — most confusion starts there.

The current official React docs, rewritten around hooks and function components — skip anything older that still teaches classes first.

The App Router docs, including the rendering model — a concrete example of what a meta-framework actually adds over a framework.

SSR, SSG, CSR and the hybrids, compared on trade-offs rather than sold as one right answer.

Why a dev-server-first build tool is faster to work in than a bundler-first one, from the maintainers.

End-to-end testing that runs against real browsers — the docs double as a solid intro to what E2E testing is for.

Where linters, formatters, bundlers and transpilers each sit in a build pipeline, and why a project needs more than one.

The ten most common web application risks, ranked and explained — the baseline before any framework-specific security advice.

A full course on what actually makes a page feel fast, past just running Lighthouse and chasing the score.

HTTPS, CSP, CORS and same-origin policy gathered in one index, each linking to the deeper reference.

The spec behind MCP, from the source — for understanding what an AI coding agent is actually calling, not just prompting it.

Methods, status codes, headers and caching in one reference — the protocol every backend framework sits on top of.

The same free book as on the front-end side — branching and history matter just as much on a server codebase.

What actually makes an API RESTful — resources, statelessness and HTTP verbs used as intended, not just JSON over HTTP.

The official learn section — schemas, queries and resolvers, from the people who built the spec.

The dissertation that coined REST. Chapter 5 is the primary source everyone else's REST article is summarising.

The official tutorial, worth doing even if the eventual database is something else — the SQL fundamentals it teaches are portable.

A free, focused guide to why a query is slow and what an index actually does about it — SQL-flavour agnostic.

The reference for the document model — where it earns its keep over relational, and where it doesn't.

Cache-Control, ETags and validation, worked through with the header values rather than left abstract.

Concrete do/don't guidance on passwords, sessions and account lockout — the checklist before shipping an auth flow.

What is actually inside a JWT and what it is and isn't good for — read before reaching for it as a session mechanism.

The methodology behind config, statelessness and disposability in service design — short, and the source for a lot of later advice.

The article that named the pattern, including the costs it doesn't market — worth reading before adopting it by default.

Topics, partitions and consumer groups from the project itself — the concepts behind any "why not just use a queue" question.

What CI actually requires to work — everyone committing to trunk daily against a suite that runs fast — not just a pipeline YAML file.

Why more unit tests and fewer end-to-end tests is the shape to aim for, and what goes wrong with an inverted pyramid.

The same MCP spec referenced on the front-end side — how an AI agent calls out to tools and data, from the source.

The job described from the responsibilities, not the title — a good corrective before reading a dozen conflicting job posts.

A short, direct contrast that makes the difference between a feature factory and a product team concrete.

The original essay on product/market fit — the source everyone else's summary of the term is drawing from.

The same structure referenced on the Product Design roadmap — it belongs here just as much: one outcome, many opportunities, many possible solutions.

A practical walkthrough of Jobs to Be Done from a company that builds around it — the framing question, not just the label.

How to ask questions that surface behaviour instead of opinion — the same skill a design researcher needs, aimed at PM discovery.

Basic, performance and delight features explained with the graph that makes the distinction click.

The format itself, and why time-boxed roadmaps tend to break their promises faster than theme-based ones.

Reach, impact, confidence, effort — how the score is actually calculated, and where teams tend to fudge the confidence input.

A practical checklist for judging whether PMF is real, as a companion to Andreessen's original essay under Foundations.

Four values, twelve principles, one page — the primary source behind every framework that claims to be "agile".

What a PRD needs to contain to actually be useful to engineering, not just to the PM who wrote it.

Why decoupling deploy from release changes how a team can roll out and roll back — from a company built around the idea.

How Google actually runs OKRs internally, including the scoring convention and the meetings that keep them honest.

How to pick one metric that reflects real customer value, and the difference between a North Star and a vanity number.

The same HEART paper referenced on the Product Design roadmap — goals, signals and metrics, this time read for product-level tracking rather than a single UI.

A neutral overview of the discipline and where it sits between strategy, IT and operations — a reasonable first stop before the vendor-specific material.

The professional body's own framing of the BABOK Guide's six knowledge areas, from the organisation that maintains it.

The role itself, distinct from the discipline article above — scope, typical employers, and how it overlaps with adjacent titles.

A working BA's rundown of which technique fits which situation — interviews vs workshops vs observation, not just a definitions list.

Where elicitation sits in the requirements lifecycle, and the difficulty everyone underestimates: stakeholders rarely state what they actually need.

The format and the "so that" clause explained — useful for a BA writing requirements a delivery team will actually build from.

The notation itself — gateways, events and swimlanes — from a tool vendor that has to explain it correctly to sell against it.

How a DFD differs from a process map: it traces information, not sequence, which is the distinction most beginners miss.

The technique in five minutes, plus its actual failure mode: stopping at the first plausible-sounding answer instead of the real root cause.

A practical walkthrough with a worked example — useful for seeing what goes in each quadrant, not just the four-letter acronym.

The questions a feasibility study actually needs to answer before a solution gets committed to — technical, operational and financial, not just "can we build it".

A change management model built around the individual, not the org chart — from the firm that created it, on why adoption fails even when the solution works.

What UAT is actually verifying — that a solution meets the business need, which is a different question from whether the code works.

Responsible, Accountable, Consulted, Informed — worked through with a real example of where a RACI usually goes wrong (too many "accountable" rows).

A power/interest grid as an actual template, not just the theory — useful for seeing what the output is meant to look like.

The method's origins and its main variants — worth knowing there is more than one school of stakeholder analysis before picking a template.

A neutral overview of the discipline's history and methodologies — a reasonable map before choosing which framework to go deep on.

A practitioner's framing of the role and the triple constraint — scope, time and cost — with the trade-offs stated plainly.

The role itself, distinct from the discipline article above — responsibilities, and where it overlaps with adjacent titles.

The deliverable-oriented decomposition a schedule is built from — the concept that most estimating mistakes actually trace back to.

Why some tasks can slip without moving the finish date and others can't — the calculation, not just the definition.

Where the format came from and what it's genuinely good at showing — dependencies and timeline, not team capacity.

How to tell "behind schedule" from "over budget" from the same numbers — the method behind the status-report traffic lights.

Why scope grows a little at a time rather than all at once, and why a change control process exists specifically to catch that.

Identification, assessment and response strategy as a repeatable process, not a one-time exercise done at kickoff and forgotten.

The primary source, from Scrum's creators — thirteen pages, and worth reading directly instead of a certification course's paraphrase of it.

WIP limits and flow explained as the actual mechanism, not just "a board with columns".

What the three questions are actually for, and how a standup drifts into a status meeting if no one guards against it.

The same manifesto referenced on the Product Management roadmap — the values every framework here, Scrum included, claims to implement.

Who counts as a stakeholder and why the definition is broader than "people who attend the status meeting".

The same change model referenced on the Business Analysis roadmap — relevant here too: a project can close on time and still fail to stick if adoption was never planned for.

What the PMP certification actually covers and requires, from a neutral source rather than a training vendor's sales page.