Product-Oriented Management

Definition

Project-oriented management funds fixed-scope initiatives with a defined end date, allocates people to projects up front ("bring people to the work"), and measures success as being on time and on budget. Product-oriented management instead treats software as a durable value stream with a life cycle, not an end date: it funds incremental delivery of business results, keeps stable cross-functional teams assigned to one value stream ("bring the work to the people"), and measures success against business outcomes like revenue rather than schedule adherence. Kersten formalizes the contrast across six dimensions — budgeting, time frames, success criteria, risk, teams, and prioritization — in Table 2.1.

In the Book

The chapter grounds the distinction in a direct contrast: the BMW Group Leipzig plant, where value streams map straight to product lines (the 1-and-2-Series, i3, and i8 lines each have their own tuned takt time and their own team), versus "LargeBank," whose $1 billion transformation was organized as overlapping projects with no consistent way to identify the customer for each piece of the portfolio — making it impossible to even locate the delivery bottleneck. Kersten traces project management's lineage to Henry Gantt's 1917 chart and Taylorism, which treated workers as interchangeable resources reassignable across projects; he cites an internal survey at one enterprise where engineers were assigned to six to twelve different projects a year, causing what he calls a "staffing antipattern" — a measured productivity collapse whenever a person is split across more than one value stream. Boeing's 787 Dreamliner is offered as the physical-product analogue: a company organized around enduring product lines, not disposable projects, could pull off an innovation of that scale. The book also notes projects create a perverse budgeting incentive — since going back for more money means creating a new project, stakeholders are pushed to ask for the largest possible budget up front, baking uncertainty into the plan instead of letting a value stream learn and adjust incrementally.

Why It Matters

This gives a concrete, testable definition of the "project vs. product" distinction that management writing usually leaves as slogan. It names the specific mechanisms — funding unit, time horizon, team stability, risk placement — that make an organization behave like a temporary task force versus a durable capability, and it generalizes past software: any organization allocating people "to the work" in short-lived bursts versus building standing teams around outcomes is making this same structural choice, with the same staffing-antipattern and budgeting-incentive consequences either way.