'''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