Archive

Customers

Traders or Traitors

I’ve been listening to lots of audiobooks of late. Mostly narrated by folks with American accents. Current listening is Asimov’s Foundation Series (maybe for the fourth time around).

Aside: I find Zachary Quinto’s narrations of e.g. John Scalzi books just awesome.

trader
[ trey-der ]

noun

a person who trades; a merchant or businessperson.

traitor

noun

a person who betrays another, a cause, or any trust.

 

In an American accent, I find the words “trader” and “traitor” indistinguishable. Setting aside the question “are all traders traitors (to their customers)?” it got me to thinking “are all Agile traders traitors to their customers.” I’m pretty sure that – from the perspective of Agile Transformation outcomes – the answer is “yes”

How about you? Do you find that folks “delivering” Agile transformations are simple traders, or actually traitors to their customers and their customers’ cause?

– Bob

 

Automate All the Things!

Or not. I prefer not. 

As John Seddon states in his most recent book, it’s far more useful to fully understand customers’ needs, through e.g. simple physical means, like pin-boards, T-cards and spreadsheets, before considering any automation.

And even then, automation has at least two fundamental flaws:

Inability to Cater to Variation in Demand

Automation and automated systems, presently and for the foreseeable future, cannot encompass variety in demand. As we’ve come to relate to the Little Britain meme “ Computer says no”. Customer demand inherently has variation. Thus, automation leads to a poorer customer experience, as many customer needs are handled poorly, or not at all. I cite the British Gas website and customer experience as a particularly egregious example.

Employment 

Let’s also look at the bigger picture of social cohesion, of which people having jobs is a part. Jobs give people meaning, status, and something to do. As well as greasing the wheels of commerce – employed people have disposable income which contributes to companies’ revenues.

The idea of Basic Income is all very fine (I’m a fan) but that concept has some major wrinkles to iron out before it becomes a shoe-in.

In the meantime, how about we try to create businesses – and other organisations – that provide meaningful employment to more people, rather than fewer? Will that negatively impact profit margins? I doubt. And there’s always Deming’s First Theorem in any case.

More and more often, the Software Industry is being called upon to live up to its fine moral pronouncements. Automation is an item in the negative column on that balance sheet.

– Bob

Lost Business

At Familiar (1996-2000) we regularly “lost” work to other companies making lower bids than us. Like many suppliers we were initially both angry, frustrated and disappointed when this happened.

Over time, we studied the phenomenon, saw a pattern emerge, and came to understand these scenarios.

Years later, I wrote a blog post – The Inductive Deductive Schism – explaining the phenomenon of clients commissioning software development work with suppliers who were clearly going to screw up and cost the client much more over the full duration of the commission.

The Schism Summarised

In summary, non-technical, non-engineering clients approach decision-making – i.e. who to commission – in entirely the reverse order to how technical, engineering people might approach the same decision. The follow chart illustrates the order in which clients might approach the question:

 

Note how trust (actually credibility of the supplier) takes first place, followed by solution fit, and then details of the solution. “Will the proposed solution work?” comes a poor fourth.

Compare with the approach favoured by “technical” people:

Here, the viability of the proposed solution takes first place, and “trust” a.k.a. credibility of the supplier comes fourth.

Bottom Line

So we see that technical suppliers who fail to understand the decision order of their prospective (non-technical) clients will inevitable fail to understand why the commissions go to suppliers who appear inept and likely to produce inappropriate and/or non-viable solutions.

If you’re a “technical” supplier pitching for business with non-technical clients, you might like to focus on your credibility, followed by the “fit” of your proposed solution to the client’s needs – and downplay the details and viability of your proposed solution.

– Bob

Better Antimatter Customers

[Some years ago I wrote a post entitled “Better Customers“. This is an update of that post, reframed using the AntimatterPrinciple]

More effective organisations need better Folks That Matter™. Where “better” means more demanding discerning. Less gullible.

Folks that demand their needs are met, or as a minimum, attended-to, not tech, nor features, nor hand-wavy “value”.

Folks that refuse to pay when their needs are ignored, met poorly, or not addressed at all.

Folks that hold a healthy skepticism for unevidenced claims and promises.

Folks that disrupt the cosy hegemony of the technologists (see e.g. #NoSoftware).

Folks that push back against complex and expensive non-solutions.

Folks that push through the embarrassment of failure to call suppliers to account.

Folks that understand THEIR Folks That Matter™, and look for partners that want to help them in that.

Folks who see the value in relationships, trust, and evidence, whilst rejecting faith-based arguments.

Folks that buy on criteria other than lowest (ticket) price (cost being just one need amongst many).

Folks that embrace the human element and humane relationships in the world of business.

Folks that understand their own strengths – and their weaknesses, and act accordingly.

Folks that generously share the laurels of success, and share responsibility for failure too.

There are so many folks that feel a need to do better, but desperately need the support of their Folks That Matter™ to make that happen. Without better Folks That Matter™, the reforms and improvements we need will indeed take a long time in coming.

– Bob

 

What Is A Customer?

In the world of Agile, and the world of business too, we hear a lot about “customer value”. Folks seem to have some kind of handle on “value” (although not everyone can agree on that one – see my post “What Is Value” for my take, based on Goldratt and his Theory of Constraints).

And for the record, we might also choose to frame the question of value within the Antimatter Principle frame, and vocabulary:

Value: The degree to which folks’ needs, in aggregate, are being (or have been) met.

But what about “customer”? So simple and straightforward. Do we even need to define it? I thought not, until a recent conversation on Twitter gave me pause for reconsidering. Specifically, the idea that maybe folks are talking at major cross-purposes, with significantly differing assumptions and definitions for the term. If we can’t agree on a basic term like “customer”, what chance alignment of a whole host of fundamental questions about software, products and business generally?

Here’s my definition, again using the Antimatter Principle as a frame:

Customer: Someone (could be either a person, or a collection of people) whose needs we’re attending to.

I’m pretty sure you’ll have a different definition of customer. I’d love to hear your take.

Before I close this post, here’s a different definition, informed by Crosby and his Zero-Defects (ZeeDee) approach to quality:

Customer: Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else.

This definition canonises Crosby’s idea that we’re all customers. And we’re all suppliers, too. And as suppliers, it falls to us to ensure that what we’re supplying is what our immediate customer needs to supply their customer(s).

– Bob

%d bloggers like this: