Preparing a product pitch

Many publishers have commented on the large number of game proposals they receive that failed to meet an acceptable level of quality. The various comments I have heard all boil down to the same sentiment; “Why do developers think that showing a badly written one page pitch document and a badly edited video will make me give them $2 million.” The publisher’s view seems to be that the sums of money involved in development are very large and that the developer should be willing to make a correspondingly large effort to prove that they are worth the investment.

Juxtapose that sentiment with a recent (and frequently echoed) quote from a developer posted on the forums. – “I don’t really like to make a game demo because it takes me some time .. I prefer giving an alpha version to the publisher if he is interested”. Analysing the developers comment gives us two main points.
1. A demo takes time (that the developer believes could be better spent developing the game).
2. They assume that a publisher will be impressed by whatever milestone code they happen to have so far.

Obviously the two parties are operating to different rules and this makes it less likely that the developer will succeed in securing a deal. To maximize the chances of a developer securing publisher funding one of the parties will obviously have to change their attitude. Given that developers are talented, creative individuals, whilst publishers are simply bloated sacks of cash, it is equally obvious that the publishers should be the ones to change – except that this would breach the golden rule of business….

He who has the gold makes the rules.

A developer pitching a concept to a publisher is doing so because they want the publisher to fund development. What many of these developers fail to realize is that the majority of individuals involved in the decision to fund/not fund have little or no understanding of development. These people are the developers “customers” (at least for the purpose of securing funding) and the developer must sell their game in a manner/language that these customers understand. If the developer submits a shoddy proposal and a badly presented demo then the publisher is going to assume that:
1. This is an indication of the (poor) quality of the final product,
2. The developer does not have the ability/dedication to produce a good demo/proposal,
3. That they lack the design skills to create something that looks good,
4. That they lack an understanding of the importance of usability as shown by the fact that they have produced something that operates at the minimum level of functionality,
5. That the developer does not consider the pitch process (and by extension the publisher they are pitching to) to be worthy of any great effort.

For most games (if not for most developers) the product pitch is a vitally important event. Although not part of the actual computer game development process it is a hurdle that most games must overcome if are to reach the shops. The majority of commercial games are either funded, published or distributed by a major software publisher. A successful pitch (presenting the game to prospective publishers) can clinch the necessary funding to complete a product or gain a publishing/distribution deal for a soon to be completed title.


  • To present the product idea clearly to the target audience.
  • To illustrate the key points (business and creative) of the product.
  • To demonstrate the team’s professional and creative talent.

The target audience for a product pitch can be split into two groups – development and non-development (marketing, sales, PR, accounts and senior management) your product submission needs to target these two groups.

The publisher’s development department will evaluate the products potential as a game. Obviously they will also evaluate its suitability on a commercial basis but their main focus is the probably quality of the game play experience.

Most of the other departments will focus more on its sales potential, marketing hooks, likely return on investment, possibility of creating/furthering a franchise or other business related issues. Few, if any sales or marketing staff understand the process of computer game development so it is important to ensure they receive the information they require before your document wades into any overly complex development detail.

The best way to address this twin audience is to divide your presentation into distinct sections as follows:

1. Pitch document (AKA the sell sheet) – This gives a brief outline of the game concept (one or two paragraphs) followed by the key business information (cost, completion date, team, target market, formats, languages and contact details). This document is the vanguard of your attack on the publishers wallet and it targets the non-development segment of your audience.

2. Design document – This provides complete game play/design information for those who want it. The audience for this document will be the publisher’s development staff. They will be expected to render an opinion as to the quality of your game design for the non-development members of the audience.

3. A Budget – Detailed breakdown of the budget for the project. Not necessary if presenting a completed product but as most games are publisher funded you will need to show how you intend to spend their money.

