What product management is

Most software that fails does not fail because the code is wrong. It fails because it solves a problem nobody had, solves a real problem badly, arrives too late, or cannot be operated and improved once it ships. Software engineering, the subject of CMPUT-301, gives us disciplined ways to build things right: requirements, design, testing, version control and continuous integration. Product management asks the companion question: are we building the right thing, for the right people, at the right time, and will it keep delivering value after launch? This course is about that question and about the practical work of delivering software products with real clients.

CMPUT-401 is usually taken alongside a client project, in which a student team builds software for an outside organization: a charity, a clinic, a small business, a research lab or a municipal department. The course gives you the vocabulary, tools and habits that professional product teams use, so your project runs like a small product company rather than a long homework assignment. Throughout, we follow an invented client, Driftwood Ferries, a family-owned operator running three small car ferries between a mainland terminal and two islands. Driftwood wants a mobile-friendly web app so travelers can see sailing schedules, live waits and vehicle space, and eventually reserve spots. A student team, Team Lumen, will discover, plan, build, ship and measure that product across the twelve lessons.

Several earlier courses are assumed rather than repeated. CMPUT-301 covered process models, requirements, estimation with story points, UML, architecture, Git, testing, continuous integration and the DORA delivery metrics. CMPUT-404 covered how web applications are built, deployed and scaled. PMP-120 and PMP-121 covered team leadership, stakeholders and negotiation from a project management angle, and BUS-220 covered marketing, segmentation and pricing. We will point back to those courses and focus on what is distinctive about product work.

Products, projects and services

A project is a temporary endeavor with a defined start, end and scope: build the reservation feature by March. A product is something that delivers value to users over time and is continually improved: the Driftwood app, which will be maintained, extended and eventually retired. A service is value delivered through an ongoing relationship, often with people and software combined, such as a support desk. Many organizations run products through a series of projects, and the shift to thinking in products rather than projects is one of the defining changes in software management over the past two decades. A project asks whether we delivered the agreed scope on time and on budget; a product asks whether users' lives and the business are better because of what we shipped.

For a student client project the distinction matters because your engagement is a project (it ends in April) but your client is acquiring a product (they must live with it afterwards). The best student teams act as product teams during the engagement and plan for the handover: documentation, operations, and a backlog of next steps the client can pursue.

What a product manager does

The product manager (PM) is responsible for the value of the product: understanding customers and the market, deciding which problems to solve, setting priorities, defining success, and making sure the team ships things that achieve outcomes. A widely quoted formulation describes the PM as working at the intersection of the business (is it viable?), the user (is it valuable and usable?) and technology (is it feasible?). The PM usually has no formal authority over designers or engineers; influence comes from evidence, clarity and trust. Good PMs spend much of their time talking to users, reading data, writing short clear documents, and helping the team make good trade-offs quickly.

Other roles share the work. A product designer, sometimes split into user experience (UX) and user interface (UI) roles, researches users and designs flows, interactions and visuals. Engineers design and build the system and own its technical quality; a tech lead coordinates technical decisions. In Scrum, the product owner (PO) role is accountable for the product backlog and maximizing value; in many companies the PM is the PO, while in larger organizations a PO may be a narrower, team-level role working from a PM's strategy. Data analysts, quality specialists, product marketers and customer support staff contribute evidence and feedback. On a student team, the same person often plays several roles, which makes explicit decision rights more important, not less.

# Who decides what? A tiny decision-rights check for a product team.
decisions = {
    "Which customer problem to solve next":    "PM",
    "How the screen looks and flows":          "Designer",
    "Which database and framework to use":     "Tech lead",
    "Whether a story meets its acceptance criteria": "PM",
    "How many stories fit in the sprint":      "Developers",
    "Whether the release ships on Friday":     "PM + tech lead",
    "Contract scope and budget":               "Client sponsor",
}
owners = {}
for d, who in decisions.items():
    owners.setdefault(who, []).append(d)
for who in sorted(owners):
    print(f"{who}:")
    for d in owners[who]:
        print(f"   - {d}")
print()
print("Decisions with no single owner:", sum("+" in w for w in decisions.values()))

