User adoption and the psychology of names

"The Name" is the name of this Brazilian group, but we couldn't use that for the portal

There’s no clever title today, just a clever first sentence.

Let me dive into this topic with some background. I’m helping a company with an internal portal strategy, and one of our concerns relates to user adoption.

My concerns aren’t only about functionality. They aren’t just about usability. I also have a concern for naming.

You see, this global company has a lot of paper forms, a lot of email, and many subsidiaries acquired over the last decade. Each of these matters to me when I think of how users might feel about this new portal.

We have learned, reflexive and instinctive behaviors, though I suppose you might argue that reflexive and instinctive are either the same or related.

Regardless, adopting new behaviors is costly (in terms of time, energy, money and other opportunities).

Looking deeper into my concerns

So here are just a few of the reasons I care about those factors:

1. Paper forms – moving to a web-based solution requires changing long-established human behaviors
2. A lot of email – what electronic communication exists is largely unstructured and long-established as well
3. Acquired companies – each business unit asserts they do things differently, and we have a lot of overlapping terminology

So in the first case we want people to use an online work order and not paper.

In the second case we want users to share conversations and upload attachments to the online work order and not pass them around in email or create lots of versions on file servers…

…and in the third case it would be great just for everyone to agree what a “work order” is!

It is this third concept I want to talk about today.

Two options, two paths?

Maybe THIS is the inner working of my Archimedles?

On the surface, we have two options: 1) we call a work order a “work order”, or 2) we call it some other thing (the term “Archimedles” [not “Archimedes”] comes to mind if you’ve read my posts closely for long).

Now, I’m speaking of a “work order” because it’s a simple concept of an artifact. I could have chosen a PO, an invoice or some other artifact. In this company’s industry, there are some commonly used documents that aren’t so universal, but end up producing a similar naming crisis anyway.

If we choose to preserve the standard name, we benefit from its history in everyday use, but we sign up for “standardizing” what people think a “work order” is. Establishing standards is expensive, though often worth it, but sometimes results in mis-communication or even minor rebellion for a time.

If we figure out a different name, even a new name, we can’t lean on the history of usefulness people already associate with the concept of a work order… but among other things we change the kind of learning processes our users go through as they work with the new portal.

We are “triggered” psychologically to notice what is different

When people see something as “new” or “different” from what they know, they attempt to figure it out in terms of something familiar, e.g., saying Google+ is “just like Facebook”. Meanwhile, they also invest some time and energy trying to learn it.

By calling something by a new name, we open the possibility for our users that what they are looking at actually isn’t what they already know, that perhaps it has some marginal utility. We can spark curiosity and wonder, and we can engage them in new and different ways.

After all, Google+ might be to Facebook what the iPhone is to the bag phone Michael Douglas carried in “Wall Street”. (Time will tell.)

Meanwhile, if we change the words we use, but our users end up feeling like it really IS just a new spin on the old work order, they could be dissatisfied and rebel against the change there, too. When we claim something is new, we make a promise… which sets up the possibility for building trust, and produces an obligation in us to deliver on the marginal utility we imply or outright promise.

A work order really IS a work order, though

Unfortunately, it often seems like we’ve used all the good names already. So we really can’t change the name of something as common as an invoice, PO or even work order. In this case, I used them mainly to illustrate the place we are in and some alternatives.

Naming is an important part of the design and rollout strategy for this portal initiative. Since we can’t take one approach or the other, we are left with a hybrid, keeping some names and adopting new ones… even inventing some where new metaphors for interaction seem proper.

Where have you considered using new names for innovative changes you develop? Has your product really been different or new? What did you notice in the form of user responses and adoption?

How do you manage demand effectively?

Take a number?

You don’t manage demand.

You can’t manage demand.

It’s not a powerful question to ask because it’s not within anyone’s capacity to carry out.

When our customers line up and take a number to make their requests of us, demand simply is. Though we may have processes in place to manage our limited resources, we should never be confused that we’re actually managing demand.

