Customers, Users and Losers

or...Who is the Product?

It is a common beginner mistake to consider customers and users to be the same. A little reflection soon reveals that not only are they different, their interests may not even be aligned! Let's see some examples.

Example	Vendor	Product	Customer	User	Customer-User Interest Alignment
Dining at a restaurant	Restaurant	Dining experience	The host	All diners	Good
Drawing class	Independent art teacher	Drawing lessons	Parent	Child	Good
Commercial Software License	ISV	Some software	Evaluator, Decision Maker, Procurement Person	Actual users	Fair
AWS	Amazon	IaaS	Cloud buyer	Developers	Good
Gmail	Google	Email	Advertiser	We	Poor
Facebook	Facebook	Social network	Advertiser	We	Poor
Twitter	Twitter	Microblogging network	Advertiser	We	Poor

But that doesn’t make sense. Why would Google, Facebook and Twitter create products that generate a conflict of interest between customer and user? They don’t. We’ve got the wrong picture. The product isn’t what we think it is. Here is the real deal: 
 

Example		Vendor		Product		Customer	User			Customer-User Interest Alignment
Gmail	Google		We		Advertiser			Ad platform users	Good
Facebook	Facebook		We		Advertiser			Ad platform users	Good
Twitter	Twitter		We		Advertiser			Ad platform users	Good

We are the product that is probed, segmented, analyzed and sold to the highest bidder. What we experience as the product (email, social network etc) is merely the farm meant to rear the real product – us. This is the sad inescapable reality of any business that chooses advertising instead of subscriptions as its revenue model.

Organizing for continuous delivery: redefining the role of a functional specialist lead

Power struggles are bad for business. Organization design should try to minimize power struggles. One way to do so is to have one power center per business outcome. Let’s say the business outcome is the success of a software product. We put one person in charge - say we call her the product manager. We make this person accountable for product leadership (quality, innovation, relevance), market leadership (revenue, mindshare) and customer satisfaction (support, training).

We don’t want to create multiple power centers in the form of specialist leads e.g VP of sales, head of marketing, director of engineering etc. in addition to the product manager. Yes, we need leadership in multiple specializations but that’s more about autonomy (influence) than about authority (power). As this pithy HBR post points out:

Managers create circles of power while leaders create circles of influence.

This ties in well with what I said at devopsdays Berlin in May this year. Continuous delivery needs cross-functional teams. But a matrix org with many functional specialist heads has too much potential for territorial power struggles to deliver effective cross functional teams. On the other hand, subordinating all functional specialist leads to the product manager robs them of their autonomy (and motivation). 
I suggest that we let the functional specialist leads retain autonomy but take away their authority (control over resources). Have specialist leaders by all means. Make sure they sit on the same level in the org hierarchy as product managers. But let the hierarchy be one of power/influence rather than just power. The product managers control resources - team and budget. It is an unconventional set up - one that tries to retain the autonomy/influencer attributes of specialist leads without the risk of devolution into non-collaborative, empire building behaviors.

Mere uniformity does not make for consistency

We often play the consistency card in the support of an argument.

I want this UI (form) to be laid out this way for the sake of consistency.

or

Let's be consistent and use the corporate presentation template.

or

I can't make an exception for you in case of this policy. We'll have to be consistent.

Used as above, consistency is an inappropriate substitute for uniformity. To check, ask "consistency with what?"

I want this UI (form) to be laid out this way for the sake of consistency.
    Consistency with what?
Consistency with the rest of the UI.
    You mean uniformity with the rest of the UI?
Isn't it the same thing?
    Well, laying it out this other way is consistent with the aim of keeping
    the user from making an incorrect assumption about the feature.

Let us all be consistent and use the corporate presentation template.
    Consistent with what?
With corporate guidelines of course.
    Guidelines don't demand uniformity. We could use our own templates as long as they are consistent with the image we want to portray as a company.
   
I can't make an exception for you in case of this policy. We'll have to be consistent.
    Consistent with what?
Consistent with the application of this policy.
    You mean you want to uniformly enforce the letter of the policy on everyone?
Well we certainly don't want to encourage exceptions.
    It seems you have already concluded that my case is an exception and one not worth granting.

Consistency is a higher order goal than mere uniformity. It requires some deliberation to decide if a certain course of action is consistent with broader objectives. On the other hand, uniformity is easily achieved by mechanical application of a rule book. This is what call center agents are trained to do. We know what the resulting user experience feels like. As Emerson said,

"A foolish consistency is the hobgoblin of little minds".

Why then, do we fall for this? Often, it is just laziness to listen and think. Sometimes (as in the case of call centers), it is side-effect of organisation design. Decision makers and policy makers sit on top of corporate hierarchies. They don't devolve discretionary powers to subordinates. The subordinates learn to function uniformly, without regard to context. They unconsciously cultivate a habit of using better sounding words like consistency to defend their actions. The makings of a classic bureaucracy!