Know Your Customer

Problem: Making informed decisions is difficult when there's not agreement about who the customer is.

Context: You're ComingUpToSpeed in a new situation that involves building products for one or more customers. Access to the customers is indirect. You're called upon to make informed technical decisions on matters that affect those customers, but there's not a shared agreement about who the customer is.

Forces: Different functional areas in the organization have different temporal lenses through which they view the customer.

Sales' view of the customer is weighted by near-term customer needs (i.e., what it takes to make the next sale).
Marketing is often focused what it will take to reach future customers.
Technical Support's view of the customer is heavily influenced by problems that end users have with the current product.
To further confuse matters, over time the technical folk may have come to confuse the end user with the customer, leading to disconnects when communicating with other parts of the organization.

Each group can make some claim of speaking for the customer. Though, much like the old joke about people in a dark room with an elephant, each group can be so influenced by their perspective as to make informed decisions, and consensus, difficult.

A Solution: Reframe the problem. Ease people in to a common understanding of the customer by way of an easier-to-develop shared understanding of the customer's ProblemDomain.

Motivate this solution by making ambiguities visible. Elicit details about the customer's problem from the key players, get them to disagree, and to acknowledge that they disagree. (Having VisitorFromMars status may help disarm defensiveness, since you can honestly claim that you're confused and are seeking clarification, and not attacking their position while defending yours.)

Then, develop a description of the customer's problem domain, and how that domain is evolving. As necessary, distinguish between the end user (who uses the product), and the customer (who writes the check). Sales probably has the best information about the current customer, and Marketing has the best read on trajectory.

Finally, develop a description of how your product addresses the problem domain. (It might be useful to add information about how competing products address the problem domain, since that may influence decisions.)

Thereafter, condition the organization to speak in terms of problem domain, rather than in terms of their view of the customer.

Resulting Context: Ideally, this results in a shared understanding that keeps everyone "on the same page." At worst, it results in a heightened awareness of others' viewpoints.

This pattern changed in the writing from where I'd expected it to go. It's worked for me when parachuting into broken situations in small organizations, but I have doubts that it would scale easily in larger organizations with well developed Sales and Marketing roles. Then again, perhaps such organizations don't suffer the problem...

If anyone wants to take a shot at reworking this, be my guest.

-- DaveSmith (3/18/96)

I don't know about reworking this, but I had this exact problem in a large company where I was employed.

We (the technical staff) recognized the issue and tried to get everyone to agree that there were multiple meanings for customer. Impossible! No one would entertain the thought that someone else could have a different definition of customer (or client). Management did nothing, deadlines loomed and we made our own decisions (satisfying no one with the resulting system).

Another area of this large company was trying to attack the same problem four years later as I was about to leave. They are about 1-2 years from implementation. So, we will see what happens! :))

Q. Is it really so important to resolve this issue if management can't get their act together? What difference does it make for a system that is supposed to address both sales and marketing?

-- ShalomReich

Even if management can't agree, having a shared vision within the engineering team helps to ensure that technical decisions are made coherently. If decisions can't be made on an informed basis, coherent decisions still beat anarchy.

-- DaveSmith

Yes, but . . .

The group (both the business side and the technical side) had been recently consolidated and management decided to create a new centralized, consolidated system to combine everything into "one way of doing things". (A real mess - trying to get technology to drive the business!!)

In truth, the various technologists still supported their original users on the old systems (which perpetuated the views of "Customer" held by the original users) and resisted seeing things a new way. It was impossible to get any consensus!

At the same time the new "centralized" managers (for both the business and technology) were unable to control the formerly independent managers below them.

It was LOTS of fun :(

-- ShalomReich