We are well past peak Email. We hope to be past peak Jira. We are in peak Slack.
The above statements are closer to where we currently are than not.
Email in the 90s was where everything started, lived, and ended. A developer would need to start her day looking at an inbox with an ever-increasing number next to the “Inbox” and go through her day consciously getting back to it, as that’s how the work got done. Looking back at that experience feels clunky and archaic, rightfully so. The user interface and the performance were in a nascent stage and although we knew things would get better, we didn’t know by how much.
Jira set a firm tone by the mid-2000s for issue tracking and project management which moved conversations away from email but ironically resulted in higher email traffic from notifications. Most of this notification traffic is borderline spam needing the user to set email filters and fish out the ones that truly require attention. We quickly moved into the “more emails but less relevant” zone. Sprint and sprint planning took off as the way to get work done in startups and enterprises alike, although with widely varying results. Daily stand-ups run by the scrum masters became the norm and they now feel taxing, both on time and energy. One could argue that in chasing flexibility and customization, Jira has delivered a non-optional byproduct to its customers in rigidity and a one-size-fits-all structure. Organizations are starting to recognize the imposing processes that Jira invariably brings into an organization which directly affects the execution pace adversely, not to mention the developer morale. This is all the more critical to product-led growth companies where the product iterations need to be much faster. Add to this the one thing that Email and Jira lack beyond any doubt - Delight, and an opportunity for disruption becomes obvious.
Enter Slack. Starting with a bold vision to make email obsolete, Slack has made a huge dent in reducing both content and traffic in email. It has created a behavioral shift where a developer starts her day looking at Slack notifications. Email is an afterthought. Slack has brought on this new wave with an intuitive design that emphasizes user experience and delight along with integrations, bots, and APIs as first-class citizens on its platform. Channels, ephemeral or otherwise are the norm to collaborate and resolve/decide now, with work items created across integrated tools on the go. User mentions, status, reminders, emojis, gifs, and threads have delighted users like no other business tool before has. Slack to an extent has democratized information but one could argue that there is more to be done here. Channel clutter, notifications overload, and lack of any smart self-resolution or deduplication of tasks or issues have left a lot to be desired.
If there is one thing that has not changed for companies in the information era, it is - How do we get a direct line to the customers as the company scales i.e how do we consistently build things that customers want? The answers to these reside in the era of Convergence which is about breaking down the information silos across various organizations in a company and empowering the stakeholders to focus on the customer. Deeper but simpler no-code integrations with day-to-day services and tools used by organizations will open to door to the next level of automation. A developer’s day would start with a priority-ordered list of unique and consolidated updates of things to do/know for the day. Any progress made on the development (read code) will trigger automatic updates on related tickets and conversations/threads (internal or external i.e customer). In this era of now, a lightweight widget will empower the support engineer to pull in the relevant developer or expert right into a conversation with a customer if need be. One-click voice and video will accelerate debugging with tickets created right from the conversation window, all context carried over and preserved automatically. A single system of record will ensure access to information across all layers like never before and information lockdown across systems/tools will be a passe. Incoming tickets caused by the same underlying issue will be deduped to a parent ticket, and live updates will flow downstream to all affected parties. On similar lines, a product manager can be brought in to field a customer’s feature request. A comprehensive product-centric interface with all microservices making the product on one side and the product’s capabilities and features on the other side will let the product manager get an accurate sense of priority, effort, and time scope for the incoming requests. This live interface is designed to show the microservices health/activity (dev) and the customers tied to the capabilities/features (rev). We are only in the early innings of what’s possible and we at DevRev believe that this is the road ahead. A road that will put the customer at the center with the power of data, design, and delight.
