Roles, Deliverables, and Prioritisation
Roles in Software Development
The boundary between “what to build” and “how to build it” is managed by distinct roles:
| Role | Responsibility | Key deliverables |
|---|---|---|
| Product Manager (PM) | Owns the “Why” and the “What.” Conducts user research, analyses markets and competitors, defines priority by business value, and shields engineers from changing whims. | Product Requirements Document (PRD), user stories, roadmap |
| Engineering Manager (EM) | Owns technical execution. Decides who builds what, oversees architecture and code quality, manages developer career growth and team health. | Technical design documents, sprint plans, team staffing |
| Technical Programme Manager (TPM) | Manages complex cross-team dependencies. Common at large tech companies (Google, Amazon) where a feature spans five teams each with their own PM and EM. | Cross-team timelines, risk registers, dependency maps |
The PM decides what should be built and in what order. The EM decides how to build it and with whom. The TPM ensures that when something from Team A is needed by Team C, everyone knows and has planned for it. Clear role separation prevents Product from micromanaging architecture (PM saying “use React”) and Engineering from unconsciously steering the product to what is technically fun rather than what users need.
The MoSCoW Prioritisation Method
When scope is larger than time and budget allow (which is always), MoSCoW provides a structured framework for triage:
- Must have: the product is completely unviable without this. If this is missing, there is no point launching. Example: a login mechanism for a user-account-based service.
- Should have: highly important; the product is significantly weakened without it, but a Version 1 could launch and still deliver value. Example: a “reset password” email flow — users who forget their password cannot use the service, but many will remember.
- Could have: nice to have if time and budget permit; easily deferred to Version 2 without reputational or competitive damage. Example: a dark-mode toggle.
- Won’t have: explicitly out of scope for this release. This is as important to document as the included features — it prevents scope creep and manages stakeholder expectations.
The Product Requirements Document (PRD)
The PRD is the “source of truth” for a feature or product. Authored by the PM, it typically contains:
- Background: the market context, competitive landscape, and why this feature matters now.
- Business goals: measurable outcomes (e.g. “reduce checkout abandonment by 15%”).
- Personas: the target users, described concretely (not “a user” but “Emma, a 34-year-old shift manager in a warehouse, who checks inventory on a tablet while walking between aisles”).
- Functional requirements: what the system must do, ideally structured as user stories (“As a [persona], I want [feature], so that [value]”).
- Non-functional requirements: the -ilities, with fit criteria.
- Out of scope: explicit “Won’t have” items.
A good PRD answers “what?” and “why?” but does not prescribe “how?” — that is the EM’s domain.
Requirements Traceability
Traceability is the ability to follow a requirement from its origin to its implementation and verification:
In practice, this means linking IDs across artifacts: Requirement #42 in the PRD is addressed by Pull Request #105, which adds a new module, and the module is verified by test_req_42() in the test suite. When all these links exist and are maintained, you can answer questions like “Why was this line of code written?” and “Is every requirement from the PRD actually tested?”
Highly regulated industries (aviation, medical devices, nuclear) require formal traceability matrices — a table mapping every requirement to every test that verifies it, signed off by independent auditors. This is the engineering reality behind “move fast and break things” vs “people will die if we get this wrong” — the regulatory environment determines how much process overhead is required by law.
Expected Learning
- Distinguish the PM, EM, and TPM roles, explaining what each owns and what they deliver.
- Apply the MoSCoW framework to prioritise a given list of features.
- Describe the purpose and typical contents of a PRD.
- Define requirements traceability and explain why it is essential in safety-critical or regulated domains.
Past Paper Questions
Scenario-based Tripos questions often describe a team structure and ask you to assess whether the roles and assignment of responsibilities are appropriate. MoSCoW prioritisation is a natural framework for answering “which of these features should be cut to meet the deadline?” — name the method explicitly.