Selling Your Ideas
If there is one thing that I wish I knew as a high school kid it would be the following. Knowing how to sell your ideas is one of the most important skills in life. By “selling” I mean, being able to convince others that things you have in your mind are worth their effort or at least attention. In fact, if I think about it. This is what I have been doing most of my life. Passing exams in school or at the university was all about convincing the professors that the ideas and notions I had in my head were aligned with their expectations. Later, working at the university as a post-graduate researcher, I was expected to produce papers, i.e. scientific publications on topics of my research. That too was all about selling my ideas, i.e. convincing peer reviewers that my results were novel enough and interesting enough to be worth publishing.
As a game designer, I face this task over and over, each time when I need to present a proposal for a new feature, let alone a whole new game. Knowing how to sell your ideas is an essential skill for anyone working in a creative team. It is also something I feel I will continue learning and improving for the rest of my life. Here are a couple of things I learned along the way.
KEY IDEA: Be dispassionate.
First of all, when discussing ideas, learn to tame your emotions. We tend to get attached to our ideas. We tend to treat them as our babies. This in turn can lead to a lot of emotional distress when our ideas get disected by others or even worse, if they are rejected. This is the wrong way of seeing things. It doesn’t matter whose idea it is as long as it improves the project you are working on.
KEY IDEA: You are not evaluated on your ideas, but on their execution!
Next thing, know what you actually want to present. Work on your idea until it is clear in your head. Develop it into a concept with enough details to provide relevant information to your listeners.
KEY IDEA: Know your audience. To whom are you speaking?
This is actually crucial. As a designer, you are most likely going to need to present your idea to several very different groups of people. Most likely you are going to need some sort of approval from other key stakeholders. These may well be people higher than you in the team or company hierarchy. They are most likely going to want to understand how your proposal aligns with the big picture, i.e. how it supports the high-level goals of the project. On the other hand, the rest of the team, the programmers, the artists, the QA, etc. will want to know about your idea on a more detailed level. They will be interested in the technical details of your proposal. People in charge of production scheduling such as producers, development managers, and development directors, will be interested in the scope of your idea, i.e. about the scope of the development effort needed to realize it. Other disciplines will have their own specific questions.
KEY IDEA: Do not try to make a one-size-fits-all presentation.
This is a bad approach. It will inevitably burden people from each of these disparate groups with a ton of detail that they do not particularly care about. Even worse, presenting needless details to a group interested primarily in the high-level vision of the proposal might lead to a situation where someone latches onto a particular specific detail which might be inconsequential in the long run, and derail the whole conversation. I have learned this mistake the hard way.
In order to systematize things in your own mind, you might want to create one big presentation that contains slides describing various aspects of your proposal. Use it as a basis, and extract just the needed slides into separate presentations intended for the particular discussions with the particular audiences. This is the method that I often use.
KEY IDEA: Start from the general and work your way into the details.
Always begin with a set of goals. Great writer Kurt Vonnegut had simple advice about making a novel. Each scene in the novel should either move the plot forward or reveal something about the characters. Otherwise, it has no place in the book. This applies to your idea. If you can summarise its reason for existence in a set of three to five goals it probably has no place in your project. Vonnegut’s advice applies to the structure of each of your presentations. Each slide has to have a purpose.
After stating the goals, when proposing a new feature for an existing game, be it a live one or one that is being developed, I sometimes list the stuff that already exists in the game that I am building upon. This is not always the case.
Proceed with describing a high-level concept. This should neatly fit onto one single slide. Use the remaining slides to elaborate on the details.
KEY IDEA: 25 words or less!
Keep the text minimal. Iggy Pop has great advice about writing lyrics for rock songs. Twenty-five words or less! Keep the text on your slides in three to five bullet points. If you can’t compress what you want to say into three to five short lines it is a good signal that the content should be divided into several slides.
Do not worry if you are not including all the details in your slides, even in a deck intended for the people that will be doing the implementation. Your PowerPoints should not be your design documentation. Design documents should reside elsewhere and be maintained differently. They should include all relevant detail.
Use pictures, diagrams, and illustrations as much as possible. A picture is worth a thousand words. This is absolutely true. Never put more than two or three pictures that are meant to illustrate different things on the same slide.
KEY IDEA: 5 to 7 slides not including the title and the end slide.
These short focused presentations intended for use on a particular meeting with a particular group of listeners in mind should ideally be between 5 to seven 7 long. This doesn’t include the title slide and the ending slide. The last slide should give a clear signal that this is the end of your presentation. If you can’t fit everything into a maximum of 10 slides your presentation is probably not focused enough. Reconsider its content.
Sometimes, this is not possible. You might want to include slides with additional details. Include them in the clearly marked appendix of the presentation.
You do not need to have all the details already worked out before presenting the idea. Be clear about the unknowns. Be clear about open design questions. For some of them, you might not have the answer right away but you could be confident that you would find one in due time. For example, you do not need to know the exact number of reward tiers that a Premium Pass would have in the end, just a ballpark estimate, and that this number needs to be configurable. On the other hand, some open design questions will require more work, discussions, and experimentation. Be open about this. Your team is there to help you find solutions.
Do not try to think outside of your domain, especially when talking to the other disciplines in the team. Your team is full of experts in their own domains. Do not try to think for them. Ask them for their input. Above all ask them for input and feedback on their area of expertise, but ask them also for general feedback on the idea.
Finally, keep in mind the purpose of each meeting. Some meetings are about getting approval to proceed or not with a certain design. They should end in one of the three clear outcomes, either everyone agrees that the design can proceed forward, or the design should be totally abandoned, or the design should be significantly reworked. In this last case, do not try to solve design problems in the same meeting, gather feedback and iterate on the design, alone or with a proper group of people. Some meetings are going to be kickoff meetings in which everyone needs to get acquainted with the design to some level of detail. These meetings should end with everyone aligned on the main points of the design. The details should be written in the design documentation. Everyone should leave the meeting with the knowledge about where to find those details.
