The Customer-Vendor Anti-Pattern
One of the four main propositions of the Manifesto for Agile Software Development is “Customer collaboration over contract negotiation”. And then one principle behind the manifesto say: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This notion of the customer unfortunately often leads to what Jeff Patton calls the customer-vendor anti-pattern. Especially in large organizations with their own IT departments, this pattern occurs when the Product Owner understands his role as a representative of internal customers and submits requirements to the Development Team for implementation. Understanding customers and their needs is important, but it is only one aspect to make a product successful and exactly that is the task of the product owner. In order to cover all aspects, the Product Owner must not be an ingenious and lonesome decision-maker and not be unilaterally associated with the business, but rather the leader of a team of experts who together take responsibility for the sustainable development of a successful product.
In his talk at MTP Engage 2018 in Hamburg Jeff Patton (as always brilliantly illustrated by his live drawings and enriched with stories from his many years of experience) explains this customer-vendor anti-pattern. In essence, this pattern is characterized by a clear separation between the customer who wants something and the vendor who is to deliver it within the agreed parameters of cost, time and quality. This pattern leads to a lot of energy flowing into the agreement and negotiation and, in case of problems, into the search for the culprit. Instead taking joint responsibility for the best possible next steps towards product success, this pattern causes a chasm between the customer, who determines what is to be done and the vendor, who determines how and with what it is implemented.
Jeff Patton also emphasizes that exactly this pattern, which is found in a similar way in many organizations between business on the one hand and IT on the other, has led to the Manifesto for Agile Software Development. This is precisely why the principles state that technical experts and developers must work together on a daily basis. However, although more and more organizations are turning to agile methods and especially Scrum, this pattern persists. The reason for this is the prevailing organizational separation of business and IT, which leads directly to the Product Owner being seen as a representative of the business side and the IT then providing the Development Team and the Scrum Master and delivering as ordered and agreed.
We see our customers as invited guests to a party, and we are the hosts. It’s our job every day to make every important aspect of the customer experience a little bit better.
Jeff Bezos
However, the Product Owner’s job is in fact to make the product successful. Following Marty Cagan, Jeff Patton defines “successful” as the intersection between the aspects valuable, useful and feasible. “Valuable” denotes the connection to the business model and strategy of the surrounding organization, which the Product Owner must understand in order to correctly prioritize the possible value contributions of the product. “Useful” means that the product provides value to the user. The Product Owner must therefore also and especially know the users and their needs. And finally, “feasible” means for the Product Owner to understand the many technical, organizational and other constraints that limit the potential solutions. And this includes technical debt, IT security, performance, scaling and many other technical aspects.
A good product manager is the CEO of the product. A good product manager takes full responsibility and measures themselves in terms of the success of the product. They are responsible for right product/right time and all that entails. Bad product managers have lots of excuses.
Ben Horowitz
In order to cover all these aspects, this anti-pattern of a customer-vendor relationship must be abandoned. The product owner may no longer feel like a customer (who does not care about the technological constraints and who only wants as much as possible as early as possible) and the development team must not feel as a vendor (who is annoyed by poorly specified requirements and constant changes). Instead, the Product Owner takes responsibility for the success of the product in all three aspects: “valuable”, “useful” and “feasible”. This requires the Product Owner to have the ability to collaborate and lead a product team because he will need experts for all these aspects in order to find compromises and make decisions jointly.
Originally published at fuehrung-erfahren.de on June 22, 2018.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 338,320+ people.
Subscribe to receive our top stories here.
