Home History Blogs Portfolio FAQ Contact Terms Of Use
 
2008  2009  2010  2011  2012  2013  2014  2015  2016  2017
2018  2019  2020  2021  2022  2023  2024  2025  2026  2027
2028  2029  2030  2031  2032  2033  2034  2035  2036  2037
 
 
 
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 everyone’s 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 team’s 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 MMO’s (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 everyone’s best interests.

While it is one thing to identify your team’s 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 team’s 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