Product Delivery Manager (PDM)

1. Role Summary

The Product Delivery Manager (PDM) creates a single, transparent path from business needs to planned and delivered engineering work. Working with Oncoshot’s CEO, COO, CTO, Head of Engineering and business stakeholders, the PDM identifies operational and product gaps, clarifies the required outcomes, translates them into well-defined backlog items, and facilitates prioritisation, estimation and sprint planning with the development team.

The PDM owns the delivery process and the quality and transparency of the backlog — not architecture or implementation decisions, and not people management. An engineering background is not required, but sufficient technical literacy is: enough to work effectively with engineers, understand dependencies and constraints, and communicate delivery trade-offs accurately to non-technical stakeholders.

Success is measured by clear priorities, engineering-ready requirements, realistic sprint commitments, early visibility of risks and blockers, and a significant reduction in unplanned interruptions to the development team.

2. Key Responsibilities

• Work intake: Act as the single intake point for non-urgent development requests from executive, commercial, operations and hospital-network stakeholders. Identify the sponsor, affected users, expected benefit and supporting evidence, distinguish the business problem from a proposed solution, and route genuine production, security, privacy or regulatory incidents through the urgent-response process instead.

• Requirements analysis: Translate business needs into epics, user stories, tasks and investigations with clear problem statements, acceptance criteria and business rules — including non-functional requirements such as security, privacy, performance, auditability and operational support. Work with engineers, UX/UI, DevOps, AI and subject-matter experts to clarify requirements and surface dependencies.

• Backlog ownership: Maintain a clear, ordered and current backlog, with Jira and Confluence as the authoritative sources of truth. Apply an agreed Definition of Ready so that ambiguous work does not enter sprint planning, and break large initiatives into increments that can be estimated, delivered and validated progressively.

• Prioritisation: Prepare prioritisation options based on business value, customer and hospital commitments, security and compliance risk, dependencies, effort and urgency. Facilitate prioritisation with the CTO and business stakeholders, and make the consequences of every priority change explicit — including which work is delayed or dropped.

• Estimation and capacity: Facilitate estimation with the engineering team without replacing engineering judgement. Work with the Head of Engineering on capacity, leave and production-support commitments, support realistic forecasting with stated confidence levels, and never commit dates or scope externally without engineering input.

• Sprint delivery: Facilitate refinement, sprint planning, reviews and retrospectives, and establish a clear Sprint Goal with the CTO and Head of Engineering. Maintain visibility of progress without micromanaging, protect the Sprint Goal from avoidable scope change, and apply an agreed process when urgent work must enter an active sprint — recording what it displaces.

• Risks and dependencies: Keep risks, blockers, assumptions, decisions and dependencies visible; chase decision owners when work is blocked on information, access or approval; and escalate early with realistic options. Coordinate cross-functional dependencies, including hospital-specific requests that require core-platform changes and shared dependencies with the Data Pipeline Engineer.

• Validation and release readiness: Coordinate sprint demonstrations, business validation and User Acceptance Testing; confirm delivered work meets its acceptance criteria and has an accountable business owner; track defects, follow-up work and deferred requirements; and support release planning, communications and operational readiness.

• Executive visibility: Give C-level stakeholders a concise, factual view of the Sprint Goal, active and likely next work, blocked or at-risk items, material dependencies, recent priority changes and decisions required from management — through maintained dashboards and reports rather than ad hoc status requests.

• Continuous improvement: Facilitate retrospectives with owned follow-through, address the recurring causes of unclear requirements, rework, carry-over and unplanned work, and monitor delivery-flow indicators such as cycle time, blocked-item age and forecast reliability — never as individual performance measures.

3. Decision Rights and Role Boundaries

The PDM is authorised to enforce the Definition of Ready and return unclear requirements for clarification; maintain day-to-day backlog order within priorities approved by the CTO; require that proposed urgent work identifies the planned work it would displace; escalate unresolved blockers, risks and priority conflicts; publish accurate delivery status and risk information; and redirect informal requests to engineers through the agreed intake process.

The PDM is not authorised to determine architecture or implementation design; override engineering estimates or assign technical tasks; commit delivery dates without engineering and capacity input; evaluate engineers’ technical competence or performance; accept material security, privacy, clinical, regulatory or architectural risk; or insert work into an active sprint solely because a senior stakeholder requested it.

