The Customer-Vendor Anti-Pattern

One of the four main propo­si­tions of the Man­i­festo for Agile Soft­ware Devel­op­ment is “Cus­tomer col­lab­o­ra­tion over con­tract nego­ti­a­tion”. And then one prin­ci­ple behind the man­i­festo say: “Our high­est pri­or­i­ty is to sat­is­fy the cus­tomer through ear­ly and con­tin­u­ous deliv­ery of valu­able soft­ware.” This notion of the cus­tomer unfor­tu­nate­ly often leads to what Jeff Pat­ton calls the cus­tomer-ven­dor anti-pat­tern. Espe­cial­ly in large orga­ni­za­tions with their own IT depart­ments, this pat­tern occurs when the Prod­uct Own­er under­stands his role as a rep­re­sen­ta­tive of inter­nal cus­tomers and sub­mits require­ments to the Devel­op­ment Team for imple­men­ta­tion. Under­stand­ing cus­tomers and their needs is impor­tant, but it is only one aspect to make a prod­uct suc­cess­ful and exact­ly that is the task of the prod­uct own­er. In order to cov­er all aspects, the Prod­uct Own­er must not be an inge­nious and lone­some deci­sion-mak­er and not be uni­lat­er­al­ly asso­ci­at­ed with the busi­ness, but rather the leader of a team of experts who togeth­er take respon­si­bil­i­ty for the sus­tain­able devel­op­ment of a suc­cess­ful product.

In his talk at MTP Engage 2018 in Ham­burg Jeff Pat­ton (as always bril­liant­ly illus­trat­ed by his live draw­ings and enriched with sto­ries from his many years of expe­ri­ence) explains this cus­tomer-ven­dor anti-pat­tern. In essence, this pat­tern is char­ac­ter­ized by a clear sep­a­ra­tion between the cus­tomer who wants some­thing and the ven­dor who is to deliv­er it with­in the agreed para­me­ters of cost, time and qual­i­ty. This pat­tern leads to a lot of ener­gy flow­ing into the agree­ment and nego­ti­a­tion and, in case of prob­lems, into the search for the cul­prit. Instead tak­ing joint respon­si­bil­i­ty for the best pos­si­ble next steps towards prod­uct suc­cess, this pat­tern caus­es a chasm between the cus­tomer, who deter­mines what is to be done and the ven­dor, who deter­mines how and with what it is implemented. 

Jeff Pat­ton also empha­sizes that exact­ly this pat­tern, which is found in a sim­i­lar way in many orga­ni­za­tions between busi­ness on the one hand and IT on the oth­er, has led to the Man­i­festo for Agile Soft­ware Devel­op­ment. This is pre­cise­ly why the prin­ci­ples state that tech­ni­cal experts and devel­op­ers must work togeth­er on a dai­ly basis. How­ev­er, although more and more orga­ni­za­tions are turn­ing to agile meth­ods and espe­cial­ly Scrum, this pat­tern per­sists. The rea­son for this is the pre­vail­ing orga­ni­za­tion­al sep­a­ra­tion of busi­ness and IT, which leads direct­ly to the Prod­uct Own­er being seen as a rep­re­sen­ta­tive of the busi­ness side and the IT then pro­vid­ing the Devel­op­ment Team and the Scrum Mas­ter and deliv­er­ing as ordered and agreed.

We see our cus­tomers as invit­ed guests to a par­ty, and we are the hosts. It’s our job every day to make every impor­tant aspect of the cus­tomer expe­ri­ence a lit­tle bit better.
Jeff Bezos

How­ev­er, the Prod­uct Own­er’s job is in fact to make the prod­uct suc­cess­ful. Fol­low­ing Mar­ty Cagan, Jeff Pat­ton defines “suc­cess­ful” as the inter­sec­tion between the aspects valu­able, use­ful and fea­si­ble. “Valu­able” denotes the con­nec­tion to the busi­ness mod­el and strat­e­gy of the sur­round­ing orga­ni­za­tion, which the Prod­uct Own­er must under­stand in order to cor­rect­ly pri­or­i­tize the pos­si­ble val­ue con­tri­bu­tions of the prod­uct. “Use­ful” means that the prod­uct pro­vides val­ue to the user. The Prod­uct Own­er must there­fore also and espe­cial­ly know the users and their needs. And final­ly, “fea­si­ble” means for the Prod­uct Own­er to under­stand the many tech­ni­cal, orga­ni­za­tion­al and oth­er con­straints that lim­it the poten­tial solu­tions. And this includes tech­ni­cal debt, IT secu­ri­ty, per­for­mance, scal­ing and many oth­er tech­ni­cal aspects.

A good prod­uct man­ag­er is the CEO of the prod­uct. A good prod­uct man­ag­er takes full respon­si­bil­i­ty and mea­sures them­selves in terms of the suc­cess of the prod­uct. They are respon­si­ble for right product/right time and all that entails. Bad prod­uct man­agers have lots of excuses.
Ben Horowitz

In order to cov­er all these aspects, this anti-pat­tern of a cus­tomer-ven­dor rela­tion­ship must be aban­doned. The prod­uct own­er may no longer feel like a cus­tomer (who does not care about the tech­no­log­i­cal con­straints and who only wants as much as pos­si­ble as ear­ly as pos­si­ble) and the devel­op­ment team must not feel as a ven­dor (who is annoyed by poor­ly spec­i­fied require­ments and con­stant changes). Instead, the Prod­uct Own­er takes respon­si­bil­i­ty for the suc­cess of the prod­uct in all three aspects: “valu­able”, “use­ful” and “fea­si­ble”. This requires the Prod­uct Own­er to have the abil­i­ty to col­lab­o­rate and lead a prod­uct team because he will need experts for all these aspects in order to find com­pro­mis­es and make deci­sions jointly.

Share This Post

By Marcus Raitner

Hi, I'm Marcus. I'm convinced that elephants can dance. Therefore, I accompany organizations on their way towards a more agile way of working. Since 2010 I regularly write about leadership, digitization, new work, agility, and much more in this blog. More about me.

Leave a Reply