-
-
- Protecting Your Start-Up From
Being Shot Down
Part 3
-
- Go To Part
1
2
3
4
-
- May 10,
2009
- By Eric M. Scharf
-
A Business Model for All Business Models
You may have received consultation on the proper direction for your
business model resulting in a cautious and careful business
approach
designed to support only one type of game product, genre, and
hardware platform. There is nothing wrong with only biting off what
you can chew especially as an unproven start-up particularly if
you have not acquired enough reliable market data to make an informed
opinion about potential product skus.
Alternatively, your business model may
actually support many types of products / product skus (one-off, series,
subscription-based, expansion packs, social networks, casual games,
and downloadable content), genres (FPS, RTS, RPG, and MMO), and
hardware platforms (PC, Apple Macintosh, Sony PS3, Microsoft Xbox
360, Nintendo Wii, Apple iPhone, and Blackberry).
A business model that also supports and encourages diversification
of your game products into those categories which entertain and train
such as
serious games should garner additional attention and investment
from other traditional business sectors (such as education, finance,
government, medicine, military, science, social services, sports,
and the list goes on and on).
Such a flexible business model provides
a little extra peace of mind whenever you are dealing with an
oversaturated or unpredictable market place where local and global
economies are struggling and businesses are in a bloody knife fight, competing hard
for consumer cash. Think remember?
Production Cycles
Establishing unique product types, genres, and hardware platforms
during the creation of your business model also encourages you to
acknowledge the unique production cycles in which you and your
co-founders may one day find yourself knee-deep. Product types
dictate production cycles, which can vary from three months to three
years or more. Production cycles in my experience do not include
the pre-production phases of concept and prototyping (which
should be derived and padded from any-and-often-necessary
"vertical slice" effort). After further research,
if the first product you aim to create requires
more first-round funding than you originally estimated due to
longer pre-production and full-production cycles then, you have two
realistic choices.
You can augment the figure you have
requested from your potential financier, providing a detailed
explanation and hoping he does not balk, or you should select a
replacement from the remaining product types supported by your
business model. Common sense and your immense feeling of
responsibility are what should snap to attention in this scenario.
Your business can end before it even starts if you allow your
passion for the product to override your responsibility for the business. This mental reminder needs to be
front and center at all times for a first-time company owner, who
(in the absence of an experienced and well-connected mentor) is
most likely reliant upon curious, toe-dipping venture capitalists and angel investors
rather than established, guidance-providing game publishers (who can
often be no better and potentially worse at their end of the
still-bottom-line games industry).
Life Cycles
The establishment of production cycle guidelines for your first game
product brings you to the life cycle of that product. This should be
identified for the purpose of determining whether your product will
receive life-extending downloadable content, expansion packs or in
the case of a subscription-based MMO ongoing (quarterly) content updates.
This decision can affect what your team needs to accomplish during
your initial production cycle, which can also force you to revisit
and re-factor your original funding projection. You do not have to wait for additional
funding to determine what is best for the future maximization of
your product.
Resource Requirements
Once you have determined your initial product life cycle, you should
move onto resource requirements, or what types of team-wide skills
are needed to deliver your product as envisioned. You ideally have a
team of people who all have robust skill sets within their given
disciplines, in-depth experience with multiple engine technologies
and a variety of developer / production tool sets, along with best practice
approaches to interdisciplinary product development.
Your team, of course, is also
highly communicative, capable of individually and collaboratively completing tasks without oversight, and willing to
give / take instruction
on the spot. This quality of depth will allow you and your team to
choose from a broader range of commercial game development tools
(engines, middleware, and various other common use licensed software
for all disciplines) without so much concern over a given learning
curve. You will only have to rely on proprietary
alternatives as a last (but not ill-planned) resort, and your team will have the
confidence and skill to deliver such tools if necessary.
You may have all the confidence in the world in the team you have
assembled (based upon previous working relationships and reliable
references), but this does not prevent the possible discovery
you may need a wider range of skills than your team currently
commands. Objectively the sooner you find out which block of
cheese your
team represents (solid cheddar or holy Swiss) the sooner you can protect
your team, your product, and your company through proactive personnel adjustments.
There is no
cosmic law that says you can or should allow your founding members
to wing it on a major core task that is beyond their skills.
Everyone from your financier to your teammates has a stake in
and responsibility towards your
success. It is your right and obligation from your position to
be ready to take the necessary steps to protect everyones
investment.
Reality dictates, however, that you may very well end up with a
mixed bag of leadership, talent, communication, and teamwork skills
spread unevenly among your founding team members. You may not have
been given lemons but with the unpredictable nature of the games
industry you are either making the best lemonade possible or making it
sweeter.
In any event, if you determine that additional non-founding
team members need to be hired to reasonably fill in the game
development blanks, then, you should do so. The fact that you
identified the product type most reasonably within your teams
capabilities early on will certainly help you identify, in turn,
which resources are missing or need to be reassigned for better
productivity.
The resource requirement parade, unfortunately, does not end here.
Each product type has its own custom headcount due to the enormity
of one product type versus another (e.g. "Mafia Wars" versus
the "Star Wars Galaxies" MMO). The general headcount approaches a bare
minimum of 30 to 45 people for your AA and AAA mainstream
entertainment software development teams. Team sizes commonly
reaching 50-60 and as high as 150+ especially for some MMOs
(including both temporary and permanent Community Management / Live
Services / QA
staff) when approaching the home stretch of production with the
Gold Master deliverable in sight.
Of course, the larger your product type, the larger your studio, the
larger the necessary infrastructure, and the more middle and upper
management team members are required, so that your core development
team is not overwhelmed with competing tasks. Nonetheless, as long
as you have been on with yourself and your funding source regarding
minimum and optimum resource requirements, you can move onto
resource valuation.
Resource Valuations Perception VS Reality
You have identified whether or not your founding team has the chops
to properly address the requirements of your first product, as well
as a second best choice if necessary, as discussed earlier. Your
team may primarily consist of close friends, which can be great for
loyalty and potentially disastrous for compensation purposes. No
matter how professional they may be, your friends may expect a far
more generous compensation package than can be factually, fiscally,
professionally, or personally delivered. Your friends may also expect some level of
favoritism over all other future employees, no matter the
circumstances.
Do not go into business with your family . . . or your friends
unless you have, again, first established a solid company
infrastructure in which as much as is reasonably possible has been
pre-defined and from which you can recuse yourself to neutral
territory when necessary. You do not want to lose quality teammates
or loyal friends over perceived value versus reality. If you are
attempting to adhere to the points I have introduced in this
article, your true friends will understand and appreciate that you
are, in fact, looking out for everyones best interests.
While it is one thing to identify your teams current capabilities
and apply a reasonable financial value to them, it is another thing
entirely to be able to identify their long-term value; what they may
accomplish for you above and beyond assigned product development
tasks, from A-Z.
You are compelled to make a collaborative determination with each
team member on the potential growth of your teams individual
skill sets, establishing their deeper, peripheral, and fringe game
development interests. I always want to learn of those interests
whether I am building a start-up team or inheriting an established
crew. I always ask everyone to share their interests in the
following format:
Primary Skill This is the reason for your hire and, ideally, what
you enjoy the most.
Secondary Skill This is an auxiliary skill you can perform just as
well as your primary and one that you enjoy enough to potentially
explore other areas within your discipline.
Emergency Skill This is an unglamorous skill you employ only when
the development chips are down and your team needs someone to fill
in due to an unexpected event (underestimated task or unforeseen illness).
Wishful Thinking This is a skill or set of skills you would love
to pick up when all other priorities have been completed which may
lead you into an entirely new discipline or into a greater role
within the team.
Those interests can manifest in the form of future proprietary
capabilities such as custom scripts, tool creation, or refined
animation prototyping technique which all can safely accelerate
your production cycle by leaps and bounds without negatively
affecting the quality of the assets being produced. Those
interests can also identify future sources of team leadership for
those team members who can look the big picture in the eye without
blinking and even public relations . . . for those team members
who can carefully channel their product passion into crisply
delivered trade
show demonstrations and speaking engagements.
This is valuable information that does not necessarily show through
in the form-fitted resumes you have on file. While some people feel
this kind of list is incriminating and enforces specialization,
others feel empowered by this list as positive public proof
of what they can do and what greater achievements they may
accomplish in the future.
You should have personal meetings with each of your founding team
members specifically to define those interests and candidly hash
out any misinterpretations before fully committing to each other and
to your available funding. The results assumed to be positive and
professional will help you devise specific invention and
performance clauses that provide appropriate incentives as part of
your compensation plan for each team member.
Go To Part
1
2
3
4