How we help product managers create fan engagement MVPs that can replicate and scale globally without code branching headaches

Some of the global event centres we manage for our customers IMG Arena and Liverpool Football Club

Who is this aimed at? — This is something of a behind-the-scenes explanation of how we tackle versioning and app variants at Monterosa. It’s one of our hottest topics and I’d love to know your thoughts. This is most relevant if you’re involved in creating web or native apps which could be destined for multiple contexts at once.

What is the context? — In the world of big format sports and entertainment properties, or the brands that partner with them (I’m sure many other sectors too), often a digital product starts life in one discreet context. Then, once deemed successful, it needs to be deployed or scaled up into other countries, languages, designs or contexts. Even in the first deployment in one region, you may find a need for multiple flavours of the same experience, each with differing languages or appearances.

That ain’t easy!

So you get your MVP working and it’s a success.

Ok it works, now roll it out! Oh what, I have to wait?

To set some context, here are a few examples where rapid, multi-variant rollouts are needed:

1. An entertainment format that travels — imagine a format like ITV’s Love Island, dependent on its native app for voting, exclusive content, community and ecommerce. It made its name as a reality TV show in the UK and is now all over the world. It had to go from one instance to 10 within a short space of time. Non-TV travelling concepts can follow the same pattern.
2. Brand / sponsor activation — in some cases, multiple instances are needed from the start. When a brand customer like Vodafone wants to activate a campaign around football in the Middle East, they will do everything in both English and Arabic, right from the get go. Language might be one dimension, but also content, sponsor visuals and messaging.
3. Sports leagues or federations — a sports league might want to provide the same native app to its teams — each will have options, different visuals and different features. Of course, it doesn’t want to split off the underlying app into 20 different instance, but there are plenty of examples, naming no names, of this painful and expensive scenario.
4. Voting Events — a media company or brand wants to run a voting experience for an award show or a sporting accolade on their site and in their apps across all territories, with the results and user data all fed back into one place. Something we do frequently with Nickelodeon for instance the Kids Choice Awards.
5. Sports Data Companies — often a data owner wants to add value to pure data by creating embedded apps or widgets, maybe full-on event centres. Typically they need to be deployed many times quickly for each customer in any language or any visual appearance. We do this for IMG Arena for example.

For simpler experiences, and for big development teams, this might all seem quite manageable, even a nice challenge. But for those that need to handle massive capacity levels, provide real-time communication and enterprise-grade reliability, support AND deliver quickly, it’s a major headache. You need expertise, resources, budget and lots of time.

The code branch death spiral!

As every product person knows, each time you branch code you end up with a maintenance overhead. Plenty of DevOps options out there to streamline this but the bottom line is, fixing a bug or adding a new feature in more than one place adds time effort and risk. It has to be merged, tested and deployed again and again for every variant. Over a handful of parallel branches it can be a death spiral for efficiency and costs.

So — a web app or native app that needs to be different depending on where it appears, therefore needs to be setup with that in mind from the start, with configuration of a single application the goal.

“Fine, we’ll make it all configurable” — tech lead.

Of course you can..but this level of productisation to a new application adds significant cost and creates bulk. If it needs to be totally configurable, that means creating a CMS of sorts, or configuration manager to allow content people to control the settings of the product. This is usually solvable, but it takes time and effort to get right.

The Lean Conflict

“Let this simple rule suffice: remove any feature, process or effort that does not contribute directly to the learning you seek.” — Eric Reis, The Lean Startup

When a fan engagement experience, game, or some form of participation application is having its first run out, it’s often seen as a test, or an MVP. Lean methods taught us not to build in all that capability upfront!

So if you follow this advice, you build it without these things and it’s successful….you’ve got to almost start again or at least overhaul the application. Not always practical or desirable for established businesses with massive audiences.

“just make something simple and see if it works” — Management

Senior management rarely want to get into the details behind the story above and of course they don’t want to blow budget prematurely. YET, when the time comes to deploy more widely, they have short memories and can’t understand why it’s going to cost the same or more again and take months.

Even if you do have a cookie cutting machine of sorts, it’s designed to make one type of cookie. If you need to roll out AND develop the type of cookie, they’re probably not going to understand why everything slows down.

A cutting machine to make cookie cutters

We encountered this problem so many times, and went through so much pain, that we eventually built a solution in the form of our platform — the Monterosa / Interaction Cloud, now in its 6th year.

There was no point building a cookie cutter because we didn’t know what type of cookies we’d want to be building. We needed a cutting machine to make many cookie cutters, so we built one.

The capabilities we’ve generated have taken many years to mature. Now all our applications are created in a way that sets them up for scale from the start — WITHOUT incurring the massive levels of extra time or effort usually associated with the challenge. It’s orientated around a set of five capabilities, with two new ones in beta now.

1. Persistent connections — all applications are built on secure WebSockets using our EnMasse Mesh infrastructure of AWS-hosted edge notes. They maintain connectivity to every user where appropriate and respond to requested changes instantly. There’s no such thing as a refresh.
2. Dynamic App Setup — runtime configuration. Every application running on the Monterosa / Interaction Cloud is persistently connected to its own App Setup within its own dedicated Project. If the App Setup changes on-the-fly, the app is made to reconfigure itself in real-time.
3. Easy App Replication via Projects- to create a different configuration of the same app, we simply create a new Project, associate it with the app or web app, and it gets its own App Setup.
4. Locale support — every piece of interactive content can be setup in multiple languages concurrently, and every configuration value can be different depending on the locale. So you can have a different sponsor logo depending on the country for example.
5. Self-Service Build Time Configuration — for both web and native apps, when more flexibility is needed, we have specific build workflows for non-developers which involve vast levels of configuration options. In the case of native apps, we can deploy the entire application in a unique manifestation visually, with differing features each time, without any development at all. A designer uploads their assets and out comes a binary that is then further dynamically configured at runtime as above. Therefore, 10 wildly different flavours of a fan engagement or sports team app can be created from the same code base — meaning one set of maintenance and everyone gets the benefit of new feature development.

In the latest version of our platform we’ve taken this to the next level. Now, one application can be self-serve deployed by anyone in the platform. You pick an Experience template, which is a set of pre-configuration options and content for a web app or native app, and the system spins up a Project ready to be setup by anyone.

Behind the scenes, it can now build a native app and text you when it’s ready. It can spin up supplementary services like Push notifications or vote Certification, ready for production launch. Now, a product person can spin these variants up without needing Engineering to get involved.

Now, product or content teams around the world or in each state, team or regional location can pick from their company’s set of enabled apps, and tailor them, without code. Like this:

Experiences, ready to be picked and deployed

We’ve also created a unified data lake underneath, so that every application’s behaviour can be aggregated and then connected via data pipelines into the customer’s own CRM or identity system. It means that in future, all data integrations can be backend-to-backend, again reducing the need to mess around with front-end variations.

International or multi-variant rollouts is just one topic in a set of scaling challenges that cause our customers the most pain and where we’ve found a way to provide a great solution — the other two are concurrent capacity scaling and multi-timezone support, which I’ll cover in another post.

Some helpful Monterosa / Interaction Cloud documentation links include:

• App Setup — dynamic configuration
• Locale Support — every field can have a locale variant
• FanKit — the underlying framework for all most of our web applications
• Fan Companion — the underlying framework for most of our native applications

Do comment if you want to know more!