Disruptive Decency

Well, this turned out to be very much a different post than what I’d first thought.

Last Thursday, CIO published an article titled “Your Pebble smartwatch will live on when Pebble’s servers shut down” that had good news for owners of the Pebble smartwatch:

But now that Pebble has been acquired by Fitbit and is presumably nearing the end of its life, Pebble users fretted that their watches would cease to work once Pebble dies. That’s not the case.

Pebble just rolled out an iOS and Android update that frees its watches from cloud-based online servers. That means when Pebble goes offline, your watch will still work.

Coincidentally, this was one year to the day since I posted “Google’s Parent Company is Stirring Up a Hornet’s Nest”, which talked about Nest’s decision to brick the Revolv home automation hub rather than continue to support them. Fitbit’s decision was a refreshing departure from the attitude demonstrated by Nest (and lampooned by xkcd above). The punchline was going to be: basic human decency seems to be a disruptive tactic these days.

And then I launched Twitter Monday morning:

@United overbook #flight3411 and decided to force random passengers off the plane. Here's how they did it: pic.twitter.com/QfefM8X2cW

— Jayse D. Anspach (@JayseDavid) April 10, 2017

By this point, I would assume Sunday night’s, incident needs no explanation on my part. Details are still coming out, but regardless of what develops, United Airlines is the loser in this scenario. There’s an old saying is that there’s no such thing as bad publicity.

The old saying is wrong:

United Airlines is pleased to announce new seating on all domestic flights- in addition to United First and Economy Plus we introduce.... pic.twitter.com/KQjPClU2d2

— McNeil (@Reflog_18) April 10, 2017

The tweet above has plenty of company in the twitterverse, none of it flattering to United or beneficial to its share price. Tweets like this haven’t helped:

United CEO response to United Express Flight 3411. pic.twitter.com/rF5gNIvVd0

— United Airlines (@united) April 10, 2017

The perception that sticks is that an older man, a doctor, was violently removed from a plane in order to allow United to get four of its flight crew to Louisville and United’s CEO is upset about having to “…re-accommodate these customers” (not exactly what’s said, but certainly what will be taken away from that garbled message). Additionally, the poor job done on that earlier message completely undercuts the perceived sincerity of the latter one:

United CEO Oscar Munoz: I’m sorry. We will fix this. https://t.co/v8EPGsiDCi pic.twitter.com/eOPiYcagvo

— United Airlines (@united) April 11, 2017

Given United’s past problems with customer service, one might expect more effort would have been spent to prevent incidents like this and they would have been better prepared for dealing with the aftermath of something that did go badly.

Wrong on both counts.

An excerpt from a recent interview of Oscar Munoz (United’s CEO) on Business Insider makes the situation all the more egregious:

Here, in Chicago, it’s miserable because if you don’t leave by a certain time, you are just dead. “I’m going to get there and there are going to be a billion people and the damn TSA line.” By the time you get to sit on one of our seats you are just pissed at the world.

So how do we make all of that a little bit easier? This is the thing. You’ve got that broad issue of anger and anti-industry noise. We’ve lost the trust and respect of the broader public, and so every action we take, they don’t particularly like, they see it negatively. We have to work on that broad communication. I am going to do it at this airline and allow myself to differentiate in the flight-friendly mode so that people don’t immediately have that visceral reaction.

Dragging people off a flight (literally) probably doesn’t fit into the mold of a “flight-friendly mode”.

So I will return to my original punch line: basic human decency seems to be a disruptive tactic these days.

Advertisement

What Customer-Centric Looks Like

My last post, “Defense Against the Dark Art of Disruption”, went into some detail about notable failures in customer-experience for 2016. This week, however, I ran across a counter-example (h/t to Tim Worstall) showing that a little social media awareness and a customer-centric culture can make magic:

A baby products company is launching a special run of ‘little blue cups’ for a 13-year-old boy with autism following a global appeal by his father.

Ben Carter, from Devon, will only drink from a blue Tommee Tippee cup, prompting father Marc to put out an appeal on social media after becoming concerned the cup was wearing out.

Ben would refuse drinks that were not in the cup and had been to hospital with severe dehydration.
His father, tweeting as @GrumpyCarer, prompted people across the world to look through their cupboards for identical cups or to spread the #cupforben message. His request was retweeted more than 12,000 times.

Tommee Tippee, based in Northumberland, said it was nearly 20 years since it had manufactured that product, but has now rediscovered the design and found the mould used to make the two-handled originals, stored in a usable condition in China.

