Plain vanilla apps - Do they even exist?

One of the main downfalls of large, monolithic on-prem software applications is their enterprise specific customizations. Often times, this led to the establishment of a code branch that was extremely challenging to support and essentially locked the customer into using the customized environment for many years. Indeed, WYSIWYG was one of the main selling points of SaaS applications, at least in the early days. Every customer, regardless of where they were, would run the exact same version as everyone else, leveraging a single unified code-base which was tested by the masses.

While this held true, at least for some time and at least for some SaaS apps, today’s reality has turned out to be very different. Talk to any enterprise SaaS application customer - CRM, ERP or HR - and they will surely tell you that the plain vanilla version that you see on that vendor's site bears little resemblance to the version they have deployed in their organization. Phrases like "night and day", "we don't even recognize the app anymore", and "our version looks completely different" are not out of the ordinary.

A recurring topic we hear from application system integrators is that the vast majority of application usability questions they receive are enterprise dependent and correlated not to the app itself but rather to the specific configuration of that enterprise.

The reason for this phenomena is something we call the Digital Triplet. The digital triplet identifies three virtual states for each software application.

1. As Designed - this is the version of the app as it was conceived by the product, design and engineering teams - the so-called "plain vanilla" version of the app that is used by a mythological, typical customer. This version is initially tested by QA teams and shown in product demos but is not the version that any organization ultimately uses.
2. As Deployed - this is the version of the app that was deployed, provisioned, integrated and customized within an individual organization. The deployment is often performed by the application vendor or a system integrator or by IT and operations teams within that organization. The idea is to adapt the application to the specific use cases and processes of a given company. In many cases, just the integrations to existing tools within the organization dictate substantial changes in the app behavior (e.g. if the app is connected to GSuite or to Office365 the overall behavior is going to be altered).
3. As Used - this is the version that the employees themselves within the individual teams are putting to work. This is where the team leaders are tweaking the unique capabilities of the tool for their specific work context. E.g. take a tool like Outreach and think of the ways it is used by an SDR for a DTC mattress company vs. the way that it is used by an SDR for a cybersecurity company - these are vastly different implementations even though the mechanics are quite similar.

Application as Designed ≠ Application as Integrated ≠ Application as Used!

This triplet phenomena spans nearly every department and every tool within the organization. It's how your company does lead scoring or territory division in the CRM and it also spans the PTO and employee review processes in your HR platform.

It's something that seems natural - however its implication is that now the organization has to train their workforce on at least two but in many cases all three triplets. You want your employees to understand and know how to use the mechanics of each tool but at the same time you want them to know how "we use this tool in our company".

In most organizations we spoke with, the answer to this training challenge is typically reliant on employees figuring it out for themselves - "sink or swim", "I'll just follow the lunch crowd". When each employee is expected to master >30 applications, this approach becomes a tall order and frustration builds. Topic for our next post.