Why Platform Teams Need To Be Built Differently
Managing operational (in)flexibility
Mark Sage - 10 min read - 05/10/2024
Steve Jobs is quoted as saying, “Great things in business are never done by one person. They’re done by a team of people.”
When we talk about the results of a loyalty programme — whether a successful launch, glossy new app or lift in spend — it’s good to remember that these things happen because of the team that sits behind it. The team that made sure everything was working. The team that setup every offer, configured every campaign, wrote every word.
This team is typically made up of a number of teams — marketing, product, operations, CRM — all of whom need to work together seamlessly as a team; creating a form of operational flexibility.
On yuu Rewards, like many loyalty programmes, we were creating 100’s of pieces of loyalty content every month. Whether new campaigns, new offers, new rewards or new app updates; the fact that these all worked as intended, almost 100% of the time, wasn’t an accident.
Ironically, in order to build a team with operational flexibility, we had to start with a high degree of inflexibility.
To operate anything, you need a set of instructions — and a loyalty programme is no different. Whilst we had quite flexible systems, the orchestration of these to deliver a single outcome like a points promotion needed to be written down — to be codified.
It was this part that proved to be the toughest deliverable because, whilst everyone could agree we needed a flexible marketing machine, there was less alignment on what that actually meant.
It’s easy to say you’d like a “category spend stretch promotion”, but less easy to say how it could work across multiple POS systems, banners and customer touchpoints. How it would be tracked, measured and reported. How customers could be targeted, informed and rewarded.
The first task then that we undertook, was to codify the different marketing mechanics.
What type of offer, reward or promotion would we support and how would it operate? What type of communications would we enable and how could these be orchestrated?
With 10 partners and over 50 different systems connected into the wider yuu Rewards loyalty eco-system, these questions were critical, as we needed to ensure that things would operate consistently for the member, regardless of the banner, channel or point of sale they interacted with.
We also needed to be able to balance the demand from the different partners, some of whom had a louder voice or perceived larger share than others.
Ultimately, we needed a common language to communicate our capabilities, agree on our capacity and allow the business to focus on the why, not the how.
To achieve this, we designed specific promotion and campaign types that had hard edges - by which I mean they were designed to do a specific job and to have a standard way of working. With an agreed set of inputs and outputs, this made it easy to say what it did (and what it didn’t) and also allowed us to train all stakeholders, including our own team, on the capabilities we offered.
Initially this was done to help us lock in launch capabilities that we could build, scale and repeat, however it also had the effect of ensuring that conversations with our partners focused on how to use these capabilities to maximum effect rather than getting lost in trying to constantly create something new.
The focus was now on ‘can do’ rather than ‘could do’.
As an example, for the loyalty offers, we created a set of promotional types that covered the different supported capabilities we wanted to launch with; both points and sales promotion-based, they differed in terms of their distribution and visibility. Each unique type was given a specific name so that it was easy to refer to and they could be separated out in terms of what they did.
Some offer types, for example, didn’t need the member to do anything to receive the offer — simply scanning their loyalty id was enough for the offer to be activated. Others were unique to that member and needed to be individually scanned at POS or activated within the app.
The key objective here though was to standardise the offer type itself — whether a unique member offer (known affectionately as a UMO) or a mass member points offer (an MMP) — such that there was consistency of customer experience in their usage and consistency of usage across every participating banner.
This approach to codifying the offer types seems simple now looking back, but it took a lot of discussion with the wider teams, as we were essentially asking them to lock-down their promotional ambitions very early on, so we could start to operationalise them.
We also took the same approach for marketing campaigns.
Creating specific campaign types that supported different channels like email or push, and supported different campaign ‘weights’ such as the number and variety of comms within it.
After a lot of back and forth with regard to codifying and sizing offers and campaigns, we got alignment with the wider teams — next step, we had to actually develop the processes to support them.
For yuu Rewards we were starting from a blank sheet of paper. There were no existing processes, no team as yet and all systems were new or in development. This wasn’t a simple case of just translating the marketing requirements around promotions and campaigns into a set of simple steps, we actually had to work out how the systems could support these requirements, how they’d be configured and how data would be retrieved and tracked.
In a sense, it was similar to designing a new recipe. You have all these different ingredients, techniques and tools and you need to bring them together into a single set of instructions which deliver something magical (or at least desirable)
When developing that recipe, you typically need to experiment a little first. Understanding what works well together, where you might need to add something more, and how to tune it so that it works, is repeatable and ideally is as fool proof as possible.
This recipe can then be followed time and time again to deliver the same result and can be followed by anyone who feels confident in using the tools and ingredients available — even if they don’t feel they are a chef!
This was the approach we took to developing our recipes for loyalty operations within yuu Rewards.
For every marketing activity we wanted to be repeatable, whether setting up a new partner, a new promotion or a new campaign, we created a separate recipe — something we called a ‘Way of Working’ (WoW).
Essentially a form of Standard Operating Procedure (SOP), each WOW document covered a specific capability within the overall flow and was designed to clearly map out the small number of steps and owners involved to complete the task.
For the individual steps, where required, we implemented detailed Work Instructions (WI) which were to be used by a single role, to do a single part of the process. By design, we looked to minimise hand-offs across the team and so a WI document could only have one role associated with it.
As part of the Ways of Working, we built in the ‘Four Eyes Principle’ which meant split roles so that someone was assigned the Setup Role and someone else the Reviewer role. The responsibility of Reviewer was to ensure the configuration had been completed correctly, and acted as a second pair of eyes on the process. Most importantly, they were accountable for publishing, so ultimately the buck stopped with them if something was launched with incorrect settings or content.
This separation of duties approach helped to balance speed with quality and was something that post-launch, worked well in minimising the number of configuration and communication issues we encountered.
Each of these Ways of Working were given a points sizing in much the same way you would score a story in agile development. An SMS campaign was 1 point, an email with an offer may be 3 points and a mixed channel campaign at say 10 points. The aim was to attribute a relative ‘cost’ to the activity which we could then manage resource against within the operations team.
The assumption here was that the team may (and should) become more efficient, and so be able to burn through more points over time, but the relative sizing or complexity of setup was kept the same.
By codifying these activities and sizing the setup, it allowed us to ensure that each banner had an allocated capacity (in essence a number of points per month) and that we could manage team capacity and throughput. New team members would have a lower velocity in terms of points and so as the team changed and grew, we were able to plan ahead with regard to how much activity we could manage.
Like many things when you’re just starting out, developing this approach wasn’t plain sailing and something became very apparent to us which was, within a start-up environment, not everyone makes it to ‘norming’.
With the launch date looming ever closer, we had an increasing focus on our operational readiness, which was heavily dependent on the Ways of Working documentation — but unfortunately these weren’t forthcoming.
When following a recipe in a cookbook, you have a level of confidence because you know that the recipe has been tested — the right mix and blend of ingredients to get the best taste; the correct temperature and cooking time to get the best consistency. You’re essentially relying on the work someone else has done, work they probably spent many hours and many iterations perfecting. If you suddenly find you don’t have a specific ingredient or your battery dies mid-cook, many of us will feel less easy to just ‘wing it’ and start filling in the blanks.
We might love cooking, but we’re less confident on being the chef!
With less than 4 months before launch, this was exactly the challenge we were having with developing our Ways of Working; there was no recipe and no pre-defined ingredients.
We were asking people to cook — to develop the right mix of processes to bake a new offer or campaign — but expecting them to also be the chef. For some, it was an expectation too far and the prospect of trying to ‘wing it’ was too much.
Within my team, I had lost another two members which now meant that almost 50% of the newly hired operations team — albeit small at this stage — had turned over before we’d even launched.
Reflecting on the reasons for this high attrition rate, it became clear that I’d fundamentally hired a business-as-usual team to do an implementation job – and these are two very different skills.
We were basically a start-up. Although we existed within a large corporation and had experienced people, setting up a new business is very different to running it. Different skills and different approaches.
Within a start-up you’re essentially executing on a strategy — something that doesn’t yet exist and yet you need to be able to implement it — and for many, building something from nothing is hard.
It requires that people are able to see clearly what is needed, before it exists, and have a roadmap to get there — all whilst operating in an environment of uncertainty and change. It needs people with the ability to get things done, work across responsibilities, challenge assumptions, make decisions. It needs people who can work with a gut feeling or intuition as there are no existing rules and no existing ‘standard operating procedures’.
These aren’t skills everyone has and aren’t areas many people are comfortable working within. To help alleviate this challenge, we needed to identify where these skills lay, source in where they didn’t and co-ordinate them with robust project planning to keep things on track.
What’s interesting is that for the most part, these skills wouldn’t be needed as much after launch and so this wasn’t a profile we wanted to recruit across the team — but it was one we needed to source for specific roles.
For everyone else, we still needed people who could operate this programme when launched, and this meant they clearly needed to be involved before launch to enable a seamless handover.
So the challenge we faced was how to create a team that could setup all the different ways of working — creating and inventing new processes — whilst also being trained to run these processes post-launch on a day to day basis.
Clearly some people are able to do both — these are change agents who would add value post-launch in helping to keep the program fresh and who are also great at operating too. If anything, the risk with these people is that they get bored after launch and want to do something new.
For many people however, they simply want to work within a defined structure with well-defined boundaries and well-defined processes.
They thrive on doing things well, but don’t necessarily want to decide what those things are. We needed these people, as we needed rock solid execution with a rock solid ‘business as usual’ (BAU) team — but we needed to setup that environment, both for them and with them.
We also had to be conscious of that potentially ‘listless’ feeling they may have during this setup period, given there weren’t yet solid ‘ways of working’ and specific roles.
This was a tricky balancing act.
So how to build a team that can implement the programme and ultimately run it?
The answer lay in blending the team with implementation specific temporary resources who had the skills and confidence for that role, and pairing them pre-launch with a mix of BAU resources who would ultimately go on to run it.
Across CRM, customer service and operations, we recruited contract team members with agency side project experience, who were comfortable creating something new, and who also had typically decades of expertise in their specific area. We then combined this with a peer working approach so that BAU team members were ‘buddied up’, helping to ensure that there was a skills transfer, a confidence in abilities and also longer-term ownership.
Most importantly, these implementation specific resources didn’t typically head up an area, but instead acted as subject matter experts.
In this way, the BAU team-leads retained their responsibilities, and were ultimately accountable for the delivery — both pre and post launch — whilst also being more settled with the uncertainty of implementation as they had confidence, literally built into the team.
Creating this operational flexibility which allowed yuu Rewards to excel as a programme and as a team post-launch, meant we had to be flexible pre-launch in terms of team design and team dynamics. Recognising where people excelled, and supporting them where they didn’t.
Overall, this approach helped to ‘steady the ship’, reducing team member churn as well as ensuring we still had a timely focus on delivery and a successful launch.