This document briefly explains what the key roles around a project and product are, what their responsibilities are, and how those roles map to specific artifacts in the learning library.

The purpose is not for the candidate to become a project manager or product manager, but to understand:

• who makes which type of decision,
• who defines the problem and scope,
• who drives delivery,
• who is the owner of operational stability and service governance,
• whom the developer addresses which type of question to,
• how those questions are distributed across the learning path: 00_end2end_onboarding.html for the umbrella plan, 04_infrastructure.html for the delivery/runtime mental model, and 05_Odoo_from_0_to_hero.html for the Odoo learning path.

1) Why these roles matter

A junior developer often confuses who decides what the product should do, who drives delivery, who owns business value, and who keeps the system running. Distinguishing four roles early prevents wasted work and misdirected questions:

• Product Manager — owns product shape,
• Business Owner — owns business meaning and priorities,
• Project Manager — owns delivery coordination,
• Service Owner — owns operational stability after go-live.

2) Product Manager

Product Manager is the owner of product shape — which problem the product solves, who the users are, what is in/out of scope, and what acceptance criteria look like.

Product Manager does not have to know technical implementation details, but must know what the product should do, for whom, and what success looks like.

Key references: Scrum Guide (Product Owner), SAFe, SVPG, AIPMM.

Example questions a developer addresses to Product Manager:

"Should this flow even exist?"

"Is calendar view a must-have or a nice-to-have?"

3) Business Owner

Business Owner is the owner of business meaning and business priorities — why this module matters, what the real operational problem is, and which rules are genuine business obligations vs. technical ideas.

Business Owner does not write tickets, but is crucial for confirming the problem exists, the solution is meaningful, and priorities are correct.

Key references: SAFe (explicit Business Owner role), BABOK, governance practices.

Example questions a developer addresses to Business Owner:

"Is the instructor actually allowed to be an attendee?"

"Is overbooking forbidden in all cases or are there exceptions?"

4) Project Manager

Project Manager is the owner of delivery coordination — planning, work sequencing, dependency management, communication, rollout, and handoff.

Project Manager does not define business rules, but ensures delivery has a realistic scope, an agreed sequence, status visibility, and a clear handoff.

Key references: PMBOK (PMI), PRINCE2, ISO 21502.

Example questions a developer addresses to Project Manager:

"What goes into this phase and what do we leave for phase 2?"

"When is the expected demo / verification / promotion?"

5) Service Owner

Service Owner is the owner of the operational service after the software is live — service ownership in production, SLA/OLA tracking, incident/problem/request coordination, vendor management, and ensuring the support process works.

Service Owner does not define product shape or the delivery plan, but is crucial when the system is live and it matters that a support model exists, escalations have an owner, and operational quality is not left to chance.

Key references: ITIL, ISO/IEC 20000, COBIT, SIAM, SRE/DevOps practices.

Example questions a developer addresses to Service Owner:

"Who owns incident coordination when production goes down?"

"Who tracks whether the external vendor is actually meeting the SLA?"

\n

6) How roles appear in the library module example

• Product Manager defines that the module should cover the library model, book/member actors, and basic search/filter.
• Business Owner confirms that ISBN validation, member limits, and book lifecycle are truly important business rules.
• Project Manager drives the work so that the skeleton is done first, then MVP, then business logic, then website UI — instead of everything happening at once.
• Service Owner would, once the module enters production, own the support model, ticket intake, and operational review.

7) How roles map to documents

This is the minimal mapping across learning artifacts:

7.1) 00_end2end_onboarding.html

• Document Owner: Mentor (Project Manager for on-boarding)
• Product Scope Input: Product Manager
• Business Context Input: Business Owner

Why: umbrella document — defines the learning path, schedule, and exit criteria for the entire on-boarding.

7.2) 01_project_product_mgmt.html (this document)

• Document Owner: Product Manager
• Accountable for business correctness: Business Owner
• Consulted for delivery sequencing: Project Manager

Why: describes the four roles and why a developer must understand each one before writing code.

7.3) 04_infrastructure.html

• Document Owner: Project Manager (delivery/runtime mental model context)
• Product input: Product Manager (the functional flow must be understandable in delivery reasoning as well)
• Business context: Business Owner (when a runtime decision has business impact)

Why: describes how the entire system works — AWS, Docker, Terraform, problem-class separation (infra vs. runtime vs. application).

7.4) 05_Odoo_from_0_to_hero.html

• Document Owner: Project Manager (Odoo learning path sequencing)
• Product input: Product Manager (functional requirements determine which Odoo topics are a priority)

Why: step-by-step tutorial for building the library Odoo 19 module — models, views, security, business logic, tests, website UI.

7.5) Maintenance / support operating model

• Document Owner: Service Owner
• Input from: Product Manager, Business Owner, Project Manager

Why: when the software transitions to production, Service Owner is responsible for ticket intake, vendor coordination, SLA, and operational review.

8) What a developer should learn from this

• When you are not sure whether a feature should exist, you address the question to Product Manager.
• When you are not sure whether something is truly a business rule, you address the question to Business Owner.
• When you are not sure whether the delivery should go out in this release, you address the question to Project Manager.
• When you are not sure whether an incident or ticket has an owner and whether the SLA process works, you address the question to Service Owner.
• When you are not sure in which system or layer the problem lives, first read 04_infrastructure.html to distinguish delivery/infra/runtime/application/functional domain.
• Do not assume scope or rules. Document what you know and what you assume.

9) Summary — one sentence per role

• Product Manager: defines what the product should do and for whom.
• Business Owner: confirms why it matters and whether the business rules make sense.
• Project Manager: coordinates when, how, and in what sequence delivery happens.
• Service Owner: ensures the system in production actually works, that a support model exists, and that SLA obligations are met.

When the module lives in production, these roles still apply: Product Manager evaluates new features, Business Owner confirms priorities, Project Manager coordinates releases, Service Owner drives operational stability, and the developer delivers per ENGINEERING_CODEX.md standards.