As long as people have concerns to care for, there will always be demand. As long as technology can help take care of some of those concerns, technologists will never have enough capacity to take care of everyone.

Demand management and portfolio management

Demand management is a philosophical orientation toward IT governance, mostly about portfolio management.

As we inventory all the projects we might take on, we call that a portfolio. As we decide what we’ll do, set priorities and allocate resources (human, financial, equipment and other forms of capital), we call that portfolio management. It is an important and powerful management practice that aligns with the most basic constraints we face.

Where “demand management” enters into the picture, it represents a philosophical shift from our real constraint to the external market. IT claims to “manage demand” because our resources are always insufficient, and we know that we have to say “no” to some requests that come in. By saying “no”, we say we are managing [read constraining or governing] demand.

Only we’re not. The demand is still there. We’re just saying it’s beyond our capacity to cover. We put management-speak around our philosophy, perhaps so that it’s less confrontational or makes us feel better?

Fundamental mechanisms of demand

Rather than jump to the opposite extreme and suggest we stop saying “no”, let’s first make some assertions about demand and our capacity to handle it:

1. IT resources are always limited, relative to demand
2. Outside of strategic capital investments in IT, working to “keep the lights on” (email, hardware, software, infrastructure, service desk, phones, etc.) consumes much of the IT budget
3. Customer needs do not go away just because we can’t handle all requests

You can't argue with fundamental mechanisms

You see, customer demand also originates in similar fundamental mechanisms: everyone needs help, they also have limited resources, and eventually if they don’t take care of their own concerns they start to suffer until they take action… and that action might not involve us in the way we prefer.

If you add to these the concern that rapid technology shifts overtake some IT professionals, causing them to gradually either 1) focus on smaller domains, 2) become generalists or 3) lose competitive advantages as the market drifts, it strains our capacity to consistently keep up with customer demand more every day.

As a result, a notion that we can manage demand seems both reasonable and attractive. It is important, however, to stay grounded in the fact that we can’t do everything and we aren’t doing everything… so if the demand is high enough, our customers will look elsewhere for the help they need.

Those environments where IT believes they manage demand but also work to prevent customers from going outside for help create “the perfect storm” for marginalizing the value of IT and prompting quick business responses to outsource the function.

How demand management impacts trust

I have written of trust in many other places. Remember for the purposes of this blog that we distinguish trust as “an assessment of our sincerity, reliability and competence to hold our promises […for as long as we need to].” I also shared the observation of a marketing expert who said they have been waiting for an IT project that has been three months from shipping for over 18 months!

It happens. It isn’t pretty. But what does it say for sincerity, reliability and competence?

If we believe the answer is demand management, and demand management ultimately means cutting back on the work we promise to do, then maybe we hope to increase trust by making fewer promises? That would make sense if it were the end of the story.

You see, if IT has a history of failing to deliver, we break trust… and if we make fewer promises, we lose opportunities to build trust. AND if we do both… we lose on both ends.

So what do we do?

The rational answer, it seems to me, is to first accept that demand management is a philosophical orientation. It is not right or wrong, but it shapes how we think and act with regard to our customers and our “competitors” (those to whom they turn when we say “no”, as we must).

Next we need to look for a more effective philosophy that focuses on what we CAN do.

Don't confuse this with the power of positive thinking...

We have to start by making make sure to hold our promises while ALSO making as many as we can keep. We make them clearly, and we work to build a new tradition with our customers of saying yes and delivering – consistently, recurrently and with optimal business value… all the time. Rinse, and repeat.

When we say “yes”, we don’t say yes to everything (which breaks trust), but yes to what we can do with our limited resources.

Let’s change the philosophy from “managing [governing or constraining] demand” to “managing [taking responsibility for] the value we produce”.

We can’t manage demand anyway… we can only manage the promises we make and what we deliver with the resources at our disposal.