Final accountability remains as follows: the CTO owns technology strategy, core-product priority decisions, architecture and technical risk; the Head of Engineering owns engineering execution, capacity, assignments and people management; engineers own estimates, implementation plans and technical quality; business sponsors own business outcomes and acceptance; and the CEO resolves unresolved company-level priority or resource conflicts.

4. Preferred Qualifications

• Bachelor’s degree in Business, Information Systems, Product or Project Management, Computer Science or a related discipline, or equivalent professional experience.

• At least 4 years as a Product Delivery Manager, Product Owner, Business Analyst, Agile Delivery Manager, Scrum Master with significant business-analysis responsibilities, or software project/programme manager in an Agile environment.

• Demonstrated experience gathering and analysing business requirements for software products, and writing user stories, acceptance criteria and functional requirements.

• Hands-on backlog management in Jira and documentation in Confluence or comparable tools.

• Practical experience facilitating backlog refinement, estimation, sprint planning, reviews and retrospectives.

• Strong understanding of Agile, Scrum and Kanban, with the judgement to adapt them pragmatically for a small, senior, distributed team rather than applying ceremonies mechanically.

• Sufficient technical literacy to work with engineering, UX/UI, DevOps and AI teams and to reason about APIs, databases, cloud services, environments, releases, defects and dependencies. An engineering background is not required.

• Experience with remote, cross-functional teams, and excellent written and verbal English.

• Experience in healthcare, clinical research, life sciences or other regulated, data-sensitive environments is advantageous. Certifications such as CSPO, PSPO, PSM, CSM or PMI-PBA are welcome but not mandatory.

5. Core Competencies

• Structured problem framing: Identifies the real business problem, affected users, desired outcome and constraints before creating development work.

• Requirements clarity: Produces concise, testable backlog items with enough detail to build from, and no unnecessary documentation.

• Facilitation: Runs focused discussions that end in decisions, clear ownership and next steps.

• Prioritisation discipline: Helps stakeholders separate importance from urgency, and makes trade-offs and displaced work visible.

• Stakeholder management: Works confidently and diplomatically with C-level executives, operational stakeholders and senior engineers, and can respectfully challenge incomplete requirements, unsupported deadlines and conflicting requests.

• Delivery judgement and integrity: Understands uncertainty, dependencies and capacity, avoids false precision in forecasts, and reports status and risk accurately — including when the message is uncomfortable.

• Follow-through: Protects engineering focus while maintaining business visibility, and keeps reliable records of decisions, priorities, dependencies and commitments across workstreams.

6. Success Measures (First 3 Months during Probation Period)

• Established a single intake route for new development requests, and rationalised the existing backlog — ownership clarified, duplicates and stale requests resolved, and all material active work visible.

• Implemented an agreed Definition of Ready and a working cadence of refinement, prioritisation, planning, review and retrospectives, with a visible risk, blocker and decision log.

• Produced a reliable executive delivery view — current and likely next work, at-risk items and decisions required from management — measurably reducing ad hoc status requests and unplanned interruptions to engineers.

• Maintained at least one sprint of engineering-ready work ahead of the active sprint, and established a baseline for carry-over, cycle time, blocked-item age and forecast reliability.

7. Working Model

• Probation period: First 3 month probation period and conversion to permanent staff after passing the probation.

• Reporting line: Reports to the Chief Technology Officer, in close partnership with the Head of Engineering, and working regularly with the CEO, COO and other business leaders.

• Team relationship: Supports the development team’s planning and delivery process but does not manage engineers; no direct reports initially.

• Cross-functional relationship: Works with UX/UI, DevOps, AI, commercial, operations and hospital-delivery functions.

• Data Pipeline Engineer interface: Coordinates requests and dependencies requiring core development support; the Data Pipeline Engineer remains accountable for hospital pipeline delivery under the COO.

• Delivery cadence: Operates within an Agile delivery model, using regular refinement, planning, review and retrospective cycles.

• Location and arrangement: Preferably Singapore-based; remote candidates with substantial working-hour overlap with Singapore and the distributed engineering team may be considered.

8. Salary Range

Indicative monthly gross salary: SGD4,000 – SGD8,000 (exclude CPF for PR/Singaporean and performance bonus/benefits/Employee Equity Share), commensurate with experience and seniority.