In a previous blog post I noted how the terms project and product are being confused in open source. However, it is agile methods, specifically Scrum, where it gets really bad. To recap: A project is a human undertaking to create an artifact. A project, by definition, has a start date and an end date. A product, in contrast, is an artifact (not an undertaking) that is born but typically has no planned end date. Most vendors, selling products to a market, hope they can do this forever.
The main use of “product” in Scrum is in the terms Product Owner, Product Backlog, and Product Vision. A product owner is a technical product manager, managing detail requirements of the artifact under development through a product backlog. The product vision is an abstract time-less vision of what the results of the work will do for a customer, a market, or humanity—whoever is the target user of the planned artifact.
The confusion probably arises from the creators of agile methods almost all being consultants, earning their keep in projects. That is, they work(ed) for consulting firms. Consulting firms perform custom projects for specific clients. They are one of the two dominant types of companies in the software industry.
The other type of company is the software vendor, which develops products for a market (rather than projects for a client). Thus, only for a software vendor can the terms product owner, product backlog, and product vision be correct. For a consulting firm, the terms project owner, project backlog, and project vision would be more appropriate (ignoring the added confusion about “owner” and “vision”).
Now, Scrum works both for consulting firms and product vendors, so we probably don’t want two terminologies but one. Artifact owner, artifact backlog, and artifact vision may be appropriate, though I suspect that for some the term artifact may be too artifactual, pardon, too artificial 😉
In any case, this little blog post is unlikely to fundamentally change anything, so we are stuck with the existing terminology and the best we can do is to move into uncharted territory and change course by pulling ahead.
Next up, a simple example of how to do that: Scrum’s product vision vs. a project mission.
Leave a Reply