Maslow’s Hierarchy of Digital Experience Needs

In 1943, a psychology theory was introduced by Abraham Maslow outlining a hierarchy of needs.  The hierarchy describes the stages of growth, starting with basic survival needs and moving onto more complex needs. If basic needs are not met, higher-level needs will not be attainable and individuals will feel anxious and tense.

The needs are:

Physiological:  These are basic physical needs for survival such as breathing, food, water.

Safety: The ability to meet tomorrow’s needs and include personal and financial security, health and well-being, law and order.

Love and Belonging: The need to feel like you belong and are accepted.

Esteem: The need to feel respected by yourself and others.

Self-actualization:  Once all other needs are met, only then can individuals fulfill their maximum personal potential.

Applying the framework to digital experience

Just like humans who need to have basic needs met before they can meet their full potential, the same can be said for businesses. For a company to become a top brand, focus on innovation, and see revenue growth, basic operational needs must be met first.

Extending Maslow’s hierarchy to digital experience monitoring, we can see the steps needed for organizations to reach their full potential.

Service Level Indicators

Start here. Service level indicators are the key, foundational input for the hierarchical construct. It does not matter how amazing you believe the application to be. If there are no indicators – to indicate the state of the service – then you are a rudderless ship in the middle of a great, big ocean with no sense of direction. Remember, data becomes information becomes knowledge becomes wisdom, so start with your indicator data and evolve from there.

Popular service level indicators:

• Uptime/availability
• Performance/response times
• Error count
• Latency
• Saturation
• Unauthorized requests
• Throughput

Customer Experiences and Reach

A highly available, highly performing service at the source means nothing if customers cannot reach and experience them from where they are. When we ask, “What good is a brightly burning sun if its rays cannot reach you on the beach (on a cloudy, stormy day)?”, it is to offer a simple yet critical way to reflect on all the delivery chain components between your service and your customers – and to make sure monitoring is done directly from the customer experience perspective. This experience perspective will include conversations around delivery chain components where traditional monitoring tools are not sufficient.

According to the 2021 Catchpoint SRE Survey, these percent of respondents said they have – or plan to have – multiple respective third-party providers for:

• 47% said they have multiple cloud providers
• 45% said they have multiple datacenters
• 38% said they have multiple DNS providers
• 35% said they have multiple CDN providers
• 31% said they have multiple API providers

Given these alarming stats on the use of third-party providers to extend service reach, digital experience monitoring must include a strategy to account for them.

Reliability and Resiliency

Credit goes to Google for seeding the idea of reliability engineering. For us, it is the idea that once you have the right indicators in place, and once you have extended service reach to match the proximity of your customers, then those services must remain reliable and resilient – from the customer’s perspective! This will most assuredly incorporate playbooks and accountability for third-party vendors and requests. But one critical way to think about reliability and resiliency in a distributed sense is to remember that each delivery chain point of presence is its own opportunity to present a different reliability profile – so your monitoring needs to be as distributed as the digital services you deliver.

Capabilities

Capabilities are the gateway to business outcomes. And there is a magical moment when monitoring strategists stop talking about features and functions – and start talking about capabilities that help the business (refer to the above graphic for “IT-focused” versus “Business value-focused”). For example, consider these example capability statements: proactively manage incidents, shift pre-production performance testing further left, or have business-level observability. These capabilities will most certainly include data sources and tools such as:

• Revenue
• #Site visitors/traffic
• Public/social sentiment
• Competitive intelligence benchmarking
• Digital monitoring (digital monitoring in a very broad sense to include all layers of the stack)
• AIOps

But for them to be considered as capabilities, you will want to also include other assets such as:

• People
• Process
• Best practices

And when you do, you can then more easily have a conversation about positive business outcomes.

Business Outcomes

Once you start talking about capabilities, then you can start talking about business outcomes. Using the above example capability statement, by having the ability to shift pre-production testing further left, the business outcome here is a great cost-saving opportunity because problems are caught sooner when they are cheaper to fix.

Value Realization

You have reached the state of digital experience monitoring nirvana. You can articulate value all the way through this value stream of activities – and sell ice water to Eskimos. Your indicators have gone from being collected at the source to being collected from where your customers are. Services and apps are reliable and resilient. You are now having business-level conversations around capabilities instead of features/functions. All of this leading to business results and the penultimate outcome: value realization for your customers.

Congratulations!