Customers, suppliers and fences

In my previous post, I contrasted two different terms for thinking about how people interact with your organisation – Customer Experience (CX) and User Experience (UX).  Rebecca Brown (a CX expert I mentioned in the post) kindly explained her view of CX to me, which got me thinking of some quality and process things that I think are related.

In this article, I will try to describe Rebecca’s view of the analysis that CX represents – at least, as far as I understand it, and then go on to the quality and process things that it inspired.

Customer Experience Analysis

In the world of CX, when you look at all the people that interact with your organisation, you classify them as either:

1. A supplier;
2. A customer.

If they’re not a supplier, then they are a customer.  So, if you provide goods or services to someone, they’re a customer.  This is regardless of who makes decisions, who pays for things or who uses things.

In the case of the business software example in my previous post, there would be three different kinds of customer and you provide different things to each:

1. The decision maker – how do you help someone to decide to use your stuff?  Are there trial versions, case studies or other documentation on your website etc?
2. The payer – how easy is it to pay?  What payment terms do you offer and how clear are they?  What payment methods or currencies do you accept etc?
3. The user – how easy is it to use your stuff?  How well does it get the job done etc?

If you divide everyone in the world up into suppliers or customers like this, then the term Customer Experience makes sense.  I suggest that anyone who isn’t a supplier isn’t the most common interpretation of customer, so while CX is a valid term and a helpful kind of analysis, I think that my comments on Customer Experience c.f. User Experience in the previous post still stand.

Customers, suppliers and quality

This division of the world into customers and suppliers reminds me of a big quality overhaul project that my Dad was part of.  It was for a large factory that made photographic film and paper.  This involved a process of many steps, big expensive machinery, large amounts of raw materials and so on.

As part of the project, each person was asked to think of who their suppliers were and who their customers were.  For some people, one or both of these questions would be easy.  Their customer might be the wholesaler who bought the finished film, or their supplier might be the company that made the light-sensitive chemicals or untreated paper that made up the photographic paper.  I.e. this would be for people at the very start or end of the process.

However, most people would be somewhere in the middle of the process.  They were at stage X in the process, and took the output of stage X-1, did something to it, and then passed it on to stage X+1 to continue the work.  They didn’t deal with anyone outside the company.

A simple encouragement to think of the customer (so that you change your behaviour in some way) is hard when the customer is so far away from you that you would need a telescope to see them.  However, if you think of your colleagues at stage X-1 as your suppliers, and your colleagues at stage X+1 as your customers, it becomes much easier to think about them – they’re the people you bump into in the kitchen.

As part of this, if you realise that at the same time as you have customers and suppliers, you are also a supplier (to stage X+1) and a customer (of stage X-1).  Therefore, it’s easier to have empathy with and understanding of your suppliers and customers.  Because you know how irritating it is when you receive an input late, you’re more likely to avoid being late with your outputs, because they’re inputs to your customers.  Similarly, because you know how irritating it is if your customer and you disagree on what it is you’re supposed to be delivering, you make sure that your supplier and you agree on what they’re supposed to be delivering.

Customers and suppliers on the software production line

I think that many programmers would do well to remember to view their testing colleagues as their customers, and not as adversaries or judges.  If nothing else, good testers are often a surrogate for the end user, and so constructive feedback from testers will help you to do a good job by your end users.

Also, while I don’t think it’s productive for programmers to do all the testers’ job for them, they should do some testing – where it’s most cost-effective for them to do so.  Unit testing is an obvious example, but also sanity testing.  Does everything compile?  Does it even start?  Can you kick the code’s tyres?  E.g. navigate to each major section of a website?

It usually doesn’t take too long to do this level of testing.  The alternative is costlier, because the overhead associated with work coming back from testing to development, and the mental context switching back by the programmer are extra costs that you’d avoid by doing it right first time.

Done?

The first thing I do when I start a new bit of work is:

1. Pull down the latest version of the source code
2. Do a local build from scratch
3. Run all the unit tests

Most of the time this just runs in the background while I get my head around the new bit of work, and so it takes little extra time.  I’m checking that my programmer colleagues and a previous version of me haven’t handed off the code and tests in a poor state, before I confuse things by making changes of my own.

Before I consider that my work is done, I do another build from scratch and run all the unit tests, having also done local system tests of my changes.  I don’t want to break the build, or hand over code for system testing that won’t even start.

If you’re aware of agile software development, this talk of customers and suppliers should be familiar, even though it might not be identical to your everyday experience.  The Definition of Done is effectively a contract between supplier and customer, where work is handed off from one stage in a process to another.

In my experience of agile, process things like Definition of Done are prominent, and internal customer / supplier relationships are much less so.  Customers are mentioned, but they usually refer to end users.  I realise that, done badly, thinking of internal customer / supplier relationships can push things towards bureaucracy to an unhelpful degree.

But agile can be done badly too – there can be an all-important and unchanging One True Version of Agile, and things can be agile in name only.  So, if you are tempted to grumble about agile admin things, I suggest you re-cast them in terms of customer / supplier relationships to see if that helps you see them in a new light.

Fences

The conversation I mentioned above between people at adjacent steps in a process reminds me of the saying:

Good fences make good neighbours

I think it has several meanings, but in this context there’s one meaning that I find particularly relevant.  If you imagine the two phases of a process being represented as neighbouring houses, each with a garden, then there will be some kind of boundary or fence between them.

Is there a dispute such that the people on side A of the fence think that the people on side B have moved the fence to expand the garden belonging to B by gobbling up some of the garden belonging to A?  Or is there a no man’s land of brambles and abandoned shopping trolleys between the two gardens, that neither side wants to claim responsibility for?

Or are the neighbours in a happier and healthier state where they agree on where the fence should be, and are both happy about it?  In fact, it’s probably at the stage where they don’t even think about the position of the fence at all, and just get on with more important stuff.  I guess the meaning I’m driving at here is along the lines of “fences in good positions make good neighbours”.

Having clear responsibilities that everyone agrees on and is OK with make for more productive organisations.  No tasks left abandoned because no-one wants them or everyone thinks it’s someone else’s problem.  No resentment when group A thinks that group B is on its turf.

That’s not to say I think there should be rigid lines that keep jobsworths apart – the boundaries should move when it makes sense to move them.  But I think that it’s helpful to have a default position for a boundary, that everyone knows and everyone agrees on.

Summing up

It can give useful context and motivation to your work to consider the people who will use it or be affected by it in some way.  Whether you call these people customers or users doesn’t matter as much as remembering to consider them.  These people can be outside your organisation, or your colleagues.  You are likely to be both supplier and customer at the same time (to different people), which can help with understanding and empathy.

Agile software development has supplier / customer relationships encoded in its Definitions of Done, even though these (internal) relationships aren’t always obvious.  Bringing the relationships up to the surface every so often can be a helpful reminder of the value of things and what’s important.