When incorporating new systems and software into their day-to-day operations, it is not uncommon for organizational end users to take what they were given and just run with it. Like the Oklahoma Land Rush, a user base is unleashed and bravely races off gloriously to who-knows-where, laying claim to various corners of the new territory (truly new in this case, as opposed to the metaphorical one), only to build shoddy dwellings and start shooting each other over turf wars once they get there. Also, the CMO just came down with typhoid. This is where my metaphor falls apart.
Back to reality. An implementation team defined the system requirements, setup the servers, carried out design sessions, finished user acceptance testing, performed comprehensive education, perhaps even held a launch party with free donuts (or maybe even a happy hour, if leadership is feeling frisky). “Go forth and stake your claim!” All done, right?
In the case of marketing operations and execution software, the answer is a definitive “no”. Unfortunately, many organizations do fall into the trap of never moving beyond their initial assumptions and standards, or even worse, carry on with a total lack of standards where they may not have even known such definitions were needed. The fallout from this manifests itself in many different ways…
- It could be as simple as the organization never fully realizing the benefits of the tool
- It could create an increasingly difficult-to-manage system environment
- It could create confusion amongst users who are applying their own approaches and habits
…but worst of all, one or all of the above could ultimately lead to the tool actively creating friction in marketing activities (which in direct conflict with the very purpose of these systems).
In order to mitigate these issues, a process of design innovation must be considered a critical piece of the ongoing usage of marketing system software. This means a couple of things:
Defining and documenting usage standards: In many cases, not all objects or fields in a marketing system that are worthy of a naming convention actually have such conventions controlled by the software. As such it is up to the users to apply such conventions. Further, a consistent approach to leveraging a system’s inherent documentation capabilities should be encouraged and enforced. Finally, if the system makes use of visual drag-and-drop type capabilities, then it is beneficial to have agreed upon layout standards and a system of governance to maintain it. The purpose of all of this is to create an environment that is truly multi-user friendly, and not just multi-user capable. By controlling and minimizing needless differentiation, collaboration is made that much easier, and thus the new systems that much more viable.
Another important aspect of design innovation is perhaps even more critical:
A consistent, controlled culture of constant re-evaluation and improvement: This could mean different things to different organizations and tools. It could include carrying out regular meetings or roundtables with users to collect complaints and new ideas, scheduled audits of the state of the system to identify gaps and developing concerns, internal education sessions so developers can teach each other “tricks” they’ve learned, and so forth. The key is to maintain a strict policy of explicitly seeking ways to improve. Given the ever evolving state of the typical marketing organization, if marketing systems and their application aren’t constantly improving/adapting, then they are progressively getting worse at supporting your needs (unless, of course, your marketing organization doesn’t evolve, which is a different problem altogether).
By following a defined regimen of design innovation, your organization’s new toys will better grow and adapt to changing needs, and further serve to justify the cost and all that effort put forth in implementing the software. Design innovation is the logical next step towards ensuring that shiny new marketing system meets organizational needs. It’s also better than typhoid.