[thelist] Demographics and market research (was The Client Doesn't Know His Audience)

[Luther, Ron]

Janet Green offered a number of neat links for demographic information that 
I've snipped (but copied to peruse later!):


Hi Janet,

Honest - I'm not going to disagree with the need to understand 'the 
marketplace' and the dynamics that cause customers to buy goods and 
services from the client.

I also highly commend (and recommend) taking this tact with your clientele. 
(This positions you more as a 'partner' helping them to improve their 
business than as a contractor merely 'building a site' ... and that 
relationship should lead to extended long term opportunities for work 
(and $$) as you help them grow their business.)

I'm just chiming in with a word of caution for folks who have not spent 
a lot of time looking into these kinds of things (it sounds like you 
have spent a lot of time working with this kind of information -- I've 
also spent a number of years conducting primary research in demographics, 
psychographics, willingness-to-pay, ad recall, and other weirder things 
{like elasticity estimation} using a number of different sampling and 
experimental design techniques).

To paraphrase from Dr. Russell Ackoff (old school business guru from 
Wharton Bus) "Companies don't have a clue why their customers buy their 
products and services!"

I tend to agree with him pretty strongly on that point.  (I also don't 
think success in the marketplace correlates all that strongly with 
understanding why your customers buy your products and services - but 
that's an (albeit related) slightly different point.)

The point is that even if (maybe especially if) you *do* run into a client 
who says they can explain exactly who buys their products and why ... 

(a) Take it with a grain of salt.

(b) Try (tread lightly here!) to help them to challenge those assumptions. 
Perhaps talking to them about web plans that could help them to extend into 
new markets would be a potential approach here ... I'm not sure.  But I 
completely agree that if you can help them to better understand their 
customers you will become a more valued resource.

RonL.

Straying perhaps too far afield necessitates a tip here:

<tip type="Forms and LOV Fields" author="RonL.">
Possibly more of a rant than a tip ... we'll see.

If you build critters that look more like web-enabled 'applications' 
than static sites. e.g. forms and reports that allow users to pull 
selected portions of shipments / purchase orders / sales orders / 
etc out of a database ... *please* don't build LOV fields off 
transactional elements (or even transactional tables).

(a) They are really really sloooooooow.
(b) They are 'anti-usability'. [Even if the client/VP asks for 
them (by name) ... eventually the users will find you and key your car.]
(c) I suspect software trainers don't really enjoy saying "Whatever 
you do - please don't push THAT button!"

How do you get around this?

(1) Talk to your users. Try to understand how and why they will use 
this new application.
(2) Talk to your users ... some more. Better understanding = better app.
(3) Use existing classification fields for selection criteria. 
{It's a *LOT* better to let your users select a single classification 
value like "RMA Orders" than to give them a list of 8,000 purchase order 
numbers and expect them to manually 'ctrl-click' the couple of hundred 
RMA orders.}
(4) Talk to your users and create new classification fields.
(5) Spend months negotiating with other systems to 'source in' 
additional classification fields.

Good Luck!

RonL.
[Who suspects that the archives for any forum for report writing 
software contain any number of messages of the 'please tell me how 
to get more than the 'x' thousand value limit into my drop-down box' 
variety. Grrrr!]

* LOV = List Of Values.  [Often a side button to show the users what 
"possible" values can go into a field on the form, or to allow them to 
select one or more values.  {Usually runs a 'Select distinct field 
from table' query in the background.} Quite often abused to bring 
back 'too many' values.]
</tip>