4. Demo – The reality is that documentation alone will no longer get you a deal. Where previously a publisher might sign a project based on a video presentation they now expect to see working code. The key here is “less but better”. The demo should show key features and visuals from the game and should be well polished and as bug free as possible. It is far better to spend time ensuring the demo works smoothly than it is to try and add extra features that may make it unstable. The demo will be viewed by non-development staff who may not see past the rough edges so keep it tidy.

In fact an IGDA (Independent Game Developers Association) publisher survey conducted in February 2003 revealed that the majority of publishers consider the demo to be the most important element of a product pitch by far and that most will not sign a game with a poor quality/non-existent demo.

Note: The demo is such an important element of the submission that I have prepared a separate feature (see Preparing a Demo) which focuses solely on preparing a demo.

5. Competitive Analysis – This is a review of the existing titles that your game will be competing with. This document helps to show that you understand the genre you are targeting and that you have examined the competition thoroughly. The document should give a brief overview of each competing title, review scores, sales figures and key features of each title.

6. First five minutes – Many publishers now like to see a description of the first five minutes of play. It helps them visualise what the game will be like and also helps to convince them that you can visualise your own game.

7. Development Team – A brief document describing your company/team, yours plans for the company and the teams previous experience. This is important as publishers want your concept to be backed up by a development team with a proven track record. The following lines are taken from the Eidos Interactive web site:

Regarding design submissions by individuals
……….it is very unlikely that we would take an interest in a design or storyboard from anyone but a well-established developer with the programming and graphics resources to develop the title in question.

Storyboards and Demonstrations from Development Companies
We are always very interested in talking to development companies with ideas for games and work in progress. However, the track record of the individual employees of the company and of the company itself is of paramount importance. Demonstrations of work already carried out on such designs is also very important. Preferably these should be running on the computer or console in question, rather than pre-rendered sequences from an SGI, for example.

Eidos are far from unique. The almost universal message from software publishers is that they want professional presentations backed up by a valid budget, a stable code demo and a team with the proven ability to make the game – Oh and no crayon please.

Note: when seeking non-publisher funding you will also need a business plan to go with the above.

Making your presentation
Your first point of contact with a publisher will be the development or product acquisition group. Unless you already have an existing relationship with the publisher your chances of getting a face to face meeting to make your initial presentation are almost zero.

The reason for this is sheer weight of traffic. Most publishers receive a dozen presentations per day and 90% of these do not meet the publisher’s needs (or their required level of quality). To meet with each developer would mean that someone would spend the majority of every day in meetings discussing products that they will not be publishing. This simply isn’t an acceptable use of their time.

Because of this most publishers will insist that a product is submitted in the first instance by post. The submission will receive a “first pass” review to decide if it is worth considering. (Anything produced in crayon will be rejected at this stage with a standard reject letter.) If it survives this first pass then the proposal will have taken its first step into the acquisitions process. This is covered in more detail in the Article The acquisitions process.

Key points to remember

  • Do not – phone the publisher and try to force them to agree to a meeting so that you can pitch your product – they are busy so initial contact is usually by post. Accept this with good grace.
  • Do not – try to pitch them your product over the phone. You will not do it justice and are more likely to damage your chances.
  • Do not – ramble once you get into a meeting. Do not tell the entire history of your game universe unless they specifically ask. Just answer the question they ask, keeping answers short and focusing on the key features of your title.
  • Do – Phone the company and ask reception who is responsible for product acquisition (then hang up).
  • Do – phone back later/next day and ask for that person by name. Talk to them and ask how many copies of the presentation you should submit. This is mainly so that they will know who you are – you have started a relationship (even if you are not even at first base yet).
  • Do – Rehearse your presentation. Work out how long your demo runs for and “script” what you will say and what key elements you will point out.
  • Do – Study your proposals weak points. An experienced publishing team will home in on your weak spot. If you freeze when asked a difficult question you may give them the excuse they need to reject the product. If you show that you are aware of it and have given it some thought they are more likely to forgive the weakness. You can also ask them their opinion. Get them involved in your project and you are more likely to get it signed.