Client sponsor:
   - Contract scope and budget
Designer:
   - How the screen looks and flows
Developers:
   - How many stories fit in the sprint
PM:
   - Which customer problem to solve next
   - Whether a story meets its acceptance criteria
PM + tech lead:
   - Whether the release ships on Friday
Tech lead:
   - Which database and framework to use

Decisions with no single owner: 1

Shared decisions are fine, but they need a rule for breaking ties. A common pattern is that the PM decides what and why, the team decides how and how much fits, and the client sponsor decides scope and budget at the contract level. Writing this down early prevents the most common student-team conflict: two people each believing a decision was theirs.

The four big risks

A useful frame, popularized by product leader Marty Cagan, names four risks every product idea carries. Value risk: will customers buy it or choose to use it? Usability risk: can users figure out how to use it? Feasibility risk: can we build it with the time, skills and technology we have? Business viability risk: does it work for the rest of the organization, including legal, finance, support and brand? Engineering practices mainly address feasibility. Product discovery, the subject of lessons 2 and 3, exists to reduce the other three risks cheaply, before expensive building begins.

# Why discovery pays: the expected cost of building the wrong thing (illustrative numbers).
# A team of 5 costs about $14,000 per week (salaries, benefits, overhead).
team_week = 14_000
ideas = [
    # name, weeks to build, chance users adopt it if built blind, chance after 2 weeks of discovery
    ("Live sailing-wait display",  6, 0.55, 0.80),
    ("In-app reservations",       10, 0.40, 0.70),
    ("Loyalty points",             8, 0.20, 0.45),
]
print(f"{'idea':28} {'build $':>9} {'blind EV loss':>14} {'after discovery':>16}")
for name, weeks, p_blind, p_disc in ideas:
    cost = weeks * team_week
    loss_blind = (1 - p_blind) * cost                 # money spent on a feature nobody uses
    # discovery costs 2 weeks of one PM and one designer (2/5 of the team) but raises the odds
    disc = 2 * team_week * 2 / 5
    loss_disc = disc + (1 - p_disc) * cost
    print(f"{name:28} {cost:9,.0f} {loss_blind:14,.0f} {loss_disc:16,.0f}")

idea                           build $  blind EV loss  after discovery
Live sailing-wait display       84,000         37,800           28,000
In-app reservations            140,000         84,000           53,200
Loyalty points                 112,000         89,600           72,800

The numbers are invented, but the shape is typical. Building an idea that users do not adopt wastes the whole build cost, so even modest improvements in the odds of success pay for themselves when the build is large. Discovery is not free, and for a tiny, cheap, easily reversed change it can be skipped; the skill is matching the amount of evidence to the size and reversibility of the bet.

The product life cycle and the PM's focus

Products move through stages: an idea is explored, a first version reaches early users, the product finds product–market fit and grows, matures, and eventually declines or is retired. The PM's focus shifts across these stages. Early on, the main work is discovery and finding fit; during growth it is scaling, onboarding and reliability; in maturity it is efficiency, retention and incremental improvement; at the end it is a responsible sunset with data export and migration. Product–market fit, a term from investor Marc Andreessen, describes being in a good market with a product that satisfies it; a common rough test asks users how they would feel if they could no longer use the product, with a high share answering very disappointed signaling fit.

Product work on a client project

Client projects add a twist: the client is both a stakeholder and, often, a proxy for the real users. Driftwood's owner knows the business intimately but is not a typical traveler, and the deckhands who load vehicles see problems the owner never sees. Team Lumen must therefore distinguish the client's requests (what they ask for), the client's goals (what they want to achieve) and the users' needs (what would actually help travelers and staff). Lesson 11 covers contracts, scope and client communication in depth; for now, notice that a request such as add online reservations is a proposed solution, not a problem statement.

Product management also carries ethical weight. Products shape behavior at scale, and choices about defaults, data collection, accessibility and persuasive design affect real people. Regulators in Canada and the United States now actively pursue manipulative design, so-called dark patterns, as lesson 12 explains. A PM who optimizes a metric without asking who is helped and who is harmed is not doing the job well.

Worked examples