When the implementation of a project becomes the product
Training and coaching in an agile approach focus very much on the processes in product development teams and often less on the entire company and its products. In software development, therefore, especially CI and CD, the implicit testing during development and the tools that support it. In short: the focus is on product delivery.
In teams that implement a project for an end customer, it may already be done, because there are only the requirements of one customer and their implementation is the goal that is being worked towards. The questioning of the requirements and thus the influence on the client with regard to an adaptation, or at least reprioritisation of the same, is not in the focus and may be, in the sense of the service idea, often even undesirable true to the motto
The customer says we should jump, then we just ask how high.
The product discovery, or to put it more bluntly, the product management, is completely missing. This discipline is simply not relevant in “implementation projects” for a paying customer or is solely on the side of the client. The product of the development team is therefore in reality the service of implementing requirements and not a product in the classical sense.
Anyone who learns the role of the Scrum Product Owner in such an “implementation context” therefore runs the risk of seeing themselves as a backlog administrator and reducing themselves to a feature owner or delivery owner. The idea is that a product owner is dictated the feature and only has to pass it on to his development team as a translator and communicator.
Here’s an excellent article by Jeff Patton, author of “User Story Mapping” on this topic: “The Mindset That Kills Product Thinking”