It has said it will make a run of 500 cups to ensure ‘that Ben has a lifetime supply and that his family won’t ever have to worry about finding another cup’.

From “Father’s search for a sippy cup for his autistic son comes to an end”, Daily Mail 11/29/2016

 

While I don’t know what it cost them to find the molds and run a one-off batch of cups, I suspect that the value of the positive global media coverage should substantially offset it. As a father, I know that the gesture was priceless.

Win-win.

Defense Against the Dark Art of Disruption

My first post for 2016 was titled “Is 2016 the Year for Customer-Focused IT?”. The closing line was “If 2016 isn’t the year for customer-focused IT, I wonder just what kind of year it will be for IT?”.

I am so sorry for jinxing so many things for so many people. 🙂

So far, the year has brought us great moments in customer experience like:

• Google Mic Drop – an automated kiss-off for email (“you meant to hit that button, right?”)
• Google/Nest and the Resolv home automation hub – retiring a product by bricking it (“it’s just not working; it’s not you, it’s us”)
• Apple Music – cloud access to your music and freed-up disk space (“nice little music collection you have here, it’d be a shame if you quit paying for access to it”)
• Evernote’s downsizing – because when the free plan is good enough for too many people, taking away features is the way to get them to pay, right?

Apple, of course, probably won the prize with their “courageous” iPhone 7 rollout:

Using “courage” in such a way was basically a lethal combination of a giant middle finger mixed with a swift kick in the nuts, all wrapped in a seemingly tone-deaf soundbite. This is the kind of stuff critics dream about.

Because Schiller said exactly what he said, he left the company open to not only mockery, but also bolstered a common line of criticism that often gets leveled upon Apple: that they think they know best, and everyone else can hit the road. You can argue that this is a good mentality to have in some cases — the whole “faster horse” thing — but it’s not a savvy move for a company to say this so directly in such a manner.

Apple then continued it’s tradition of “courage” with the new MacBook Pro models.

So, is there a point to all this?

Beyond the obvious, “it’s my site and I’ll snark if I want to”, there’s a very important point. Matt Ballantine captured it perfectly in his post, “Ripe for Disruption”: “You’re less likely to be disrupted if you are in sync with your customers’ view of your value proposition.” His definitive example:

I think that most of the classic cases of organisational extinction through disruption can be framed in this way: Kodak thought their value was in film and cameras. Their customers wanted to capture memories. Kodak missed digital (even though they kind of invented it).

The quote bears repeating with emphasis: “You’re less likely to be disrupted if you are in sync with your customers’ view of your value proposition.” What you think your value proposition is means a whole lot less than your customer’s perception of the value of what you’re delivering. This is a really good way to poison that perception:

https://twitter.com/jetpack/status/790931790961729536

Disappointment, betrayal (perception is reality here) are not conducive to a positive customer experience. Customer acquisition is important, but retention is far more important to gaining market share (h/t to Matt Collins). The key to retention is to relate to your customers; understand what they need, then provide that. Having them pay for what’s in your best interest, rather than theirs (hello Kodak), is a much harder sell.

Google’s Parent Company is Stirring Up a Hornet’s Nest

On May 15th, my house will stop working. My landscape lighting will stop turning on and off, my security lights will stop reacting to motion, and my home made vacation burglar deterrent will stop working. This is a conscious intentional decision by Google/Nest.

To be clear, they are not simply ceasing to support the product, rather they are advising customers that on May 15th a container of hummus will actually be infinitely more useful than the Revolv hub.

Google is intentionally bricking hardware that I own.

— Arlo Gilbert, “The time that Tony Fadell sold me a container of hummus.”

Google, even before it morphed into Alphabet, has a long history of killing of products. While this is annoying when the product is a free online service (yes, I still miss Reader), the impending demise of the Revolv home automation hub raises some interesting questions. Arlo Gilbert, CEO of Televera (which produces medical monitoring software), asked in the Medium article referenced above:

Which hardware will Google choose to intentionally brick next? If they stop supporting Android will they decide that the day after the last warranty expires that your phone will go dark? Is your Nexus device safe? What about your Nest fire/smoke alarm? What about your Dropcam? What about your Chromecast device? Will Google/Nest endanger your family at some point?
All of those devices have software and hardware that are inextricably linked. When does an expired warranty become a right to disable core device functionality?

According to an article on Business Insider, Nest bought Revolv a few months after being purchased by Google. Since the purchase was aimed at acquiring Revolv’s talent, Nest quit selling the $300 Revolv devices, but they did continue to support them. That, however, will end on May 15th according to a recent announcement.

