User engagement is as much art as it is science. Since Product and Engineering teams are busy focusing their time and energy on building the core application that delights users and powers their business, notifications are often treated as an afterthought.

Usually, the conversation goes something like “Send users an order confirmation email,” or “send an OTP text when they log in.” The team then creates a confirmation email and OTP text because it’s easy and takes no time. Fast forward 6 months and new requests for different notification types, channels, and features come in. This results in building these notifications in disconnected ways, possibly having to refactor the entire system with each new addition.

As we can see above, engineering effort is minimal to create a basic notification. However, once implemented, it is very challenging to scale as end-users demand a more robust and customized notifications experience.

The challenge that arises from this is that even inside the seemingly simplest of app activities, a poor notifications experience is lurking, ready to hurt your carefully crafted user experience, or worse, damage your brand in the process.

Why does this happen? Usually, it’s because of how notifications are thought about and ultimately implemented. They’re afterthoughts that come with long-tail engineering and product requirements, and dreaded product and technical debt that results from piecemeal fixes as product teams increasingly demand more types of notifications, more notification channels, and autonomy and control over the content users receive.

Say no to clunky notifications

As a product manager looking to provide clients with an excellent user experience, one of the biggest challenges you face is having clunky a notifications system.

A clunky user experience is symptomatic of the following core issues:

• Lack of user control over which notifications they get, and when, where, and why they get them.
• Lack of brand consistency.
• Developers or an external source are required to make changes to notifications.
• Unique content, systems, and sources for each notification app, function, or channel.
• Lack of visibility and awareness if a message has or has not been delivered, and the time-consuming troubleshooting when things go wrong.

If you’ve encountered these challenges, they likely stem from a common cause: friction between development and product teams. This friction occurs because of a lack of centralized way to build, manage, and interact with a notification framework.

Core notification challenges details

Lack of user preferences

The bar for user experience has been raised, and setting individual preferences is now table stakes. It’s simply a part of the common notification experience that your users expect. How do you ensure that user preferences are being met?

”We want to have a tool that is capable of managing the preference and the user info, to allow the customer to constantly update if he wants to receive email, SMS, through the mobile app, and so on.” — Lead Platform Product Manager, automotive software

Some of your users might not want to receive emails. In that case, how does the system know to send SMS, or WhatsApp instead? If these notification types are set by the business, but stored in different systems, it’s much harder for a product manager to ensure no user is left behind.

Importantly, this also helps prevent sending a barrage of notifications all at once.

A centralized notification platform helps you deliver notifications to your users where they want it, when they want it, how they want it.

Lack of brand consistency

Oftentimes, especially when relying on engineering teams or professional services to make changes, there’s a lack of brand consistency.

Stop me if this sounds familiar when describing your notifications:

The word I would use is clunky. There is not a lot of consistency and there are a lot of holes in exactly what things look like.”

— VP Product Manager, banking

Without a template management system upon which to standardize your notifications, this is too often the result. A typical workflow is that product will deliver a PDF or a Figma design to the engineering team or external service provider, who then have to code the design to spec. Along the way, something of the notification gets lost in translation.

Reliant on engineering to make changes

“It requires engineering effort to make changes. We have a number of product and operations teams, who would like to have influence over messaging, verbiage, and cadence. We want to run experiments, and our current solution isn’t able to support that…”

— Lead Product Manager, e-commerce software

This lack of ability to manage notifications directly makes it a black box. For non-technical team members, this leaves them without control over their own destiny. Not only does it hamper experimentation, and thus innovation, it also decreases velocity by adding multiple feedback and review cycles to work that the product or operations team need to own.

We often speak with organizations that are using some type of enterprise solution that has a “notifications module” to manage their application notifications. This experience typically comes with a lot of back and forth with the external professional services team and lacks true ownership of content and overall message.

In the same way that DevSecOps aims to shift-left, moving security and vulnerability to the hands of the developers who have the most context and can remediate immediately, we should aim to shift notifications left, into the hands of the product teams that have the most context over the messages they’re sending.

Product teams shouldn’t have to rely on development teams to fix a typo, tweak wording, or update a logo or other image.

Lack of centralization

Teams should not have to work in multiple notification systems, depending on the type of message, the channel it’s being sent through, or the function it’s being sent for.

“You can imagine what happens when every department builds their own notification system within their own use cases and their own functions. That gets to be a real challenge when I’m a product manager and I just want to send a notification out. I would like to go to one place as opposed to all these other individual systems.”

—Director of Product Management, automotive manufacturer

Disparate systems further exacerbates a lack of consistency. It manifests in subtle ways, such as look-and-feel, elements within the in-application notifications being different from what’s sent in an email, inconsistent wording, and mixed messaging.

But it also adds cognitive overhead. As a product-led software organization, you may have multiple feature teams which develop notifications independently. For example, you likely have a mobile team that cares about push notifications, a separate team that cares about text messages, a payments team that implements email invoices, and so on and so forth. Those are several teams that need to then be coordinated for execution.

This is why notification management should be centralized.

Troubleshooting message delivery

The fifth aspect of user experience is message delivery.

“Is there a way we can actually follow a single message, see if it’s delivered for a specific device or specific user, so we can test it, make sure that particular message has been sent and received?”

— Managing Director, accounting software

Disparate systems make observability exponentially more difficult.

Having a single platform makes it easier to troubleshoot and debug when notifications fail, and furthermore, have built-in retries to ensure delivery.

Engineering and development teams want this too

The good news is that product managers aren’t alone in facing these challenges. Development teams want to solve notifications too.

“Instead of hand-rolling the rules, sending an email, change custom icons in the app. I want to get out of all that customization, streamline the delivery for my product team, and make the customer experience better.”

—CTO, communication software

The common denominator across a clunky user experience is the lack of a centralized notifications platform, where engineering and product teams can collaborate.

This allows development teams to:

• create templates for brand consistency
• empower product teams to directly manage messaging and cadence
• offload notifications logic, user preferences, and more
• quickly debug and troubleshoot notifications issues

The Novu way

To recap, product managers want to deliver an excellent user experience through notifications. However, they are often faced with a lack of ownership over the notifications they send, leading to messaging, design, and branding inconsistency, and an inability to experiment with verbiage, cadence, or really anything else.

The solution is to empower both product and development teams to collaborate, where each team team controls the parts they care about: logic, integrations, and data sources for development teams, and cadence, messaging, experience, and functionality for product teams.

A powerful, centralized notifications framework enables development and engineering teams to easily build a scalable, reliable, and infinitely flexible notifications platform to product teams.

In parallel, product teams directly interact with the notification types, content, messaging, styles, branding, etc… they completely control all components of a notification they want to—all without the risk of breaking sensitive business and software logic.

End users benefits from all of this. Rich, interactive notifications in the channels they prefer. Flexible, accessible preferences means they, too, are in control of how you communicate with them.

If you, like our customers, are under tight timelines and looking to deploy features more quickly, it makes sense to try Novu. Instead of looking to build this in house, maintain it, and expand (cough* refactor* cough) as new features are required, avoid the unknowns and use the standard for notifications infrastructure.

Book a discovery session to learn how Novu can accelerate your notification velocity today.