From pitch to launch: Key takeaways for a successful development partnership

The world of mobile game development is ever changing, and in the 14 years Tag Games has been around we've seen it all.

We went from making indie games at a time when smartphones were still seen as a luxury, to working on massive IPs played by millions. We've seen the rise of the centralised App Store and Google Play, the emergence of free-to-play, and the propensity of major licenses migrating to mobile games in a way that just wasn't the case in 2006. To stay ahead of the curve in this increasingly competitive market, we've had to stay nimble.

Here are five key lessons in the lifecycle of a client project that we believe have been key to our success and contributed to our ongoing growth.

1. Prospecting: Build relationships and get on the radar

Fostering relationships with potential clients is key, and we are lucky at Tag to have someone dedicated to business development, continually building and maintaining good relationships. However small or large your company is, if there isn't someone managing client relationships and finding new contacts you are going to struggle to move from one project to the next. There are a lot of mobile developers out there, and you have to make sure you're on people's radar as they're not going to come looking for you out of the blue.

You have to make sure you're on people's radar as they're not going to come looking for you out of the blue

When you're pitching to a publisher, make sure you have the right people in the room for those meetings. Our team is made up of a range of skills and personalities who naturally fit into pitching roles.

It's important to have the person who is most knowledgeable about the product you are pitching, as well as someone there to back them up with numbers or data. It also helps to have someone who is knowledgeable about the publisher, can make everyone in the room feel comfortable, and keep the meeting moving as you ask some of the inevitably awkward questions.

At the start of my career, I was fresh out of university and went straight into pitching original IP ideas to the heads of large publishing companies. I was incredibly nervous when walking into a publisher's boardroom to pitch. It took me a long time to realise that these are just people who want to make a great product, so if nothing else you'll at least have that common goal. Just remember that you're in the room because they want to hear what you have to say.

2. Pitching: Immerse yourself in the IP and become an expert

Congratulations: you have received a request for proposal. This is a success in itself. Your team, track record and skills have qualified you to submit a game concept on a really cool IP. Remember that this IP is potentially the lifeblood of that company. They have fostered this IP over years and are considering their first game or the next installment of a franchise. Be it a TV series, comic book, film, or toy franchise, you must dive into its background and learn as much about it as you can.

When we worked with Mind Candy on Moshi Monsters Village it wasn't an IP that a studio of 20- to 30-somethings really knew much about, but as a team we all got engrossed with the world of Moshi Monsters and the weird and wonderful characters.

By providing a fresh set of eyes on someone else's IP, you are able to push the envelope

Over time, it was clear that Tag understood Moshi Monsters as much as Mind Candy, and this earned us more credibility. Art, design and feature approval became faster and smoother, giving the team a greater sense of ownership. That team soon started to feel like an extension of Mind Candy and not just a hired hand in Dundee, and this is what we try to get all our teams to think and feel with all our products such as Rick and Morty, CSR Racing 2, or Angry Birds.

By providing a fresh set of eyes on someone else's IP, you are able to push the envelope just enough to make a difference. For us, there is a balancing act with free-to-play and the IP. Often people think they want something revolutionary, but in reality, there are few free-to-play companies that will, or can, take a risk on releasing a product that doesn't have a known and predictable monetisation model.

Also, the IP itself will have some strict rules about what you can and can't do, so you really have to get creative to see what can be achieved and make an impact within those boundaries. As an external team, you can provide a much needed fresh outlook on what more can be done with the IP, that the owners may not have considered.

3. Project set up: Communication and honesty is key

There are very few issues that appear in a project that can't be solved without open and honest communication. It's so important to agree up front how often, what channels, and who should be on calls.

At Tag, we don't hide anything and believe that honesty is best. Our Jira -- or any other task tracking software the team wants to use -- is open to view by the clients. The sprint reports sent to senior management are the same reports sent to the client. In our experience, most issues actually surface because something isn't shared or communicated during development, be that an expectation or a limitation.

There are very few issues that appear in a project that can't be solved without open and honest communication

If change requests are repeatedly coming in, then you need to communicate what that is doing to the backlog and the potential of delivering on time. But more than that, it'll help you get to the source of why so many changes are being requested. What isn't working? What did we miss about the original expectations that led to so many changes?

Working hard on good communication has made it easier for us to transition from working together in one office to adjusting to working remotely during the COVID-19 pandemic. Our internal and external communication channels were already so strong that this global crisis has had very little impact on the delivery of our projects.

4. Development: Double down on the relationship

The relationship between a developer and a publisher has a reputation of being one-sided, but in our experience this is not the case. The best projects have a healthy balance between the development team and the publishing team. In fact, telling a publisher that a request is unreasonable, or that your team is not comfortable with the changes or schedule, is just demonstrating that you're looking out for the product in the long run. As such, we find that those push backs are respected and not something to fear.

If you are open and honest with all the stakeholders from the start of the project and ensure great communication throughout the development, collectively you can push through any stumbling blocks and find the best solutions to the problems that all development teams face. By addressing client feedback this way, each build should constantly be getting closer to their vision.

By working hard on your relationship with the client, they will understand that when you raise a concern with the product direction it really is in their best interest. They know that your team is committed to the IP and believe in the product, and trust your judgement when you spot something on the horizon that you believe is an issue for the project's success.

A good example of this is when a project takes a sudden directional change, via a new stakeholder or business decision. We've all been there. These things happen, but your experience tells you that this decision has the potential to put the product at risk.

This is the time to gather all the stakeholders for an all-hands meeting to discuss your concerns with the new direction and what you believe it will mean for the project. You've been open and honest with them to this point, so there's no point changing that now. Tell them how this change will affect the product. In the end, most of the decisions will result in a financial implication, a change in development time, a change of audience, and in the end money talks. You may not have the final say on your client's financial decisions, but you do have a voice -- use it.

5. Launch: Control the moving parts

Launching a game is always a stressful endeavor. Lots of things have to be aligned for the perfect launch, and you know that if something could go wrong, it will go wrong on that all important launch day. So prepare early. Load test your servers and check that your build machine isn't due for an upgrade on launch day. Dot all your "i"s and cross all your "t"s, ensuring that nothing can go wrong. Your launch day should be cause for celebration, not panic.

Your clients will likely be the ones controlling the launch, but we would always advise having a long, detailed chat and a checklist for what needs to be done on both sides as builds go up.

Who is checking that the version numbers are connected on build as on the store? Whose responsibility is it to move the staging server data to live? There are lots of moving parts in a live, connected mobile game, and everyone needs to be super clear about which parts of that machine are their responsibility.

Everyone hopes that a good client relationship will last for more than one project, and free-to-play products naturally have a longer tail, so work on one game could last three to four years -- or more if it's a success. It's often hard to take a long term view when you are in the thick of it.

Developing a successful mobile title is a tricky business, but it doesn't have to be. Working in collaboration with an external partner brings together two sets of collective knowledge and experience, which is a massive advantage. By being honest with your clients, respecting their IP, being flexible, and preparing for any hiccups along the way, you'll prove yourself as more than a work-for-hire studio, but a trusted steward and co-runner of these licenses. Follow our advice and you should stay creative, happy, and successful in this ever-changing climate.