Google’s choice “…to intentionally brick…” this product is important for several reasons. There may be some legal ramifications (as reported in Business Insider, the devices were advertised with a “lifetime subscription”). Gilbert’s question about what happens to the devices he listed should make people (consumers and producers) think.

I agree with Christina Warren’s assertion in her post on Mashable that it’s unrealistic to expect companies to support products forever, particularly where the hardware and its supporting software services have become very tightly coupled. However, producers need to consider the cost to their reputation/good will when they take actions like this. One option floated on Vox:

Of course, it might be a waste of resources for Nest to support a product that only a small number of people are using. But if there aren’t many users left, that means it wouldn’t cost Nest very much to compensate the few remaining users — either by refunding the purchase price or offering to send users a similar product. Instead, Nest appears to be simply leaving them out of luck.

Generating fear, uncertainty, and doubt (FUD) is an ethically questionable tactic when applied to your competitors’ products. When you generate FUD about your own products, then it’s your judgement that comes into question. One way to throw cold water on the excitement around the Internet of Things (IOT) is to unintentionally or cavalierly create that doubt in the minds of consumers. When you’re working on a really big IOT product, something like an autonomous car, do you really want people questioning your commitment to standing behind your products?

The Business of IT – Customers, Clients, and Fit for Purpose

Over the past few months, I have touched on a variety of what might seem to be disparate topics: the need for architects (or at least architectural design), estimates, organizations as systems/enterprise architecture, customer-centricity, and IT management and governance. I suspect the trend will continue for a while, so it’s time for a post to explicitly tie things together.

The concept of “organizations as systems” is the cornerstone. Software systems do not exist in isolation, but within a fractal set of contexts, each of which are systems themselves. These systems serve as the ecosystem for those they contain and will ultimately end in one or more social systems. Understanding the ecosystem is critical to ensuring that its component systems are fit for purpose, otherwise we risk trying to introduce fish into a desert.

The social system context is, in my opinion, key. Information technology delivery can take place in a wide variety of ways, but a useful high-level differentiation is that between delivery of an off-the-shelf product versus delivery of a service. Is the customer a client?

These two sentences, left alone, could be a source of confusion. Precision isn’t one of the English language’s strong points. Not all products are off-the-shelf, sometimes the service we deliver is the creation of a bespoke product (ultimately, the end user is concerned with the product that they will use, not the project by which we created it). Likewise, in my opinion, clients are customers, just not all customers are clients. In my career, I’ve exclusively dealt with client customers, so I tend to use the two terms interchangeably. That becomes a problem when we have a client that isn’t being treated like a client. Seth Godin’s recent post explained the difference nicely:

The customer buys (or doesn’t buy) what you make.

The client asks you to make something.

The customer has the power to choose, but the client has the power to define, insist and spec.

There is a large number of potential customers, and you make for them before you know precisely who they are.

There are just a relative handful of clients, though, and your work happens after you find them.

If a customer doesn’t like what’s on offer, she can come back tomorrow. If the client doesn’t like what you deliver, she might leave forever.

When a vendor fails to treat its customers as clients, they risk losing the client. When an in-house IT organization treats fails to treat its captive customers as clients, the result is “Shadow IT”. When that result is complained about, it betrays a shocking lack of awareness on the part of the complainer.

A client will have a hierarchy of concerns in relation to IT. The client’s main interest is the job that they’re doing (or will be doing) with a product. Their concern with the product will be shaped by that, as will their concern with the process by which the product is delivered. We shouldn’t be surprised when things that don’t promote the client’s welfare (or, at least, aren’t presented in that manner) are met with a lack of interest. We definitely shouldn’t be surprised when things that are seen as a net negative to the customer are met with hostility. Understanding and respecting the client’s point of view is required to avoid damaging our credibility and relationship with them.

Meeting the needs of my clients is my objection to #NoEstimates. Clients may have questions that require estimates to answer. In “Estimates – Uses, Abuses, and that Credibility Thing Again”, I listed several that were taken from a post by a prominent #NoEstimates advocate. In my opinion, those questions become my concern by virtue of being my client’s concern. Suggesting, as that advocate does, that they need different questions, is not serving their needs.

