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!

Why continuous delivery needs devops, and why devops needs infrastructure-as-code

Update 02-Apr-13
Just came across this detailed relevant talk by Reinertsen - the author I reference for silo reduction and batch size reduction.


http://www.infoq.com/presentations/lean-product-dev
===============================================

Update 26-Oct-12

Slides, with notes
=========================

I'll present on this topic on 25th October 2012 as part of a ThoughtWorks Studios webinar series on continuous delivery. Please register from the webinar page.

Abstract
Continuous delivery and devops have gone mainstream, at least in terms of mindshare. As a result, a lot of vendors have jumped onto the bandwagon. Most products that have anything to do with deployment now try to associate themselves with devops and continuous delivery. In this webinar, Sriram will try to clear the air in a product independent manner. He will also cover common devops anti-patterns and explain the idea of infrastructure as code.

The economics of aesthetics

Many will argue that it is just plain wrong to subject aesthetics to cost and benefit, at least until a certain threshold. Someone said, “An economist is someone who knows the price of everything and the value of nothing.”

But this is the reality of business. A product or service can be made just useful or it can be made useful and beautiful. As consumers, we frequently choose from varying degrees of form and function. However, things get more interesting in a B2B situation.

Clients agree to foot the bill for aesthetics to the extent it promises to help their topline. Funds are made available for aesthetics on a public facing website. The belt is tightened for an internal facing application. Vendors use the same logic. They spend money to make sure that their presentations are not only substantial but also aesthetic enough to impress clients.

What about the people who write code? They also have a sense of aesthetics. Their bosses don’t grudge them the inexpensive effects – standard tools that can ensure uniform indentation, nice fonts and syntax highlighting. But higher order aesthetics are a different matter altogether.

I mean lucid, performant code, fluent interfaces, pithy names, succinct tests and coherent classes residing in cohesive modules loosely coupled with their neighbours.

“Don’t just call these aesthetics”, I hear the indignant coders say.

“They confer vitality, suppleness, and longevity to the codebase.”

There is truth and perhaps some irony to this claim. Unfortunately, even the truth is appreciated largely only by the coding intelligentsia. As a result, efforts to secure these higher order aesthetics go unchallenged only as long as the development team stays on track for budget and schedule. As Stewart Brand said, form follows funding.

But estimates being estimates and competitive bids being competitive bids, there is many a slip between the cup and the lip. Screws get tightened,

“Enough gold plating already.”

Some will contend that effective visualization of internal software quality will bring about the necessary loosening of purse strings. Well, only occasionally. For one, a common (and sometimes legitimate) reaction is,

“Why did you incur technical debt in the first place? That’s not why I hired expensive consultants like you.”

But first, there is the question what makes for effective visualization. Should we show a tangled ball of wool versus a neatly wound ball in order to contrast the current cyclomatic complexity with desired state? Should we progressively untangle the ball in progress reports? Is it not enough to state in text that the industry standard is about 20 per 100 hundred lines of code and that we are currently at 45?

Should we depict a slummy urban sprawl for a monolithic codebase and gradually introduce suburbia with zoning as we modularize? Is it not enough to show a dependency structure matrix?

How accessible does a visual need to be before a non-technical/post-technical decision maker gets it? One kind of visual targets the recipient’s analytical faculty. Another kind targets their aesthetic faculty. Aesthetics are in vogue among consumer devices. I suspect this has spilt over to the kind of visuals favoured by IT decision makers.

They very people who scrutinize spend on aesthetics through the lens of the topline lean towards aesthetics when they ask their sub-ordinates and vendors to send them reports and presentations.