A growing number of MarTech (the blending of marketing and technology) solutions are suffering from what product managers are calling “arrogance.” These solutions are designed as if they should serve as a central point within a marketer’s stack, which is slowing users down. There isn’t a single marketer in 2019 who will be only using a one point solution. This is, according to Rasmus Skjoldan, Chief of Product Strategy for Magnolia CMS, fueling a movement towards more “humble” software.
Rasmus Skjoldan shares his thoughts on why marketers need more humble solutions and, what developers can do to build meaningful integrations that enable a more seamless workflow.
Digital Journal: What are the key challenges when it comes to getting different software to work together?
Rasmus Skjoldan: When it comes to getting different software to work together, there are two main obstacles that companies need to overcome.
For one, most applications are designed with an “egocentric view.” Meaning, nearly every software vendor tries to make their solution the center of the stack. This ends up causing friction for users who work across multiple applications.
Second, few companies examine how software can fit into the business process more seamlessly. Not only does this make it difficult to look at business processes as a whole, but it also makes it difficult to figure out the right way to make software work cohesively for practitioners. Focusing on the business process from a holistic point of view will directly improve the way software works together.
While most companies aren’t at a stage where they can talk about optimizing their stack (because, quite often, it isn’t considered an urgent priority), many are now realizing that it’s impossible to deliver a world-class customer experience without first creating a first-rate practitioner experience. You simply can’t play a concert without having the right instruments.
DJ: You speak of ‘humble software, what do you mean by this?
Skjoldan: The idea behind ‘humble software’ is getting applications to work well together. For decades, what I’ve been seeing in enterprise software, is that vendors are marketing their software to customers in a way that makes the application appear “central” or “foundational” within a customer’s stack. Now put two central products next to each other and what happens? You will see software you paid big money for starting to compete. This causes a pull on employees who have to operate that software.
The way I see it, this boastful approach is problematic because cross-application usage is always needed. If everyone is trying to be the “alpha” in the group, the dynamic between different solutions is fundamentally screwed.
Humble software, on the other hand, is specifically designed to serve workflows spanning across multiple applications. As a practitioner, you always have to work with software outside the suite, even if that suite promised to deliver all of the functionality you need. By implementing humble software, practitioners have the ability to integrate not only on a technical level, but on a workflow level.
Humble software also helps companies mitigate or even avoid vendor lock-in. It’s common practice for vendors to “lock-in” customers, or make it difficult to switch providers. Humble software goes against this trend because it assures customers that it’ll be possible to move your data out of an application if it’s better suited elsewhere.
I’ve seen many companies frustrated with the tools they have, yet refuse to stop using them due to fear of project migration. There are too many risks involved. We must develop a new kind of software that doesn’t lock-in customers the way they’ve been imprisoned for decades.
DJ: How can such software assist the business process?
Skjoldan: Companies tend to purchase a lot of software, but only use a fraction of it. So, it’s not uncommon for software to be bought and never fully deployed, or even deployed at all. This often occurs after practitioners realize the application they purchased has workflow problems or doesn’t quite work for their business processes.
This is one of the underlying reasons we’re developing more humble software — It connects business processes because it is open to workflow cycles from one application to the next. We advocate for using service design practices, where you look at a business process as a whole and figure out where specific applications fit into it. Essentially, we’re turning things around by saying the business process is what’s important, not the software itself.
Quite often, when you look at how software is being marketed and sold, it’s hyper-focused on itself and its features. Buyers should instead look at optimizing cross-application software workflows first, and then figure out how individual features can work in unison to fulfill whatever business process they’re looking to accomplish.
DJ: How can developers produce this type of software?
Skjoldan: It’s important that developers work with UX, service and process designers. Humble software isn’t going to become a standard from an engineering standpoint alone. Developers need to work together with people who deeply understand the more holistic view of how business processes work and what makes them work well.
DJ: Why is Magnolia 6 a good example of this?
Skjoldan: Magnolia 6 is the archetype of what humble software should be. The technology is developed to connect extremely well with other applications, not only on a data level but also on a user experience level. It’s common to see organizations running through an in-depth strategic process to figure out how to optimize a business process or how to run a specific initiative. Then, in the very final phases, the entire strategy fails. This happens due to the overwhelming amount of signals and interactions that a marketer has to make sense of when working with the software put in place to operationalize marketing.
That’s why Magnolia is so focused on making sure you can take the most important data from other applications and feed it into your Magnolia 6 workflow at just the right time and place. The system also exposes features and data that other applications can pull from Magnolia, so the integration extends both ways. We don’t see Magnolia 6 as always being the central solution, we’re also a source of data for other applications.
