Three key use cases of product-led (PLG) companies

At DevRev, we believe that any business can adhere to some essential principles to become a PLG or product-led company. We understand that there are several technologies and tools that companies today have adopted to become product-led. These apps and tools are typically stitched together with bespoke work that gets incredibly expensive and complex to manage over time. Our vision and mission are to build an operating system for PLG to help these companies become product-led more efficiently and simply. We call this PLG operating system (OS) the Developer Customer Relationship Management platform, or Dev CRM for short.

A typical company focused on building a digital product, a product driven by code, can be divided into two main groups of people and processes working in cohorts - front office and back office. The front office typically consists of efforts and workflows aimed at acquiring new customers, supporting them, and getting them to renew their subscriptions periodically. The back office, on the other hand, consists of people and processes focused on building and supporting the product, typically consisting of code.

The front office can be further divided into growth and support quadrants, while the back office can be subdivided into the build and operate quadrants. Although this requires little explanation, the front office’s center of gravity is around a company’s customers (Rev). In contrast, the back office is centered around the makers responsible for building and operating the product (Dev).

Before we get into how to use DevRev as a PLG OS, let’s look at some of the fundamental principles of a product-led company.

• A product-led company has automation drive most, if not all, of the processes across the company.
• The automations are typically based on an event-driven architecture where the data is generated off user clicks streams or data generated by disaggregated services.
• The amount of data generated and consumed requires the use of AI and ML not only to learn but also to build models that add predictiveness and personalization to automations and interactions between the front and back office and between Devs and Revs.
• The interactions, conversations, and responses to automated or manual events generally happen in real-time and are often asynchronously dictated by the company’s priority and resource modeling.
• Given that code and automation drive most of the company’s interactions, interaction design is a crucial tenet of all product-led companies.

DevRev enables businesses to become product-centric by embedding some key principles into three interconnected use cases that cut across the front and back office.

Let’s look at each one of them.

Use case 1 - Building product catalog by connecting Dev and Rev parts.

Key principles:

• Hierarchy of parts - Within DevRev, you can create Products that could have multiple capabilities, and each capability can have multiple features. Together these are referred to as “parts.” A part is typically of two different kinds - a Dev part or a Rev part. A Dev part is something your dev team has built up and can be either a repository, microservice, service, or, in essence, any collection of code that forms a deployment.
• Real-time - Every dev part is connected to your code repository and deployment (coming soon), which means when you click on a Dev part, it gives you real-time information about code changes and deployment logs about them.
• Connected - Every dev part is typically connected to a Rev part which in turn is connected to issues and tickets. A ticket could also be connected directly to a customer conversation.

To see an example of typical Dev and Rev part trails, watch this 2-minute video.

DevRev Trails - Build your product catalog visually.

Use case 2 - Connecting product to Developer work.

Key principles:

1. Simplicity - Within DevRev, we believe in fighting complexity, especially when it comes to managing developer work. Any work item that a developer/maker works on is an issue. Any work item that originates from a customer (internal or external), on the other hand, is a ticket. Tickets and issues can have relationships with each other (parent, child or related to other issues and tickets).
2. Connected - Tickets can be connected to issues. Issues can be connected to other issues and, more importantly, parts. This means users can view issues by parts. All events for parts (for example, a Pull Request for a part related to an issue) are captured and consumed in real-time at the work item level, thus obviating the need for multiple status check meetings.
3. Real-time collaboration - We believe all work items should have features so Dev and Rev teams can collaborate remotely and in real-time using text, voice, and video (coming soon). This collaboration should happen at the individual work item level, obviating the need for noisy and temporary Slack channels requiring manual setup.

Use case 3 - Connecting front-office conversations to back-office work.

Key principles:

• Identity for personalized conversations - With DevRev PLuG, customer identity is at the heart of all communication. With a few lines of code, the PLuG can be embedded inside any application, and conversations are immediately connected to individual customers. Over the period of time, insights about the customer and their usage will help front office support agents with insights to have more personalized conversations with their customers.
• Connected conversations - Within DevRev, all conversations make it instantly to the back office where they are connected to tickets, which in turn are connected to issues and parts instantly. This is the core essence of being product-led when all work items (conversations, issues, and tickets) are connected to parts (Dev and Rev parts) and customer identity.
• Bi-direction real-time updates – Since parts are connected to issues and tickets and tickets are connected to conversations, any updates, automated or otherwise, at the code level are immediately captured and become shareable with the customers in real-time. In addition, all conversation updates are immediately available at the tickets and issues level so that part owners are never out of sync.

You can view how to do all these three use cases in a short video here -
Three PLG use cases within DevRev

Summary
We believe that in order to be a product-led company, the code/product needs to be constantly connected to all developer work, which in turn should be connected to the end-users and customers. With the three use cases described above, companies can use DevRev to become product-centric and hence more customer-focused.

You can sign up for DevRev here and try out these use cases on your own.