Project Management Meets Product Management
A project has an end date and a product does not, and most of the friction between the two jobs comes out of that one difference. The project manager is accountable for something finishing. The product manager is accountable for something that will still be here in four years, being changed by people neither of them has met yet. Put those two accountabilities in the same governance meeting without agreeing anything in advance, and the argument that follows will be about scope, because scope is where the disagreement becomes visible.
The relationship works when three things have been settled early: who decides what gets built in what order, what counts as enough to go live, and whose budget carries the product once the project's has closed. None of those is difficult. They are simply easier to answer in month one than in the week before handover.
Two clocks in the same room
The project clock runs from an approved start to a defined finish, with a budget that closes and a set of commitments that were made before much was known. Everything in the discipline is shaped by that: baselines, forecasts, change control, the whole apparatus for keeping a commitment honest while circumstances move.
The product clock does not stop. Value accrues through use, the thing gets better or worse depending on what happens to it after release, and the central question is always what it should become next. Decisions are reversible in a way project decisions often are not, because there is always another release.
Section 2.3 of The Standard for Project Management sets out the considerations where these two overlap, and is careful about the conclusion: neither discipline subsumes the other. That matters, because the overlap is usually presented as a contest. In regulated manufacturing the project discipline is what keeps a commissioning sequence safe and a validation trail intact, and no amount of product thinking substitutes for it. In the same plant, three years on, the product discipline is what keeps the system useful once the original requirements have been overtaken by how people actually work. Both are doing necessary jobs on different timescales.
Where the two jobs touch
Priority. During delivery, somebody has to decide the order of work, and two reasonable people will order it differently: the project manager towards the dependency chain and the date, the product manager towards the users who will judge the thing. The workable arrangement is usually that the product manager sets the order of value and the project manager sets the order of feasibility, and the two are reconciled openly in the same forum every cycle. What fails is each quietly reordering the other's list.
Enough. Every release argument is a disagreement about a threshold that nobody wrote down. The project has a completion criterion, often contractual. The product has a judgement about whether this version earns the disruption of putting it in front of people. Writing both down, separately, before the first release, removes most of the heat from a conversation that otherwise recurs monthly.
Change during delivery. Where the project is modifying a product that already exists and is in use, the project cannot have exclusive control of it. Something will break in production on a Tuesday and need fixing that afternoon, and a change process built for project scope will not accommodate that. Agree the route for operational fixes early, including who is told and what happens to the baseline.
Life after go-live. Who owns the thing, who funds it, and who decides what happens to it next. This is the interface most often left until the closure meeting, which is the worst possible time, because everybody's attention has moved and the budget conversation now has to start from nothing.
When the project closes and the product carries on
A manufacturer was replacing shop-floor data capture across three plants: terminals at every station, a new production record, the old paper job cards withdrawn. The project had a date, a capital budget and a steering group. A product manager had been appointed for the system, sensibly, about four months in.
By the time the first plant went live, the two were in a weekly disagreement. The floor at plant one had produced around ninety change requests in six weeks, most of them small and several of them clearly right. The product manager wanted them. The project manager declined them, correctly, because they were not in the approved scope and the capital budget had no room in it. Both were doing their jobs and the effect was that good ideas from the people using the system went into a spreadsheet nobody owned.
What resolved it was not a scope negotiation. It was a funding boundary drawn in a different place. The operating budget for the system was brought forward to start at plant one go-live rather than at project closure, which created a six-month overlap in which both budgets were live. From that point the rule was simple enough to apply on the spot: anything needed to bring the remaining plants up safely belonged to the project, and anything that improved the system for the plants already running belonged to the product. The spreadsheet became a backlog with an owner and a budget, and about thirty of the ninety requests were delivered inside the overlap.
The overlap cost roughly four per cent of the capital value and it bought two things. The remaining plants went live with a system the operators at plant one had already improved, which took the resistance out of plants two and three. And the closure meeting, when it came, was a genuine closure, because there was nothing left in it that needed a home.
For a PMP® candidate, the thing to carry is that questions of this kind are rarely settled by deciding who is senior. A situation where a product owner and a project manager disagree about scope is usually pointing at a boundary nobody has drawn, most often a funding or decision-rights boundary, and the move that helps is to name the boundary and get it agreed. Governance situations where two accountable people are both right get a great deal of room in a structured PMP exam preparation course.
Where the product carries on after the project, one question is worth asking at the next steering group, however early it feels: on the day this project closes, whose budget pays for the next change to this thing, and who decides what that change is? If the room cannot answer in a sentence, that is the work, and it is far cheaper now than it will be in the final month.
Interested in going further?
Most project managers meet this boundary in the form of an argument about scope that neither party can win. Omega's PMP® Exam Preparation works through governance and value decisions where the authority is shared and the horizons are different.
The relationship between project and product work is set out among the considerations in The Standard, published with the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A027: Project Manager, Sponsor, Product Owner and Team: Who Does What?
A028: Project Manager vs Scrum Master vs Product Owner
A029: What Sponsors Should Do, and What They Shouldn’t
A007: The Standard for Project Management vs the PMBOK Guide
A191: Product Backlog vs Sprint Backlog
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
