A game developers' guide to working with clients

Abstraction has been in the platform adaptation business for over 12 years. We have extensive experience in dealing with the challenges in, as well as capitalizing on, the opportunities presented in porting, co-development work, and multi-platform development.

With over 160 SKUs on over 15 platforms, we have been the go-to company for games like Angry Birds, Ark: Survival Evolved, Hotline Miami, Total Reliable Delivery Service, The King of Fighters XIV and many more.

So, let's talk about the production side of Abstraction. Successful production management really boils down to three key things:

1. Clarifying goals, expectations and ownership
2. Enabling the team to achieve those goals
3. Learning fast from the successes and failures

This is the core of successful production management of any project -- beyond just multi-platform adaptation work, or even games in general. We argue that these three missions of production management are industry agnostic. Without these three explicit directives, any project is going to face unnecessary inefficiencies.

The best strategies for achieving these directives, however, differ depending on who you are partnering with. We have found that clients who partner with us on multi-platform adaptation work tend to fall into four categories, based on two different spectra:

• How much experience they have themselves in multiplatform development
• How detail oriented they are about the project itself

These two spectra get us a nice four quadrant graph that helps classify partners:

The Learning Partner

Whether it's out of anxiety or interest, a partner who is new to multiplatform development, and is very interested in meticulous details is likely just trying to learn how this all works and add to their own skillset and efficiency.

Successful collaboration with this type of partner requires:
• Thorough documentation of deliverables, processes and risks
• Liberal access to project tracking and status information
• Frequent communication
• Proactive 'calls to attention' of areas where the client can mitigate problems

Clarity focus: Oversharing
Very simply, tell them everything you can and make exposing information from your processes and team easy. Transparency and visibility will engage your partners learn-lust and quiet most anxieties they have about their own lack of understanding. Carefully enumerate the finer points of platform specific work, such as approvals processes, expected timelines, and so on.

Enablement focus: Noise Management
All the information sharing can create a lot of interference for your dev team. Shaping communication traffic away from them will be critical to success. A successful producer will make as much information radiant for the client without requiring contact with your busy developers. Fast learning focus: Awareness

While the iterative learning cycle should ultimately focus on whatever unique, specific opportunities a given development presents, a good general focus is on awareness and improving it. Focus on what you as a producer can do to provide greater low-impact awareness, and what your partner can do to further their own understanding.

Abstraction War Story
One of our Japanese clients was less experienced with PC development and asked us to help them bring their title to Steam. There was of course the typical thorough documentation on what was expected for each deliverable, but they also wanted to know the state of the project as frequently as possible. We are always transparent with our clients, so we gave them access to our JIRA database to ensure they could always see what we are working on and discuss priorities with them if needed.

However, the biggest hurdle was the fear of information getting lost due to the language and culture barrier. We mitigated this by hiring someone as a junior producer who was proficient in Japanese but had no work experience at all. With this we found a way to communicate with the client in their native language and had someone who could be trained to become a producer. Communication and expectation management with the client turned out to be painless, we signed another deal with them, and three years later this guy became a producer who writes GamesIndustry.biz articles now and then.

The Burnt Partner

This is the partner who has gone down the multiplatform road before and had issues, either with the platform holder, or their co-dev partner, or both. They are experienced but want lots of visibility to mitigate risks that they have suffered from in the past.

Successfully working with the burned partner requires:
• Lots of proactive communication about identified risks - even if they normally seem obvious or minor
• A conservative delivery schedule that gives ample opportunity to over-deliver
• Total transparency about processes and statuses

Clarity focus: Risk management
The burnt partner is always looking to avoid being burned again. Identify risks early and have mitigation strategies already underway when you bring them up. Even if you're an experienced developer, don't skip the risks you consider obvious or trivial - doing so may raise alarm bells with your partner.

Enablement focus: Absorbing client anxiety
As the development partner, you will need to get a clear understanding of what the client is anxious about and sympathize with them. Sometimes the client does not know themselves what they are anxious about and you will need to figure this out from the context. You need to stay calm and collected and give them concrete examples on why they do not have to be anxious.

Fast learning focus: Weaknesses
Just as exposing risk factors will make the burnt partner trust your handling of their project, exposing your own weaknesses and failures with proactivity is similarly valuable. It shows that you as a developer aren't making the assumptions or masking problems - both potential sources of their previous pain.

