As a computer science & managment graduate I took a few courses in marketing. The most important in my mind was the one tackling the most basic issues of marketing. These issues are relevant to all the fields of marketing, games included. One basic principle struck me as especially interesting and useful, and I thought it would be nice to tell you all about it. This principle might have several names, but my professor called it "the three questions rule". This rule says that the first step in creating a new product is asking yourself the three following questions: 1. Who is my customer? This is trivial you might say, but this is the point of failure for many. I''ll give you a classic example of such an error. Let''s say that I want to create a killer business app for the mobile market. I start my project by researching the market and I find out that there is this magical thing called J2ME (java 2 micro edition) which runs on almost every device out there (!). Reading a bit further I find out that the old interoperability-for-performance tradeoff is more true than ever, and I am limited to the least common denominator of the mobile hardware. Still, wanting my application to be as broadly available as possible I write a black and white application limited to the capabilities of age old technology. This application is of course crashed by the colorful and rich feature competition. What did I do wrong? Well, I went for the most common mistake of "interoperability is always preferable to performance". I didn''t ask the simple question of "who is the customer?". Had I asked it, I would have known to answer "businessman". And what hardware do respectable buisnessman have? That''s right - the latest phones and gadgets so they can look important and impress unsuspecting colleagues. What I should have done in the first place, is find the type of hardware MY TARGET MARKET (i.e. businessmen) uses, and write the best app I can, given the POTENTIAL CUSTOMER LEAST COMMON DENOMINATOR. Trust me, answering this question will save you a lot of dead-end projects. 2. What does my customer want? Trivial as the first one, but not less dangerous. Understanding the needs of the potential customer (you did ask yourself the first question, right?), is the next phase in designing your project. You need to know exactly what the customer wants in order to create exactly what he needs. No more, no less. I''ll continue with the previous example and show you a common error. Let''s say that you understand completely your customer, and you decided to use a specific set of phones that are much more powerful than the average phone. Also, you made it pass through the first phase of the current question and you cleverly decided that businessmen need business app. You are now in the phase where you are writing a feature list for your app. Let''s say that you decided to write a translator app that has a "say" feature, i.e. that phone speaker is used to say the translated words . "Wouldn''t it be cool if it had an equalizer feature?" you might ask. The question you should have asked is "Would a it be a useful feature to my customer, and will he consider it as an added value?". The answer is probably no. 3. How do I supply my customer with his needs better than the competition? In a perfect world, there would be no competition. Alas, our world is a bit less than perfect, and competition is abundant. Therefore after carefully examining who our customer is and what he wants, we need to figure out how we are going to beat the competition. There is no magic rule, since you usually don''t know what the competition has cooking in the R&D kitchen. What you need to understand however, that this is sort of a "deaf & blind infinite race". The winner is the one who gets further faster. However, the problem is that you run blindfolded, and you can''t even hear the footsteps of your competition. If you try to run too far too fast you might collapse. On the other hand, if you stop too soon or too late, you can count on it that there will be 10,000 runners staring at you from the same point after removing the blindfold. Hope this helps, Adi.

Interesting. But isn''t there a 4th question? Like "How do I communicate with the customer to tell him/her about my product"? Marketing involves building a relationship. If the customer isn''t aware you exist and you have a product ready-matched for him/her, you''re not even on the starting line (to use your race metaphor).

> As a computer science & managment graduate I took a
> few courses in marketing.

Here are a few reads along those lines that might interest you:

Ward et al., "What High-Tech Managers need to Know About Brands", Harvard Business Review, July-August 1999, p.85.

Adrian Ryans, Roger More, Donald Barelay, Terry Deutsher, "Winning Market Leadership: Strategic Market Planning for Technology-Driven Businesses", John Wiley & Sons, 1999.

Geoffrey Moore, Regis McKenna, "Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers", Harper & Collins Perennial, 1999.


-cb

Ah, but then that wouldn''t fit nicely in that "Power of 3" rule that''s so prevalent in marketing psychology would it?

Cas

I think there should be many more questions, including the one you wrote down. I see a lot of people diving deep into projects before asking themselves even the first one.
I think that what you mentioned, regarding product awareness is especially important for us "lone wolves" who do not have the resources for advertising campaigns. Usually the harsh reality forces us into a not so fair agreement with a distributor. I''ve heard one too many stories about developers not being paid, or not being paid as agreed.
One can only hope to find honest men to build business relations with.

> ... that wouldn''t fit nicely in that
> "Power of 3" rule ...

I wrote down 3 references, so the rule is respected ... |8-}

> One can only hope to find honest men to build
> business relations with.

The gaming industry is pretty tight; people tend to know who the rotten apples are. My advice would be to talk to established developpers and cross-reference their recommendations. The IGDA is also a good reference; check out their free documentation for indie developpers:
Game Submission Guide
Game Contract Walkthrough
IP Rights
Best Practices

A good book reference is this one: Laramee, F.-D., "Secrets of the Game Business", Charles River Media, 2003. A good read about publisher/developper relations & contracts.

-cb