So here we have our first reader comment (RC) based post. In response to my post about product managers, James Ifill asked several good questions, which I'll address in separate posts over time. The one I'm focused on here is: "
Is there a direct 1-1 relationship between the delivery of a project and the delivery of a product?"
The short answer is no. It is far more likely that there is a 1:many relationship between delivery of a product and delivery of projects. A particular product, because it has an indeterminate life, is likely to be the subject of several projects over its lifecycle.
The most obvious one, of course, is the project to set up/create/establish the product in the first place. In this sense, the product (and its associated parts) are described in the product WBS while the project structure around the setup forms the project WBS. Within this model, there is a 1:1 relationship between project and product in that the end result of the project IS the product.
Where product-based thinking differs, however, is what happens next. After the product is brought into the world, subsequent projects to alter/enhance or even retire the product are still part of the same product delivery lifecycle. Thus, you may have the initial product creation, a significant enhancement project, a relaunch project after 3-4 years, and then a retirement effort -- all 4 projects for 1 product.
To me, the key difference is that there would (should) be one product manager throughout the entire product lifecycle -- or at least cohesive product management with proper transitions if multiple managers are involved over time. Handoffs would include an understanding of why the product was created/brought in in the first place, who the audience is, how it has evolved, and what alternatives have been considered at the time and since.
Any of us who have participated in a discussion about an enterprise system where the current owners have no knowledge of why a system was introduced or what has happened with it since understand how critical this continuity of knowledge is for unlocking the value of a product. "Starting over" just decimates product value -- even if the "tangible" product itself remains intact.
Note that this discussion is still relevant even in a "100% agile" organization. The enhancement and relaunch projects I mentioned in my example above might really be marketing and communications efforts to advertise value that has been added via the continuous delivery operation for the product. Even if you deliver code every day or every hour, you still want to have release events (as I discuss in my post here) and only have one shot at each one (we only do a "Fall 2019" release once, as an example); it's important to make every release count to build a strong brand -- which calls for high quality project (or program, if you prefer) management.
My thanks to James for a great question. Feel free to add to continue this conversation in the comments.