Why is It So Hard to Implement New Technology in a Creative Environment?

(And what does that have to do with your PDS process?)

I spent years working in advertising agencies, running complex production workflows. By the time I left in 2020, we were still using Google Sheets and shared calendars. We'd looked at other systems, and we'd done the research, but still nothing got off the ground.

When I moved into financial services consulting, I found myself working with clients who faced similar challenges. Different industry, higher stakes, identical root cause.

The process lives in the people

In an agency, the workflow can look chaotic from the outside but somehow holds together. That's because the knowledge that makes it work - who really signs off, what happens when a job lands on a Friday afternoon, how to handle a client who changes scope mid-production - lives in the people. The majority of agencies will have a pretty decent process document, but it’s the people who really make it happen.

Ask most product teams to trace a PDS update from trigger to lodgement and you'll get a version that covers the standard cases clearly and gets a bit vague around the edges. That's not a criticism, it's just how high-functioning teams operate. The institutional knowledge is real, it's just unevenly distributed, and often concentrated in one or two people who've been around long enough to know where every exception lives.

A new system can't absorb that knowledge. What it can do is create the conditions to surface it, document it and share it - if the implementation is approached the right way.

The workflow looks familiar

Product teams and PDS managers are not, by any stretch, process-averse people. The work of building and maintaining a Product Disclosure Statement is intellectually demanding in ways that don't always get the credit they deserve. You're making judgment calls constantly, maybe about how to explain a complex investment strategy in plain language, or about where the regulatory requirement ends and the genuine communication begins.

You care about the words, you argue about a single sentence and you know the difference between a disclosure that technically complies and one that actually communicates.

That's craft. It just happens to live inside a legislative framework instead of a brand one. And the workflow that supports it looks more like an agency than most folks in financial services would ever know! A trigger or the brief that starts the required work, be it a regulatory change, a new product, or an annual review. The strategy behind the change. Multiple contributors with different priorities and different definitions of "done." A review and approval chain that is rarely linear and almost always dependent on someone being available who isn't. And a final output that must be precisely right, lodged on time and defensible under scrutiny.

The stakes are simply higher. In advertising, a version control mistake costs money, embarrassment and an erosion of trust. In financial services, a material error in a PDS can mean the same, plus regulatory action, member remediation and a board conversation nobody wanted to be having. Not to mention the regulators knocking at your door!

The questions to ask before any decisions are made

Before any system goes in, a team needs a genuine shared understanding of how the process works. Not the ideal version, the real one.

Who owns the process? What does "approved" actually mean when three people have returned different versions of the same document? What happens in the exception cases that don't fit the standard workflow?

If those questions don't have clear answers before the new system arrives, it will inherit the ambiguity. And that ambiguity is harder to unpick once it's been baked into any new technology

No one liked to admit it, but a clear and documented Agency process was essential. It didn't limit the team, it focused them. A team that truly understood how the work flowed produced better work, faster, with fewer expensive revisions at the end. The same principle applies here.

Change management is the real project

Here's the part that doesn't make it into most implementation plans: a change to a new technology solution can only go as far as the people using it are willing to take it. And people don't commit to change they don't understand, weren't consulted on and can't see themselves in.

Change management isn't a phase you add at the end of an implementation. It is the implementation.

Technology implementations fail when people are treated as users to be trained rather than participants in the change. They succeed when the process is designed with the team, not for them, and when someone takes responsibility for the human side of the transition, not just the technical one.

What it looks like when it works

At Mayflower, this is where we spend a lot of our energy. The configuration of the software is obviously important, but having the right conversations before, during and after that happens is what will make or break how successful change will be.

With every client we've worked with across superannuation funds, fund managers and platforms, the turning point hasn't been the go-live date. It’s the moment when the team doesn’t see the new process and system as something that's been done to them and sees it as something they helped build.

That shift takes investment. It takes sitting with the team, mapping the real process, having honest conversations about what's working and what isn't, and co-designing something better before a single workflow is configured. It requires stakeholders to be consulted early, not informed late. It requires leadership to model the change, not just mandate it.

The teams that come out the other side aren't just running a better system. They understand why it works, they own it, and they're capable of running it without us and that's always been Mayflower’s goal.

The short version

Technology implementations fail when people are treated as users to be trained rather than participants in the change.

They succeed when the process is designed with the team, not for them and when someone takes responsibility for the human side of the transition, not just the technical one.

That's as true for a creative agency managing campaign workflows as it is for a product team managing a PDS disclosure roll. The output is different but the fundamentals are the same.