Experience Chain Management

You heard about it here first, folks. I've just created a new discipline: Experience Chain Management.

It was fueled mostly by some reading I did of Lou Carbone's writing, in his book Clued In: How to Keep Customers Coming Back Again and Again.

The core of it is that every business is trying to create a valuable customer experience to keep the money coming in the door. However, nobody thinks about the internal consumers of the business processes that deliver those experiences to the paying customers. Someone upstream can sabotage the effectiveness of the downstream team members and, without even realizing it, impair the customer experience.

Simple example that I'm periodically wrestling with:

• Developer publishes a code change past the start of the testing cycle
• The QA engineer doesn't regress that part of the code because they don't know about the change
• A bad bug slips through to production
• A customer can't get what they want done, and gets angry instead

I'm thinking that there are probably some lessons to be learned from all of the work done on supply chain management. Even though you're shuffling bits instead of atoms, when you have a team turning out software that drives a customer experience, it's still an awful lot like manufacturing. You have:

• raw materials (product ideas)
• manufacturing (coding)
• assembly & testing (build, configure, QA)
• delivery (deployment & operations)

Of course, the thing I need to think about more is how downstream components and processes can block or impair the productivity of upstream partners. For that, you need to look at a different discipline (see next post).