The responsibilities a PM takes on make a whole universe in itself, and we understand. We understand the constant battle to try and figure out functionalities and iterate pieces of the product, while thinking of the effect that this would or wouldn't have on the application, the customers using it and the engineers building it. It’s a lot to handle every day, and if you’re a PM reading this, then we’re here to tell you you’re a star!

Our curiosity lead us to conduct a survey and speak to multiple PMs to understand how similar this journey was in handling the notification layer of their respective products.

Based on this, their life (revolving around the notification layer), looks something like this:

  1. Ideation and Modelling Phase
  2. Implementation Phase and Iterations
  3. Fallbacks

Let’s dive a little deeper into each of these topics to understand better.

Ideation and Modelling Phase:

The PM does extensive research on what happens in a notification layer and why it is needed. Hours of reading, making notes, sketches and diagrams inspired by the greats, who have built their in-house notification layer, ultimately leading to a design idea.

This design idea finally boils down to something along the lines of:

  • A plan on what the notification layer is, and how it will plug into the application based on trigger-based calls from an interactive flow that clients would be able to execute on the application. Based on the requirement, these flows may run into multiple at once. We’re talking 100s!
  • The ideation then continues into how it can be implemented into the notification system being built, which eventually leads to finding the relevant vendors for each service like SMS, Email, Push Notifications etc.
  • In tandem with this, conversations will be initiated with the Engineering Managers to have buy-ins and further inputs on the notification layer implementation. A detailed sprint plan will be made with a roadmap for the entire piece, including engineering resource assignments to work on the execution.
  • Based on the survey we conducted, it typically takes an average of 3-5 engineers, a Product manager and anywhere between 3- 6 months to have an initial product up and running, based on the complexity and workflows.

Provided all these requirements are fulfilled, and the EM gives his blessing, the product manager gets the ball rolling, taking us to the next step

‍

Implementation, iterations and more:

  • This is one of the most crucial phases as it sets the tone for the rest of the layer to be built.
  • The implementation phase of the activity involves most of the heavy lifting done by the EM and the Engineering team, in the process of designing, creating and implementing a product.
  • The PM works closely with the team of engineers assigned, to unblock anything that is impeding the progress of the project towards the stipulated deadline.
  • The implementation, most often than not, works to fit the requirement that has been drawn out by the PM and will have little to no deviations from the requirement. (Possibly missing edge cases as well as fallbacks when the “happy flow” breaks).
  • When we conducted a survey with some companies that did build their own internal notification layer, the most common statement we heard was that they got into the project thinking it was a “build and forget” project. But it was not. Multiple integrations, new requirements, and template iterations require constant touch-points with different teams like Marketing, Engineering, etc. Maintenance is easily forgotten at the beginning but comes back later as a bigger problem to solve.
  • Another common pattern that we noticed was that once the initial build is shipped out, the engineering team is dissolved and realigned to other projects. This only means that if there are iterations that are needed, the dependency would fall on the same engineers who are currently working on another project - which is impossible. Delays, stop-gap fixes and rudimentary processes are born from this situation, leading to further chaos.

Fallbacks

Every EM builds to fix a problem. Nobody starts off a project thinking it’d fail. But here’s how teams end up missing building fallbacks to counter this. Especially not a “small” piece such as notifications.

Most of the failures, however, fall out of the control of the EMs and the PMs, which then becomes an overlooked problem.
  • The provider may have a downtime - unpredictable; or planned. Regardless, having just 1 provider, which is how most companies start, is not wise. This piece can be solved with other providers or channels, but the coding piece of it is yet again dependent on the EM who initially worked on the project - the same bottleneck.
  • While they are at it, most PMs also ideate about adding additional channels for wider reach and multi-channel communication with clients. This is a great idea, except for the problem of spamming. Nobody likes getting the same message 2 - 3 times on different sources like SMS, Email and Application Push notification. This also leads to a disgruntled user experience and can have negative repercussions for the business.

All in all, the effort that a PM and an EM puts into building the notification layer is larger than expected, involves multiple iterations and needs a lot more thought and effort than it’s initially given the credit for. Notifications can propel a brand forward greatly. In today’s climate, it’s become super critical to give thought to notifications and plan in detail how to go about it - for the long term!

Over the years, working closely with companies of different industries has only made it more and more clear that having an expert looking at your communication layer and making it better with automation inputs and application integrations, is a real need of the hour. Use the talent and efforts of your engineering teams to focus on what really matters - your core product.

At Fyno HQ, this is exactly what we’ve set out to solve. You focus on your product, and we’ll focus on your notifications.

See you in the next!

‍