Just as the infrastructure environment can influence design decisions, so can the social environment. While it is certainly possible to deliver IT in an environment where the clients’ needs are largely ignored, doing so is detrimental to the clients, to the providers, and to the organization(s) to which they belong. We wouldn’t try to force a square peg in a round hole and we shouldn’t try to force ill-fitting solutions on those who depend on our work. Products generally work best when they’re designed to be used in the way they’re used. The same holds true for services.

[Recursive Matrena 01 image by Vahram_Mekhitarian via Wikimedia Commons]

Updated 4/8/2016 to fix a broken link.

Fixing IT – Remembering What They’re Paying For

Dan Creswell‘s tweet said it well:

Software development isn't your business: It's just one of many tools for providing a service that satisfies (customer) needs.

— Dan Creswell (@dancres) June 20, 2014

Max Roser‘s tweet, however, illustrated it in unmistakable fashion:

https://twitter.com/jetpack/status/596604003527589890

Success looks like that.

Not everyone gets to create the kind of magic that lets a blind woman “see” her unborn child. Nearly everyone in IT, however, has the ability to influence customer satisfaction. Development, infrastructure, support, all play a part in making someone’s life better or worse. It’s not just what we produce, but also the process, management and governance that determines how we produce. The product is irrelevant, it’s the service that counts. The woman in the picture above isn’t happy about 3D printing, she’s overjoyed at the experience it enabled.

Customer service isn’t just a concern for software vendors. It’s remarkably easy to destroy a relationship and remarkably hard to repair one. The most important alignment is the alignment of concerns between those providing the service and those consuming it. Mistrust between the two is a common source of “Shadow IT” problems, and far from helping, cracking down may well make things worse.

Building trust by meeting needs creates a virtuous circle. Satisfaction breeds appreciation. Appreciation breeds motivation. Motivation, in turns, yields more satisfaction.

As the saying goes, you catch more flies with honey.

Fixing IT – Taming the (Customer) Beast

In my previous post, I outlined the source of the dysfunctional nature of the relationship many IT departments have with their customers. This post will be about fixing that relationship. Having taken part in just such a venture, I can state that it is possible.

When I first became involved with corporate IT, I worked for a group that was developing a core line of business application for the company. Our process worked (well, “worked”) like this:

1. The users would produce voluminous “specs” minutely detailing the new features they wanted in terms of behavior and presentation. These were delivered to product managers.
2. The product managers would take the users’ “specs” and file them away for reference in their trash cans. The product managers would then generate their own “specs” minutely detailing the behavior and presentation of the features in accordance with the way they knew it really should have be.
3. The new “specs” were presented to the remainder of the team for estimation, and the final project plan was created.
4. Product managers, developers, testers, technical writers, trainers, etc. would all gather with their management and everyone would sign a “contract” to deliver what was specified by the due date.
5. Developers would then proceed to implement the features as best they could, substituting their own ideas for those parts that were ambiguous or unrealistic. When everything was completed (or when the “code freeze” date was reached, whichever came first) the features were delivered to the testers.
6. Testers would then generate bug tickets for anything that did not work the way they thought it should (regardless of whether it matched the documentation or not). Bug tickets were sent to the developers.
7. Developers would remedy the defects according to the instructions in the ticket and batches of bug fixes would be released to the testers.
8. Testers would pass the the tickets and forward them to the product managers.
9. The product managers would re-open the tickets and direct that the features be coded according to the original specification (or not, if they had had a new idea in the interim). These tickets would then be returned to the developers.
10. Developers would remedy the defects according to the new instructions in the ticket and batches of bug fixes would be released to the testers.
11. Steps 6 through 10 would repeat until either the tester or product manager relented, typically due to exhaustion. When this point was reached for all features, user acceptance testing was began by the user representatives who had composed the original “specs”. The original go-live date was, of course, long since passed by.
12. User acceptance testing consisted of repeated rounds of find-fix-push. The goal of the user representatives was to bend the meaning of “bug” such that something resembling the original requests would emerge. Really good ones could manage to get entirely new enhancements implemented as “fixes”. At the end of this process, a release to production was scheduled.
13. After the deployment (and all the downtime due to remediation of the release management issues), the end users could then contemplate how they were going to work around the software to earn their paycheck.

Needless to say, this process led to our having a warm relationship with our customers. They frequently assured us that should we burst into flames, they wouldn’t hesitate to stomp the fire out. Several even routinely produced books of matches and offered to demonstrate.

In all seriousness, the process we worked under at that time seriously impaired our relationship with our customers, both on an organizational and an individual basis. It destroyed our customer’s trust in us as it all but guaranteed that we would be lying to them about what they would be getting and when they would get it. The fact that they would not find this out until the very last second only added insult to injury. When the product was declared dead and the majority of the group laid off, it came as no surprise to anyone.