Burnt Partner Abstraction War Story
We have had several burnt partners that went down the rabbit hole of releasing products on several platforms. One of them wanted constant visibility and last-minute changes to be in for release. Initially we had some friction and issues on what we had to focus on, and the constant switching between tasks ended up being unproductive and destructive for the team. Throughout the project we created a roadmap with insane granularity that showed what the client dependencies are and how long tasks and features would take. Furthermore, the roadmap would also dynamically update dates and deadlines if you changed any data on work or dependencies. Even though this helped us mitigate most of the problems we had, the granular approach meant we had no room for overdelivering and is not recommended.

The Blind Partner

This is the partner that simply doesn't know what they do not know and is generally the most difficult to work with. An even scarier variant of this partner is the one who believes they are not blind. These are usually the most challenging collaborations.

Success here relies on:
• Frequent, diplomatic calling out and addressing assumptions you or your client may be making about development or platform specific requirements
• Proactively raising problematic deliverables well in advance
• Driving partner deliverables and action points

Clarity focus: Challenging assumptions
The blind partner will often make unconscious assumptions about ownership, process, and timelines. As a good partner, your job will be to call attention to and check these assumptions. Proactively dig into the details of deliveries and ensure that everyone involved knows exactly what to expect and when.

Enablement focus: Mitigate client-created risk
As the development partner, it falls on us to look out for even the obvious 'to do list' items and ensure they have explicit owners and shepherds.

Fast learning focus: Humility
A productive angle here is a little self-deprecating admission of failure, which creates an environment where it's safe for others to similarly examine themselves. Tell hard truths in ways that they'll be heard.

Blind Partner Abstraction War Story
A good example is one of our previous partners that requested their browser-based game to be adapted to touch devices. The biggest reason for this partner to be 'blind' was that this was a company not part of nor accustomed to the games industry. This, in combination with showing little-to-no understanding of our explanations as to why the adaptation was not straightforward and instead only demanding unrealistic deadlines, made it close to impossible to get to a successful end result of which everyone involved would be proud. This game was built with little-to-no room for expansion in cross-platform functionality, and required swapping engines and a near full rewrite of the codebase. The amazing efforts of the team were unfortunately not always understood by the client and, after many attempts, we ended up parting ways.

The Trusting Partner

Whether it's because you've earned it or not, this is the partner that is just counting on you to get the job done, and isn't particularly interested in -- or maybe doesn't have time for -- the details associated with this.

All else equal, these are the best partners to have, and succeeding here leans on:
• Driving partner-based dependency elimination
• Proactive reporting
• Ambiguous ownership = your ownership

Clarity focus: Signal to noise ratio
It is as simple as clarifying with the client what they want to know, how often they want to know and how they want to know. For some clients, a weekly report with broad strokes of how development went is enough, while others might want to have a more personal bi-weekly call to touch base. Often, and quite naturally, the frequency of information sharing will increase as you are heading towards the submission and certification process.

Enablement focus: Thorough requests
Based on your and the client's previous experience, you have already thought of most of the angles, did proper research and presented the client with a clear proposition of what you need. You need to make sure that an excessive amount of back-and-forth will not be required, which should not be the case since you should have a good understanding of the client's requests and wishes.

Fast learning focus: Preserving trust
This should be true for all types of clients, but your internal retrospectives should be laser focused on maintaining and growing the trust that you have with the client. Mutual trust is a core component in delivering a high-quality product that both parties are satisfied with and should always be preserved regardless of the circumstances.

Trusting Partner Abstraction War Story
One of our most recent and technical challenging projects was on a big title with a trusting client. We worked on a previous project with them before and even though there has been mutual trust from the beginning, it was properly fostered throughout the duration of several projects by always being transparent and fulfilling promises we made. This technical challenging project blew up in all ways imaginable, but it was due to our good relationship and mutual trust that both parties pro-actively investigated how we could mitigate as much damage as possible and still deliver a high-quality product. They trusted us in being upfront and honest in what can and cannot be done within the given boundaries, and we trusted our client in being understanding and trusting our technical capabilities.

Want to know more about the way we work? Get in touch here.