Understanding your audience
- By Tig Tillinghast
- May 24, 2001
People managing Java projects require an acute awareness of end users' needs. I don't mean requirements and specs, but needs, such as the priorities users have that they're going to use to judge your product.
Even engineers have to sell their product, at least internally. The "end user" could be the person stuck using your code, or it could be a liberal arts graduate who happens to be the supervisor of the relevant business group in your company.
While the spec may tell you scalability and efficiency are top priorities, you have to use your own intuition to divine the real priorities, such as:
- Develop code that gets the product development people "off my back" quickly.
- Develop code in such a way as to let me suggest this is "clever" and probably "proprietary."
- Make sure it doesn't push me down a "technological dead-end" for the future.
Having marketed developer products for some years, I find most companies and agencies conform to a few profiles—groups of people who share similar priorities. These are worth examining for the Java coder or manager.
The IT Head
The person in charge of a company's technology strategy will frequently exhibit more skepticism and conservatism than someone who actually uses new technologies. Heads of IT departments live with the headaches and costs of cool, new things that were just a little "too cool" and a little "too new."
Marketers harp on reliability when talking to this audience. We use images you might see in banking ads, and testimonials from bigwigs at big companies.
There was a brief respite in this strategy in the last year-and-a-half. A lot of IT heads got caught a little behind the Web trend, and had to do some quick catching up.
Managers of programmers, engineers, system architects, and the like have several conflicting influences:
- They tend to be held responsible for keeping to an existing grand scheme, making major new technology introductions dangerous.
- The programmers that managers need to keep happy often push managers to use more "state-of-the-art" methods, even if it breaks the neatness of the grand scheme.
- The average programmer manager harbors a bit of "programmer" in their soul. This makes them apt to want to employ new things, particularly those that will make the process appear more efficient.
The coder is the most complex of these technical characters. Coders often need to feel a certain degree of cleverness. The satisfaction of well-written code comes not from the most consistent documentation and code comments, but from a creative process.
Often, products sold to the Java market can provide programmers with media they can use to hack together brilliant, sometimes non-intuitive solutions.
Marketers who tell coders they don't need to think quite as hard when they use their products are missing the message. Coders don't want these products to do their jobs; they want them to do the annoying bits, freeing their creative sides.
The perfect product for a coder is positioned as a humble tool that allows the coder's creativity to flourish. It gives the credit to the programmer.
Likewise, internal tool developers need to downplay their own role in product development, giving credit to the user. This breeds end-user satisfaction.
Figuring Out Your Own Customer
There are many different ways to slice audiences. You might find it appropriate to break down internal customers into different departments, or into those who serve different market segments. Use discretion.
By thinking in terms of customer needs and their likely priorities, you can reduce a great deal of friction and increase perceived satisfaction. Often, this doesn't require Java coders to change what they do; it merely requires them to position their efforts in a customized manner.