What did come as a surprise was that a small cross-functional group from the team was retained and tasked with teaching a new process to the remainder of the IT group. The nine months prior to the demise of the product had been spent re-engineering the process by which it was developed. While the effort wasn’t sufficient to save the product, it did get the attention of those looking to transform the IT function.

Reduced to its essence, that shift in process was nothing more than a recognition that our job was to make it easier for others to do their job. It wasn’t about technology or software development, it was about providing value to our customers and meeting their expectations. Value was understood to be more than just taking orders, but actually working with customers to define their needs and jointly determine a solution that met those needs. Meeting expectations was understood to be involving customers in the planning and keeping them in the loop as it evolved, not committing to a date with insufficient information and then hiding the changing circumstances until it could be denied no longer.

The result of this communication and collaboration was, slowly, step by step, the building of trust. As Tom Graves noted in “Product, service and trust”, “Trust is at the centre of everything in any enterprise – every product, every service”. In that same post, Tom used the image on the right to illustrate the cyclical nature of trust built via mutual respect, attention to needs, and delivery of results. Each success enhances the trust of the customer and the reputation of the provider. These successes can also form a virtuous circle where customer satisfaction increases the motivation of the team serving them.

It is important to understand that this is a process, rather than an event. As Seth Godin stated in “Gradually and then suddenly”:

It didn’t happen suddenly, you just noticed it suddenly.

The flipside works the same way. Trust is earned, value is delivered, concepts are learned. Day by day we improve and build an asset, but none of it seems to be paying off. Until one day, quite suddenly, we become the ten-year overnight success.

The reason this is so important should be clear. Business is dependent on technology more and more with each passing day. However, being dependent on technology and being dependent on a particular provider are two different things. When it is responsive and trustworthy, in-house IT can provide tremendous value to an enterprise. When it is not, the value proposition for outside providers becomes clearer.

Fixing IT – How to Make a Monster (Customer)

Software development in general and IT in particular seems to have a love-hate relationship with our customers – as in, we really love to hate on our customers. We have Stupid User Tricks, ID10T issues, PEBCAK, and of course, Clients From Hell. Every once in a while, even Dilbert takes a break from bashing managers to take a swing or two at customers.

There’s even some evidence that the feelings are mutual.

Why?

How is it that we’ve managed to come to the point where distrust, even open hostility, is the norm? How is it that this situation is allowed to continue? What if we don’t change the dynamic?

To get an idea of how we got here, imagine the following scenario:

• There’s a restaurant where you’re required to eat.
• You don’t get to decide when you can eat; you have to ask (and ask) and eventually you’re allowed to sit at the table without any idea of when you’ll get another chance.
• You don’t pay for what you eat, but you will have to justify each menu item you order.
• The kitchen staff will be required to say how exactly long it will take to prepare the order, even if the item is not on the menu and no one has ever made it before.
• The waiter, the chef, and the maitre d’ may not understand or be able to prepare your order, so they reserve the right to alter it without any notice – you’ll find out when it arrives.
• Waiters interacting with diners after the initial order is considered poor practice; kitchen staff doing so is completely out of the question.
• If the order doesn’t meet your approval, you can send it back to be fixed as much as you like.

Under those circumstances, one might expect the restaurant patrons to be a tad distrustful of the staff, who will probably respond in kind. The experienced patrons will have learned to order as much as possible, regardless of need, subject only to the restraint of getting approval. They will have learned to be vague enough to allow them to keep sending dishes back for fixes that are enhancements in disguise. The bolder patrons will either learn to cook for themselves or find another restaurant, perhaps both.

Is this starting to sound familiar?

The second question, how is it that this has been allowed to continue, is something of a mystery. While there has been a growing significant incidence of shadow IT, things still haven’t broken out into open rebellion. How much of this is inertia and how much of this is the current economy holding back expenditures? More ominously, how close to the edge are we?

This brings us to the third question, the answer to which should be obvious. Trying to maintain the status quo will not work. In fact, doing so will be more likely to hasten the demise of IT as it becomes more of a commodity. Without major changes, IT risks becoming irrelevant and marginalized. Rather than worrying about blame (it should be obvious that this is a systemic problem rather than one or two bad actors), both business and IT need to find a way forward that maximizes value and minimizes friction. The risk to those organizations that cannot make this transition increases with each passing day.