The Productivity Trilemma 2: A Second Response to Maciek

In response to the post on The Productivity Trilemma, Maciek went replied with another, focusing on Productivity, Niches, and Aesthetes.

Maciek’s first point – that most people associate gains in productivity as a deliberately cheapening of the inputs, resulting in a crappy, cheap output, is quite apt. Any trip to a big box retail outlet will confirm that link for you. And that sort of productivity gain is just fine if you’re in a race to the bottom.

The implicit assumption running through Maciek’s post, I’m happy to say, is a race to the top. How does one go about producing artisan products, of high quality, for niche markets, in a manner that is highly productive? This culminates in the passage:

Moving forward, we are transitioning to an age of niche products and services that can’t hope to attain gigantic followings and easy economies of scale. Seth Godin would suggest that every tribe of 1000 customers is the key to another 1000, and so on, but what if a product only will ever appeal to a small number of people? What if all products worth having a knowledge economy salary for are niche products? What if we shrink that number even further?

I think you can shrink the number down even furthur.

Frequent readers of this blog can watch the struggle. The Economics of Analytics I, II, and III were all struggles to clearly enunciate why I think so many client-agent relationships struggle along, especially when it comes to Niche Services, or ultra Niche Services – services that may only have 10 clients in the world. For instance, I could invisage a service whose only customers would be major web analytics vendors – of which there are no more than 10 who are ‘majors’. Those types of services could be incredibly niche.

What about mass market products?

Consider Starbucks. I think I read somewhere that customers can create 10 billion different combinations of products through their requests. (Or something like that). At Subway, you have a similar array of choices. Of course, both businesses start off with a base product – for Starbucks, it’s just about making hot water taste like something. At Subway, it’s about adding stuff on top of bread (and during the Atkins boom, low carb ‘wraps’). These companies are, at least at the franchise level, ‘productive’ on some level. They’re also Just In Time (JIT) in other respects. And they produce very niche products for their customers.

I’d argue that a lot of software development, a lot in software engineering, has been all about how to make a Subway sandwich without fail. Except the Bread is a framework of documentation. I know I’ll get into trouble for comparing the two processes – but I think they’re striving for the same thing. A repeatable process that results in a highly customized output without fail. Regardless of Subway’s label of ‘Sandwich Artist’, they’re not actually Artists. The Client is mostly in control of the entire process.

Indeed – it’s very difficult to assemble a piece of software in the same way that a Sandwich is assembled. Imagine that you’re the client, not the Artist, and you don’t know what Onions taste like. But you see that purple, and you want it. The Artist says, ‘alright’, and puts them on. Then, when you’re cramming that sub down your word hole, you taste your first onion, and proclaim, loudly, that this isn’t what you ordered. The Artist, having just completed his degree in aviation security policy, is bright enough to quip that “It’s exactly what you ordered, it just isn’t what you expected“.

So, to Maciek’s point – when you exist in a sector where what you do by definition is not commodified, expectations will be skewed. Expectations are especially skewed when the agent doesn’t know enough to set expectations, or to communicate clearly what the end result will, and will not, do.

This leads to client-agent innefficiencies, and ultimately, a high degree of waste.

Enter design patterns and competitive advantage through efficiency and brilliant client experience design?