FooterCTA

DevRevHeader

DevRevArticlesList

DevRevDataProviderArticlesList

ArticlesAll

DevRev - Blogs and News

Screen

InvestorWebapp

plasmic-basic-components

react-youtube

GA Website

react-slick

TechCrunch

Former Nutanix execs launch new startup with $50M seed round

She brought a whole new meaning to living in harmony with nature. Following ancient tradition and making the most of each season’s givings, she grew her own food, crafted furniture, dyed clothes, and redefined ‘from scratch’. She mastered the art of sustainable living and brought her stories to millions around the world. She made everything and could be anyone — a chef, an engineer, a farmer, a carpenter, a gardener, and a creator.

As I watched [Li Ziqi](https://www.youtube.com/channel/UCoC47do520os_4DBMEFGg4A) over the years, experiencing an ideal lifestyle with nature in the deep countryside of rural Sichuan, I appreciated The Simple Life, and found peace and greatness. She bolsters my belief that the individual, as a creator, holds more power than any time in the past. The rise of the individual is real.

**The rise of the Developer**

Li Ziqi is among many creators in the New Renaissance — Anthony from [Ace of Clay](https://www.aceofclay.com/), John Plant from Primitive Technology are other examples. In the new era, human relevance, purpose and self-realization are at the forefront. Technology has made this shift real, more than any time in the past, helping bring creative minds together and where our future is more human, not less.

In this article, let’s explore ‘the developer’ creator and how she may build products and run businesses. Most developers, like Li Ziqi, love deep silent work and an unconstrained creation of awesome software. And software development is that grounded profession where you can make money if you solve people’s problems well and make them happy!

So how do we empower developers to deliver creativity at their best? How can we enable developers to do deep silent work, while bringing the human element, the customer into their creation? Such would be running your business with code. Let’s explore how we may do this with GitHub and DevRev.

**Building software with GitHub and DevRev**

There’s a lot to love about [GitHub](https://github.com/). It is where millions of developers and organizations are building, shipping and maintaining their software. The reason GitHub is so indispensable today is that it addressed problems that every software developer struggled with regardless of operating system, programming language and role. It has democratized coding and made it -
<ul>
 <li>easy to use Git
<li>easy to collaborate on code
<li>easy to host (and find) open source projects
</ul>

![image](https://cdn.sanity.io/images/umrbtih2/production/102dfdd023fefa6e17fecf140408e4d60c9d7291-1400x733.jpg?w=1400)

DevRev heart GitHub

GitHub has forever changed how people write and share code, and is now an essential platform for every developer. In this article, let’s discuss how DevRev can extend the awesome GitHub experience, and empower developers to build great software and run a long term sustainable business.

**Bring the human, the Customer**

[DevRev](https://devrev.ai/) is focused on bringing developers closer to customers and revenue. We strive to fill the missing seat, that of the customer as developers write and collaborate on code. The first step to writing awesome software and building a business is solving problems. Typical questions are — shall we solve problems that are highly specific experienced by a small group of customers, or are they big, ambitious products with a great potential market? Are we continuously solving painful problems and are we building sticky and impactful products?

Discovering customer wants and needs, and prioritizing against company goals, is still a complex problem today. It is difficult to distill signal from noise, and information typically gets lost across multiple systems and functions. Decisions on what to build may happen in isolation, with poor correlation to customer value and business impact. Product managers may source feature requests in a time consuming process, collating ideas from many disparate sources, in the form of customer support tickets, community discussions, user experience feedback, and also from internal sources, such as new market opportunities, platform refactoring plans and technical debt. Some may prioritize based on instinct, without a full understanding of impact and the right information on hand.


![image](https://cdn.sanity.io/images/umrbtih2/production/d8488b443c27315abf53fc05116fdda63ab9bab6-7680x4320.png?w=7680)
Connecting Developers with Customers on One Platform

As code gets built into software that is operated in the cloud and delivered to customers, DevRev brings the context of the customer when developers build new features, fix bugs or address test regressions. When there is clear visibility of value chain from writing code, deploying microservices and delivering features that customers consume, we unlock -


**prioritization**: build what’s most valuable with issues prioritized against customer impact along with relevant customer records, eliminating subjective reasoning on what to work on

**attribution**: triage customer defects, along with context such as cloud environment, logs and events and attribute to relevant microservices and libraries


**impact**: bring honest visibility on engagement and churn, so developers see impact and avoid building shelfware

*“Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs.” Facts and Fallacies of Software Engineering, Robert Glass*

In a world where developers spend an average of 60% of their time maintaining software, diagnosing issues, triangulating between data — logs, metrics, stack traces, source code repositories and tribal knowledge, GitHub and DevRev integration will automate tasks, leaving developers to focus on higher-order problems and get closer to their customers.

**Develop products with agility**

There is incredible power in seeing the world through the lens of products, as opposed to simply projects and agile methodologies. Projects represent activities an organization performs to achieve an objective and are typically ephemeral, and sometimes disconnect you from the macro objective, their customer. Alternatively, products are what connect the user with the developer — they bust organizational silos and provide a true north.

![image](https://cdn.sanity.io/images/umrbtih2/production/32d6ce36d1afbb18cb2c62221226556c92cafcd6-7680x4320.png?w=7680)
Connect code & microservices with customer-centric features, capabilities and products

GitHub and DevRev integration enables meaningful organization of code from the developer-centric world of libraries and microservices to customer-centric world of features, capabilities and products, empowering developers with a new way to work -

**products, not projects:** where developers build, operate, and support a shared asset, the product that binds everyone together


**agility, not agile (methodology)**: where developers and customers engage and respond to change, while understanding relationships between micro services and customer consumables, such as APIs and features


**catalog thinking**: where developers appreciate the economics of pricing, inventory, supply, demand, cost, capital and nurture business-thinking
‘Product-centricity’ fundamentally changes how developers may work with their peers and how they organize their work. Converging data across the software supply chain, starting with GitHub correlates code with products and meaningfully connects to customers.


**Enable deep silent work**

Creativity comes from deep work and achieving deep work time i.e., focused, distraction-free time for development, can be challenging! Fortunately, by organizing around code, the possibilities to let machines take care of shallow work are endless

<li>spend less time in meetings: eliminate manual updates to issues, by connecting GitHub pull requests and commits with DevRev, and providing stakeholders visibility of exactly what is being worked on
<li>easy access to data: let developer be in charge through /commands that answer questions and access data from GitHub without going to multiple places
<li>integrate your tech stack: remove silos by integrating with your entire tech stack and tie alerts, customer usage and metrics back to code, saving time and bringing code to the center of your decision making
</ul>

**GitHub and DevRev, better together**

![image](https://cdn.sanity.io/images/umrbtih2/production/c4a8a28285d655d396323a21341255f31088683e-863x478.png?w=863)

Just as Li Ziqi found peace and meaning, every developer deserves a deep silent space, and an avenue to unleash her creativity. This future, that of bringing developers to the pace and empathy of front office, will empower developers to not only write awesome software but also become entrepreneurs. If you are excited about this future — Get Started with [DevRev](https://devrev.ai/) and [Join our Beta Waiting List](https://devrev.ai/circle)!

GitHub with DevRev, creativity at its best

Not very long ago something seemingly trivial like making phone calls across the globe required complex processes and integrations with different phone companies. Today, you can not only make phone calls but even video calls in an on-demand fashion from anywhere.
A lot has happened since the telecom industry went digital and today we live in an era where anything, from a car to a meal, can be ordered instantaneously, with notifications and real-time tracking ensuring the user always knows its ‘status’.

A similar thing happened when it came to payments. We went from writing checks on paper to instantly paying or sending someone money across the globe using mobile apps.

One could argue that there was one big reason that caused this revolution. Our transition from physical to digital necessitated developers to translate complex and error-prone processes into code and APIs.
What was complex and proprietary in the physical world turned into &lt;code&gt; that could now talk to other systems.

## Product-led takes root
With the transition to digital, product took center stage in terms of go to market strategies. Cloud software promised a new software experience that would enable departments to quickly purchase, deploy, access, and upgrade their business apps all over the internet, which in parallel shifted buying decisions from IT to business unit managers. 20+ years later, SaaS is now the norm but a new trend will permeate business software over the next 20 years.

Just as cloud apps shifted buying decisions from IT to department units, modern SaaS apps have perfected the original promises of low cost, seamless onboarding, and rapid product development. This led to the birth of product-led motions where trials and freemium experiences put users at the center. Mirroring B2C trends, application experiences drive growth and adoption, instead of manual long-tailed sales motions.
This has further shifted software decision makers from management, to teams, and even individuals. The next decade will see the rapid adoption of Product-Led Growth (PLG) first offerings and it will transform not only how software is built, but more importantly how you build a business and organization to sell and support them.

## The true product-led era is here and now

In the product-led era, B2B starts to look a lot like B2C.
Top-down, sales motions which target buyers get replaced by grassroots, product-led motions targeting the end-user.
Big multi-year commits get replaced by usage-based micro-transactions, and
Long, consultative provisioning processes get replaced by zero-touch self-service, value driven experiences.
In this era, code is now driving all interactions across the customer lifecycle, which has put the Developers at the center of a revolution that is quietly taking shape.

## The birth of a revolution
While most companies recognize the need for developers to support go-to-market functions, the work is still prescribed as tasks. Developer work is framed as a backlog of items to deliver, with little expectation that the developer relates to the desired outcomes. By siloing developers, they get pushed further and further away from their users and customers, resulting in a product built without considering the full spectrum of solution sets available.

When it comes to the tools and systems available today for developers to do their work, they have increasingly become project-centric instead of being product-centric. In fact, some of the most used tools for ticketing and bug fixes are manager-centric instead of maker-centric.
Ten tools for a better Dev experience

When we spoke to our early adopters and design partners about how they manage their work along with product parts, what we heard was not very different from our past experiences as makers.

On average, it takes ten tools and systems to stitch together a common workflow such as triaging an incident and understanding its customer impact. Our design partners shared similar experiences as they navigated the complexities of managing data across systems like code repos, DevOps tools, project trackers, collaboration channels, ticketing systems, product analytics, and data warehouses. In this web of siloed systems, collecting the right signals to understand impact and priorities is nearly impossible.

## What if?
As developers, we imagined a system where customer interactions across conversations, tickets, and clicks, come together with the Dev interactions of collaboration, triage, and commits.
If a phone can converge, simplify and bring together hundreds of physical tools and processes into a simple interface, what if everything a developer works on can be brought under one “operating system.”
If an app could democratize specialized work and make every smartphone owner a photographer, what would happen if we brought makers closer to customers and broke down organizational silos?
The question to ask is — when it comes to Customer Relationship Management (CRM):
Where is the relationship between the user and the product?
Between the customer (Rev) and the makers (Dev)?
More importantly, with the developers at the center of it all — How will Devs define the future of CRM?
We call this DevCRM — a system that empowers makers to build, operate, support, and grow their businesses by putting their customers at the center, and this is what we shared in our live stream on Oct 20, 2021.


![image](https://cdn.sanity.io/images/umrbtih2/production/d8488b443c27315abf53fc05116fdda63ab9bab6-7680x4320.png?w=7680)

Connecting Makers with customers on one platform

![image](https://cdn.sanity.io/images/umrbtih2/production/cdb85a137d26f7f4ae76b9b5d14126bff79b7e51-7680x4320.png?w=7680)

Collaborate across organization silos

![image](https://cdn.sanity.io/images/umrbtih2/production/9d2aeae484de625c308cd305db1daefe088fff85-7680x4320.png?w=7680)


Nurture and support in-app
As we see in the video, a fundamental part of DevCRM and DevRev is the notion of product (code) connected to everything a dev creates or works on.
This is just the beginning and we are working on a number of exciting things we would love your feedback on.
Join our early adopters waitlist at https://devrev.ai/circle and help us build a better future.

The why and what of DevRev

For those reading this with a PLG (Product-Led Growth) background, the assertion that there is no meaningful difference between bug and feature request may seem like a no-brainer. Others, however, may consider this claim strange or even ridiculous. Let me attempt to change your mind.

## Utilitarianism vs Deontology
First, let's start with a brief philosophy lesson. I promise it's relevant. Those who are fans of the philosophy of Netflix's "The Good Place" may be familiar with these two ethical theories. For those that aren't, utilitarianism posits that the action that does the most good for the most people is the one that is morally just. Deontology, on the other hand, asserts that some actions are inherently good while others are inherently bad.

An important criticism of utilitarianism is that it can justify inflicting undeserving suffering on one if it will provide a positive outcome for others. For example, forcing a person with a specific set of genetic traits to undergo potentially invasive painful medical procedures to potentially help others.
Deontology also has its set of criticisms. Here the most relevant one is that it doesn't consider the outcome of the action, only the action itself. For example, a follower of deontology would be unable to lie even if it were to spare someone needless emotional distress.

## PLG vs. SLG
A quick definition of these two growth strategies provides further context to this discussion. PLG stands for Product-Led Growth, and it suggests that if a product is really good and continues to adapt to serve the needs of its users, it will find product-market fit and grow without the need for significant marketing and sales investments. On the other hand, SLG stands for Sales-Led Growth, which follows a more traditional approach, particularly for B2B software, where you have a sales team that ideally drives adoption and growth in the market.

## What is a bug?
This depends on who you ask. Most sitting on the developer's side of the screen will say something like, a bug is something that doesn't work, something that's broken.
Someone sitting on the end user's side of the screen will probably say something similar. However, they do not know the intent, so what they may see as a bug may, in fact, have been intentional.

## What is a feature request?
Again, this depends on who you ask. From the developer's side of the screen, it's likely something new that the end-user wants to be added to the product. It may also extend to a change the end-user would like made in the product.
However, from the end user's side of the screen, that change or new feature may not feel like a feature request because it is something they would have reasonably expected.

## Why does it matter?
Here's where we get to the really contentious part of this argument. Before you read on, take a moment to think about why you think differentiating between bug and feature request is important.
Here are some reasons I've been given:
- To determine priority
- To measure an individual or teams code quality
- To measure productivity
- For ticket routing

Coming from a startup that built B2C software with a team of only 12 and over a million users, some of these were foreign concepts to me due to the small size of our company. However, a business degree and lots of reading gave me some insight into where my colleagues at DevRev were coming from.

I'll address each of these but let's start with a story.

## Story Time
I've always liked being the voice of the people, happy to put myself on the line when I was sure of the right thing to do, so I ended up practicing PLG before I ever heard of it.

Still, early in my career, I was going back and forth with developers over whether something was a bug or a feature request (if you're a developer, product manager, or support engineer, you have absolutely had this argument at some point). We always put out MVPs in service of being first to market, which had greatly contributed to the company's success; however, it also meant we'd go to market without features that a reasonable end user would probably expect. This was one of those situations. As the voice of the user, I made the argument that not having it caused significant confusion, and the end-users often interpreted it as a bug and were understandably upset. I was met with the explanation that it was a feature request because we knew that it often wouldn't work and would require significant resources to make it fully operational. After 15 minutes (and countless previous conversations) of going around in circles arguing about whether it was a bug or a feature request, I finally said with a little more force and frustration than I'd intended, "It doesn't matter if it's a bug or a feature request, from the end user's point of view it is something they expected to work and doesn't!"
Unfortunately, it didn't get that item fixed during my tenure at the company, but the concept stuck and helped us start making more user-centric product development decisions.

## How does this all relate?
Great question. Referring back to the list of arguments above, let's start with Determining priority. Followers of Deontology would likely say, you should fix the bug because it's the right thing to do. However, the bug may be something that only inconveniences about 5% of your users, whereas there's a [**new feature**](https://www.chameleon.io/blog/build-features-customers-need) that would significantly improve the experience for 80% of your users. With your limited resources, followers of deontology would still fix the bug.

On the other hand, followers of utilitarianism would work on the new feature because it does the greatest good for the greatest number of users. However, utilitarianism here has its own drawbacks. Just because a feature is requested by a significant number of users doesn't mean it is the best business decision for the company, particularly in cases where it requires significant resources but does not offer leverage over competitors' offerings.

The next two arguments, To Measure Code Quality and Productivity, are difficult topics. It's very human to want to quantify everything, give it a numerical score and determine if it's moving up or down, but it's been proven this isn't an exact science. The old approach was to measure by the number of lines of code written, but that's really nonsense considering it encouraged writing verbose, complex code rather than parsimonious efficient code. Here I'd refer to an article written by one of our founders Manoj Agarwal for Forbes.

The last argument, For Ticket Routing, is especially interesting because it is something the DevRev platform essentially eliminates by separating the end-user language from what the developer specifically works on without sacrificing the important context often contained in tickets. This means routing is done by the dev area of expertise rather than whose turn it is to address tickets.

## The Cultural Shift of PLG Teams
There is an added benefit of getting rid of the distinction between bug and feature request outside of improving customer centricity, eliminating false prioritization, and minimizing sub-optimal routing of tasks. It creates a natural shift towards a more collaborative culture by minimizing the stigma that seems to come with the word "bug." By removing it from our vocabulary, you no longer have a developer say they're "just doing bug fixes" but instead talking about their work in the context of the impact it is actually having.
Calling something a bug has an implicit element of blame to it making one feel like they're stuck doing tedious cleaning work rather than impactful development (whether or not this is actually the case). On the other hand, as builders, we are always drawn to making something new as a feature request implies. To quote Anoop Dawar, "I don't want to get into the debate of a feature versus a bug, so I use the word improvement." 

## So, what do we call it?
In our ecosystem, we simply call it a ticket. Tickets describe what an end-user is experiencing without the classification of "bug" or "feature request," thereby avoiding the trap of false prioritization based on these categories allowing prioritization to be determined based on the wider business goals. These tickets are then mapped to one or more issues. Issues describe what the developer is working on. This system allows the user-facing ticket to remain user-centric in language and the developer-facing issues to remain developer-centric. It is a many-to-many relationship as well, which means that developers are working on real issues related to their area of expertise instead of trying to clear end-user tickets that may really span multiple teams. 

With this in mind, we find that the argument of bug vs. feature request is a distinction without a difference in a PLG-oriented company. To execute well on PLG, we must follow utilitarianism (within reason) to benefit as many end-users as possible in the decision-making. To that end, it doesn't matter what the work item is called. All that matters is that the end user's experience is improved.

![image](https://cdn.sanity.io/images/umrbtih2/production/d69e086782bdc00ed6754703b05f41f0ed900745-10417x5859.png?w=10417)


Bug vs feature request - A distinction without a difference

ZDNet

DevRev launches developer-focused CRM with $50M in seed funding

In the product-led era, great customer support isn’t just good business practice, it represents an invaluable opportunity for growth.

The [latest research from Gartner](https://www.gartner.com/en/newsroom/press-releases/2021-11-18-gartner-survey-shows-64--of-customer-service-and-supp) finds that 64% of customer service and support leaders will focus on business growth in 2022. Increasingly, industry leaders recognize that customer management is [knowledge management](https://www.forbes.com/sites/forbestechcouncil/2021/10/21/knowledge-management-for-customer-experience-challenges-and-best-practices-in-2021/?sh=55d27b3c66c0), and seek to harness customer insights to improve the product and grow their business.

Investing in your team’s customer support strategy is a critical step; here, we lay out three functions that founders ought to prioritize.

## Product integration

Product integration means harnessing insights from customer interactions in one organized place so builders can directly apply them to the product.

For startups, customer support is an untapped goldmine for data-driven decision making. Your customer support tool should help you capitalize on every customer interaction, building a knowledge base that informs your product and processes.

Great customer support platforms seamlessly incorporate dashboards and metrics that inform their business practices. Traditionally, these insights are siloed in customer support teams, and don’t connect to developers and other teams in the company.

In your startup, it’s not enough to just capture insights from your customers. That knowledge base must be easily accessible to all of your teams, empowering you to build and grow your business with customers at the center.

## Consolidation

Startup founders know the pain of sitting in front of a screen for hours, sifting through a mountain of customer requests and grievances. This inefficient approach halts workflows and diverts time from more pressing tasks.

To avoid this anguish, it’s essential to consolidate customer interactions in one place under one system. This saves needless headaches and prevents valuable customer information from falling through the cracks — housing all your customer operations under one roof.

## Malleability

There’s no one-size-fits-all solution for your customer management system; as Michael Redbord writes in the [Harvard Business Review](https://hbr.org/2017/09/scaling-customer-service-as-your-startup-grows?registration=success), when scaling your startup’s customer support, you must “pick tooling that matches your service channels, style, and workflows.”

Your successful customer support tool should be simple to get started with, customizable from day one, and adaptable as your business grows.

For startups in particular, your tool shouldn’t be bogged down by endless features you don’t need. Instead, you should only pay for features and capabilities that are suitable for your growth stage; in customer support, minimalism is elegance.

## Customer success in your startup going forward
In 2022 and beyond, successful enterprises need to recognize every customer interaction as an asset.

As your customer support needs grow, it’s important to choose a malleable, consolidated, and integrated tool that delights your customers and informs your product-led growth from day one.

At DevRev, we understand this need and believe that makers (Dev) should be as close to the customers (Rev) as possible. Our platform synchronizes customer support, work management, and product planning in one place so your business keeps customers at the center.

The 3 essential functions of customer support tools for the growth-minded startup

I remember my first few weeks of college being completely different than I expected. I had taken computer science classes throughout high school and presumed that I would be at least a little ahead of the curve arriving at college. However, a week went by and we had already surpassed what I knew. After I finished my freshman year I felt even more confident in my abilities going into my first internship, and I again thought that I would be overly prepared, and again I quickly realized that I would have to start from scratch. Now after four years of classes, three internships and starting a full time job, I have a much better perspective about what school teaches you, and what it doesn’t.

Throughout my first internship, it felt as if school hadn’t prepared me for any of what I was doing. I had taken classes on data structures and computer architecture, but my internship was primarily front end work with some focus on data visualization and databases. Although my classes had taught me some new languages and some of the ideas that make for good programs, they were taught with a narrow view of applications primarily with future classes in mind. I had to more or less teach myself the ins and outs of web development with help from my mentor, and used little to nothing that school taught me. I knew that I would have to learn bits and pieces as I went, but I wasn’t expecting it to be that drastically different. As my time went on at school, I figured that I would be able to use what I learned from my internship because I thought I would have more classes that would cover some of the same material. However, out of 12 computer science classes, only one (Software Engineering) had any mention of front end development.

![image](https://cdn.sanity.io/images/umrbtih2/production/179d26c5e7166b629318c1492ca6ba33e9c6449d-4032x3024.jpg?w=4032)

In my mind, within computer science there are hard skills that directly relate to programming i.e. languages, libraries etc. and soft skills such as git, docker, ticketing systems etc. While you get good exposure to many different hard skills within school, training for soft skills is oftentimes lacking in the classroom. Again, out of 12 computer science classes only one (Software Engineering) really taught us how to use many of the different tools that are needed on a day to day basis as a programmer. While it is a little more understandable that there is less of a focus on front end engineering, the fact that these soft skills aren’t taught from day one is somewhat surprising to me. While in school, I worked as a freshman mentor for computer science students and taught a weekly one hour seminar to expose students to some of what they need to know that their classes would not teach them. Through that seminar, many students (including myself my freshman year) will learn a little about tools like git, some about recruitment, internships and going into the workforce, but that alone is not enough to truly prepare someone’s soft skills for the future.

Although I have a few qualms with some of the ways that college doesn't prepare students, over time throughout my classes and internships I started to see my college experience start to pay off. For example, picking up a new coding language is much easier after using so many for classes. I also find that my development procedure has drastically improved over years of coding for classes and meeting deadlines. I also took a lot away from my extracurricular activities that I was a part of during school. I was a part of an organization that puts together hackathons, and that really helped with my interpersonal skills and leadership. There are also classes that go over necessary skills that have been made public online like [this one](https://missing.csail.mit.edu/) from MIT. 

However I think the internships I got through my education were the biggest teachers for me, specifically my last internship that turned into a full time offer with DevRev. Working for a startup will get you ready to work on anything quickly; but I’ll save that for another day.

What college didn’t teach me

PR Newswire

DevRev Product-Led Support Now Available in AWS Marketplace

Product-led growth is one of the biggest themes in the zeitgeist of contemporary software companies. Adopting a [product-thinking mindset](https://devrev.ai/?tab=our-mission) can transform a company’s ability to delight its customers and grow its top line. Moving away from the centralized, sales-led model of traditional enterprise software companies, innovative players are now recognizing this opportunity and starting to adopt the product-led ethos, leveraging the insights of the consumer internet and adopting efficient, scalable, and user-focused strategies for growth. These companies have not only attracted large numbers of delighted customers; they have also, understandably, attracted the attention of a new wave of founders and venture capitalists eager to build the world-shaping companies of the [product-led paradigm](https://devrev.ai/articles/all/product-led-growth).

The product-led mindset does not, however, need to stop at the revenue-generating elements of a company. A fully product-led organization will approach every function in the organization, including operations functions and areas traditionally seen as cost centers, with the same user obsession, drive for innovation, and focus on scalable business value.

Based on our own experience taking a product-led, user-focused approach to building our operations at DevRev, we have distilled several key learnings that can help to guide you and your company on your own felicitous path toward product-led productivity.

1) Design for your customers
With every operational function, it is important to identify your customers and work assiduously to improve your offering to them (including constituencies internal to your organization). Drilling down further, to serve a customer well, you need to understand the needs of the customer’s atomic unit - the actual user. In employee onboarding, for example, you need to provide a delightful experience not only to new joiners, but also to hiring managers. In event planning, you may have speakers, marketing-analytics experts, and financial arbiters in addition to event planners. All of these groups need to be able to work from the same source of truth (the system of record), and each of them will have their own workflows that need to be built on top of that system. For instance, vendor quotes for an upcoming conference need to feed seamlessly into the planner’s budget plans, the finance team’s approval workflows, and the marketing team’s models for the expected productivity of outreach spending.

2) The builder must be a user
To have deep empathy for the user experience and to understand the nuances of workflows and edge cases, there is no substitute for being an actual user. When we at DevRev decided to scale up our engagement with the developer community through in-person events, we built an events-management tool that now provides people throughout the company a transparent calendar, a database of relevant logistical details, reporting dashboards, budgets, metrics, alerts, and status updates. Critically, our operations team built the tool not in a vacuum or based on a theoretical view of an event planner’s workflows, but instead in the real-world fray of planning, executing, and evaluating specific events. As a result, we built our ontology, data collection, and dashboards to support both tactical execution at the level of a single event as well as the macro view needed for setting strategy, allocating capital, and maximizing learning. We can easily and reliably answer, for example, essential questions like how many founders we expect to reach in our core geographies over the next six months or how many new users we can attribute to events of one type versus another.

3) Every operational function needs a system of record
The system of record is the cornerstone of accuracy and transparency that must underlie any product-led organization. It allows you to build trustworthy reporting and to inform your decisions with accurate and complete data. Importantly, operating with a system of record also allows your team to operate more flexibly. For instance, with a robust applicant-tracking system as the system of record for hiring activities, anyone can schedule a candidate’s next interview or answer a question about the candidate’s next steps based on a fully transparent view of the candidate’s activity up to that point. If one member of a recruiting team is out sick or on vacation, then another can easily step in with the benefit of full situational awareness. B2C has gotten this principle right out of necessity, but B2B has somehow still not caught up, continuing to rely instead on labyrinthine information flows rife with misdirection.
Realizing the value of the system of record requires leaders to draw lines in the sand. Every piece of an operating model must be founded on the system of record so that the work of every team member will compound in the product and lead to continuous improvement. In DevRev’s people ops team, we operate under the principle that “If it isn’t in the system of record, it didn’t happen.” All new hires, for instance, need to be managed through our applicant-tracking system since we have numerous automations to support employee onboarding that are dependent on having accurate data in the ATS. We have also learned that managing reporting through automatically refreshed dashboards rather than slides and forbidding the use of manually updated spreadsheets in ongoing processes are powerful design constraints to promote the growth of product. Working within these lines may be difficult initially (more on this later), but doing so is essential to ensure that the organization has a firm product foundation.

4) Decentralize power and enable the customer to take direct action
Just as most travelers looking to modify a flight itinerary would prefer to make basic changes themselves through an airline website, most standard operational workflows should be accessible to the user directly, allowing specialized team members to focus their efforts on complicated edge cases, situations needing white-glove attention, and opportunities for advancing the product forward on its roadmap. In a product-led hiring operation, for instance, a hiring manager should be able to schedule an interview for herself. At DevRev, our interviewers can schedule their own meetings with candidates in under 30 seconds using a bot in our chat app that lets them identify overlapping windows of availability between their schedules and the candidate’s schedule, choose an interview type and length, book a suitable slot, and send a confirmation email with a fully configured calendar invite to the candidate.
Most organizations orient themselves excessively toward internal secrecy and black-box processes, whether for reasons of internecine politics or merely the momentum of history - “It’s how we’ve always done it.” In stark contrast, the blossoming of Web3 - built on the premise that a decentralized architecture is more dynamic, scalable, and empowering to the individual user than a top-down monolith - shows the promise that new operating models can provide to forward-looking companies.

5) Start with the product, then build the team
Most organizations begin building a new function by making the first hire, and usually this hire is someone who brings specific experience in the relevant domain. The questions of how that function should operate and what tools should enable the function’s work come next, and naturally, the team’s prior experience will heavily inform the answers. This mimetic tendency leads the organization to replicate the operating model of a status quo that is generally process-anchored rather than product-led.
To build a function that operates differently from the status quo, you need to establish the product-led foundation before you start building out the team. The roles will differ in responsibilities from those in other organizations, the skills and interests of the people who will thrive in those roles will differ, and the success metrics against which you will ask them to perform will differ from the usual metrics. Many of the best hires for these roles, in fact, may be career-switchers coming from entirely different backgrounds, as their open minds and curiosity about a new space will enable them to adapt more quickly to your company’s distinctive way of operating.

6) Embrace the J-curve
It is critical to resist the siren song of the one-off short-cut when building a product-led operation. Setting up the initial version of a product, tweaking its configurations, and iterating on the necessary steps to complete an end-to-end workflow for the first time require significant commitment and effort. The output benefit, however, is back-loaded compared to what could be achieved through a traditional, brute-force, process-driven approach. In investment parlance, the journey toward product-led productivity follows a “J-curve.”

![image](https://cdn.sanity.io/images/umrbtih2/production/8cc43895647e18889c689140950f605e17f8e38c-982x982.png?w=982)

In the early phases of the journey, when you are working late into the night to figure out the right tech stack and to iterate on the necessary workflows, there will inevitably come a time when you are tempted to resort to a bespoke spreadsheet or a manual workflow just to get the job done. For those brave souls who pass through the “valley of doubt,” however, this upfront pain and investment will yield compounding returns.
For an operations organization to become product-led, managers in particular must fight the urge to optimize only on short-term output. Because managers are separated from the product-building work of the makers, the J-curve is not tangible to them. They may not appreciate the interim progress of a product under construction, and as a result, they may pass judgment on the efforts of the makers too early, believing mistakenly that their input efforts are not producing sufficient value.

7) Create a product roadmap to fight the invisibility of the J-curve
Just as the product managers and developers building a software product use a clear roadmap to strategize for and plan the capabilities and features that they will add in the future, operations functions should be approached in the same way. Functions like employee success, legal ops, and real estate can all benefit from an intentional product roadmap to guide their roll-out of new technology tools, their data architecture, and their use of user feedback to iterate on their offerings. Our operations team uses DevRev’s Trails to structure our functions and their sub-components, and each part in our organizational architecture has associated with it a clearly defined set of work items that are prioritized and tracked directly in the platform. With transparency into a product-led function’s architecture and a clearly articulated path forward, the maker and the manager can more easily pass through the J-curve’s valley of doubt.

8) Track goals, KPIs, and SLAs
A continuous iteration cycle depends on clearly laying out the top-level goals for every function, the KPIs that drive those goals, and the SLAs to which each activity should adhere. At DevRev, we define goals as the highest-order measurable objective for the company. These are typically lagging indicators (outputs), and in general, they should not change frequently. KPIs are intermediate indicators (often inputs) of performance in specific areas that help us either track progress toward our overall goals or achieve them more effectively. We see SLAs as the tactical operating metrics that ensure that we are operating at a customer-service standard (e.g., time to respond to a customer inquiry).
With a product architecture that automatically generates these metrics and disseminates them through transparent dashboards, an organization can eliminate countless hours of time spent creating one-off presentations. Instead of relying on stale information or spending senior-management and board meetings covering surface-level read-outs or debating facts, key decision-makers can instead operate from an evergreen and transparent view of organizational performance that allows them to focus their time on higher-order creative problem-solving and deeper, more substantive engagement with the company’s strategic priorities.

Taking a product-led approach to operations is a continuous and iterative journey that will allow you to unlock much greater potential for each of your functions than most organizations ever realize. Your users, both within and outside your organization, will thank you. You may even build the prototype for a new business!

The power of product-led business operations

## You have Jira

Almost 20 years ago, Jira redefined work for developers. The magical ticket management system fueled an era that was increasingly powered by the web browser, open source, and offshore development. Atlassian, the company behind Jira, was an original PLG company that let developers use its freemium software, no questions asked. Jira not only changed how we built software, but also how software companies worked. Engineering organizations went from expensive desktop tools to an affordable lightweight web application that upgraded often. Startups went from spreadsheets and emails to a system of record that helped scale their businesses.

Over the years, Jira went from being a bug tracking tool to a platform for workflows and product management. Companies went from monolithic waterfall release planning to agile development methodologies with sprints, epics, and stories. Agile became a necessity. Process was king.

Agile morphed into continuous integration and continuous deployment with the advent of cloud. Work became continuous and even more bite-sized, powered by informal chats and social conversations. Tickets became the new waterfall, and developers became loath to update them, while managers worried about the accuracy of their dashboards. Systems of record were now the breeding ground for vanity metrics such as developer productivity, story points, and burndown charts. The uncontrolled sprawl of metadata made developers crave for a system of engagement that was less informal, more delightful. Work needed to be more than a chore, a mere statistic.

## You like Slack

Jira had uncontrolled metadata, one KPI too many, and way more administration than what makers could fathom. More importantly, it celebrated process, and process alone. Product was relegated to component dropdowns at best. Customers were the domain of CRM systems. Users, no one bothered! After all, “users” were a B2C jargon, so why should a B2B software company care?

In the last decade, as B2B went SaaS, startups started to care about informal work and real-time collaboration, including with end users and partners. The informalism of GitHub Issues and Slack was very attractive to companies craving for end user feedback, product-market fit (PMF) jitters, and in-app-everything.

Slack was a master of all things informal. From emojis and reactions to grassroots channels and search, the social tool had made collaboration real-time, delightful, and mobile. Even machines could participate via their bots! That’s how egalitarian social could be. Of course, they had to shun all metadata – process, product, customer object models – to achieve their “work os” moniker. And that clean canvas thinking required creating a parallel universe of channels, one for every “boring” work item recorded by legacy systems of record.

Work, though, is beyond the walled garden of companies. The success of the cloud model – both the public cloud and the offshore delivery “cloud” – has proven beyond doubt that work will increasingly be done in partnership with others. Users of a product, through their community, will play an increasingly important role in improving product experiences, championing products, and partaking in web3 tokenomics of the brand. Work also needs insights, which, for better or worse, needs metadata around product catalog, user activity, and customer transactions.

So the key question is: how do you keep work social, while still preserving product- and user-centricity? What else can one make with one part oxygen, and two parts hydrogen?!

## You'll love DevRev

Those two parts of hydrogen are product-centricity and user-centricity, and social provides the oxygen to bind the product, the user, and all work together. There is no ‘P’ in PLG without the user, and that’s why we believe in PLuG. The identity of the user, the notifications to the user, the incentives of the user – they are all key to product engagement. At DevRev, we believe that makers – developers, engineers, and PMs – need to be plugged into the “matrix” of end users.

## PLuG (and Play!) 

Imagine you could add five lines of code into your application and now your app comes alive with an exhilaratingly simple real-time conversation widget to add social touch to all interactions.

What separates PLuG from other business messengers, though, is not just the ease of use in how you install and configure it, but also what happens when your customer success team is having real-time conversations with your users. Every conversation that is a customer problem immediately gets connected to a ticket that is linked to the right product “part” and tagged with the right developer or PM who owns that piece of code or feature. We call it Product-led User Growth (PLuG). We think this is the future of customer relationship management – real-time, maker-aware, and product-centric.

PLuG, over time, will help Product Managers(PMs) bypass spam marketing emails to educate, notify, and reward end users right in the application. The widget will also capture anonymized data around user behavior and error diagnostics to share with developers. The last mile of PLG will need you all to be totally plugged in!

## Real-time work, meet Play!

We designed a work management system built for the social product-led era.
Command line tools to create and update tasks from Github? 
Sure. 
Slack like channels for issues, tickets, features, and capabilities?
No problem.
Notifications to make sure you find and fix something even before your customers know about them? 
Why not?
All work items connected to your customers on one end and your code/product on the other?
Now, we are talking.
Self-healing code?
Keep guessing …

## Product-led. Customer-centered. Catalog-ready.

We built an exhilaratingly simple system of record for your product that shows you the full picture of features and capabilities of your product “catalog” and connected them back to your work items including real-time conversations. 

We call it Trails. 

Did we mention it updates in real-time when you check in code to Github?

## H20 in love!

The world’s first DevCRM platform – with its design, data, and machine intelligence – will make PLG come to life. With a freemium distribution model, we hope to make it as ubiquitous as water!

You’ve code.
You want Product-Market Fit.
You’ll love DevRev.

You’ve product.
You want Product-Led Growth.
You’ll love DevRev.

You’ve Jira.
You like Slack.
You’ll love DevRev.

[Sign up here](https://devrev.ai/landing/beta?utm_source=artclead&utm_medium=fb&utm_campaign=slackjiraarticle) and become a part of the next revolution that brings your work, catalog, and customers in one place. A place called DevRev.

You have Jira. You like Slack.  You’ll love DevRev!

Palo Alto, April 20, 2022:  DevRev, a business software company bringing Developers closer to their customers (Revenue), today announced the beta release of their platform.

Launching as the world’s first Developer Customer Relationship Management (Dev CRM) platform, DevRev brings together the holy trinity of product-led companies – product,  customer, and developer.

The company announced that over 100 customers have already signed up for beta. 

The beta release represents a year’s effort from 100 DevRev developers, a grand total of 10,000 pull requests and hundreds of hours of customer interviews.

DevRev brings together customer conversations, work management with real-time collaboration, and a system of record for product in a single platform. You can read more about the DevRev capabilities [here](https://devrev.ai/assets/deck/april2022.pdf) and walk through the demo [here](https://devrev.ai/beta-demo).


**About DevRev**

DevRev is a business software company that brings developers and customers together in the era of product-led growth. The company is building an API-first, dev-centric CRM that leverages data, design, and machine intelligence to empower developers to build, support, and grow their businesses. In times of anemic NPS and high customer churn, DevRev strives to create the world's most customer-centric companies led by happy developers. Grok and grep more on DevRev via the web, Twitter, and LinkedIn.

DevRev launches their DevCRM beta, a platform for Product-Led companies

Rome wasn’t built in a day. Creation takes time. But it also takes energy, vision, and sometimes conflict, sacrifices, and constant experiments every step of the way. In this process of building brick by brick, it is often the milestones that help us pull back and reflect on how far we have come and how much farther we have to go.

Today is one of those milestones. 

Today we are announcing the General Availability of DevRev, the world’s first DevCRM. In addition, we are also announcing the first app on the platform: product-led support aimed at a new breed of product-led companies looking to support their customers with code, and automation and looking to bring their customers and customer support engineers closer to their developers.

## Product-led support

A new breed of companies is leading the way in supporting their customers by tying customer interactions with product features and creating bespoke workflows that smartly detect issues even before users are aware of them and proactively fix them. This requires stitching systems like live chat widgets, customer identity, a support ticketing system, and a backend work management tool like Jira.

With DevRev’s product-led support, companies can now connect customer conversations with a ticketing and Knowledge-based platform with an integrated issues management workflow connected to the product features. All of this with real-time multiplayer collaboration and connections to other apps that companies currently use like Jira, Slack, and GitHub.

Let’s take a [look](https://youtu.be/5OqdQPHWvw0)

## PLS features:

Here are some of the things you can take advantage of right away by signing up for free on DevRev:
**PLuG Conversation widget:**

With a few lines of code, Install an in-app conversation widget that opens up real-time communication with your customers. We call this the PLuG widget.
![image](https://cdn.sanity.io/images/umrbtih2/production/d09d719234cf6b2e8db4cdaa8f8f598912c536a8-512x872.png?w=512)

**Realtime updates for your users:** Keep your users always in the loop, with real-time status of their tickets, through the PLuG widget integrated with the PLuG Inbox.

![image](https://cdn.sanity.io/images/umrbtih2/production/7e6f66023d59cf48eafb8afc4e0639dd35147c9a-1514x946.png?w=1514)


**Knowledge-based articles and their management:** Along with adding and managing KB articles by DevOrg, users now have the ability to search them through PLuG widget.  

**Never miss your messages:** Whether your customers are chatting with you on PLuG or responding to your email, you can now stay notified 24x7.

**Convergence of Conversations, Tickets, and Issues:**
Track all your customer requests from within the conversations with a ticket. Connect and track developer work by connecting tickets with issues. Watch bi-directional updates flow through the system for effective customer-centricity. 

![image](https://cdn.sanity.io/images/umrbtih2/production/6a3b71e15e07448d50977cd5c3f7b2ad39f83466-1380x938.png?w=1380)


**Real-time, social collaboration with the entire team:** With Slack-like features, work with your colleagues as if they are sitting right next to you. 

![image](https://cdn.sanity.io/images/umrbtih2/production/499d312c322a63c0dbac1e301185ee187721d5c0-1224x900.png?w=1224)

**Work management with Vistas:**
Create views of your team’s work and share them with others. We call it Vistas.

![image](https://cdn.sanity.io/images/umrbtih2/production/0db02faa28611c112df0b2b23e6ae9626a41d324-1440x900.png?w=1440)


**Integration with your favorite apps:** Integrate your favorite apps like Github, Bitbucket, Jira, Slack, Linear, and many more.
 
**Interact with DevRev from Slack:** Never leave your customers in the dark! Create DevRev tickets and keep customers up to date without ever leaving Slack. Create DevRev tickets or issues from Slack conversations and stay up to date as the status of the work items change.

![image](https://cdn.sanity.io/images/umrbtih2/production/59d9fb9670387341710f5e18387126182df612f4-1400x930.png?w=1400)


**Automatic GitHub Updates:** Put your work in autopilot with Github and DevRev and make updates in real-time, and make your developer free from doing status updates.

**Product System of Record with Trails:**
Connect your code from your repository (Github, Bitbucket, etc.) and map them to features used by your customers and connect to issues and tickets. This is the true essence of product-centricity.

![image](https://cdn.sanity.io/images/umrbtih2/production/9e63afd16b5f87baf4b20702bee150bd7f8b34e5-1440x900.png?w=1440)


These are only some of the features we are releasing today.

Sign up for free [here](https://app.devrev.ai/) and hit the PLuG icon in the bottom left corner of the screen to chat with us.

We have just started our journey of a thousand miles and we hope you join us as we build the first operating system for PLG companies. 


The birth of a new platform for PLG  companies

## Tech’s employee attrition problem

Employee turnover is one of the major issues affecting tech companies today. According to a Linkedin study, the tech industry has the highest turnover rate out of any sector at more than 13%. According to the US Bureau of Labor Statistics, the turnover rate is double the industry average for tech startups. It can take months to get a new employee up-to-speed and able to contribute fully. Moreover, recruiting and onboarding a new employee can take up to nine months worth of the employee's salary. Thus the inability of the tech sector to keep its employees motivated to build and grow within the organization is a huge challenge for every organization.

There are numerous reasons for the high attrition numbers across the industry. A big driver of the short tenure of employees is seeking more responsibility and being able to understand the “why” and the impact of their work. Too often, developers work on tickets and issues without a sense of real purpose, as they are far-removed from the actual end-user. They do not have direct access to the customer, and their teams are isolated from customer-facing ones. They become too project-oriented, and lose the sense of the “why” behind the product. They do not have any sense of what commercial and business impact the list of work items they are working on is having on the organization. Over time, the monotony of their day-to-day and the lack of real sense behind their work cause them to look for other opportunities, costing businesses tens of thousands of dollars per employee and months of lost productivity.

## How DevRev will be the critical platform to retain and motivate employees

This is where DevRev comes in. DevRev is building the world’s first Developer CRM that is breaking down organizational silos, and connecting makers to their end users as they build, operate, support and grow their businesses. Through the DevRev platform, every work item that the developer is working on can be brought under a single operating system that directly ties the work to customer impact. The developer is able to see exactly the source and the “why” of an issue or ticket that was generated, and how exactly the code that is worked on will enhance specific parts of the product. Hence, the developer is able to track in real-time the direct impact of the work item on the end-user and what exact parts of the product are being enhanced. Furthermore, the maker will eventually be able to see the direct commercial impact of the work item, as the issues and tickets will be enriched with commercial data such that the revenue/contract-value that will be captured by the completion of the work will be visible to the maker. DevRev will serve as a unified product and customer system of record, enabling the developer to prioritize work based on customer impact, focus on what really matters to delight the end-user and capture the business impact of each work item. There will be no more status meetings as every customer touchpoint and product enhancement will be linked together. As a result, DevRev will empower makers to directly tie every single work item to real customer impact and capture the “why” of their day-to-day. Product teams will move away from project-centricity towards product-centricity and track in real-time the direct impact they are having on their end-users. This will be a key driver for businesses to keep their employees motivated and satisfied. The end result will be a hungrier team working towards a unified vision and much better employee retention for the company.

Tech workers are more mobile than ever. Hybrid work is here to stay and demand for top talent will continue to grow. As a result, retention of top talent should be a major priority for every tech company. One of the keys to reduce attrition is to keep employees motivated by showing them the impact their work has on their end-users and the commercial metrics of the business. DevRev’s first-of-its-kind DevCRM platform will connect the makers to the customers, remove artificial siloes between teams of the organization, and serve as a central system of record that will connect every issue and ticket directly to customer impact. DevRev will thus become a critical platform for businesses to keep their teams aligned, motivated and customer-centric. The end result will be a much more coherent workforce and much higher retention numbers for the company.


Importance of DevCRM to improve employee retention

Podim

DevRev enabling developers to build the earth’s most customer-centric companies

The PLuG platform in DevRev was created by support people for support people.

I’m going to outline three different support team structures I’ve worked with, pros and cons of each, and how I’d recommend setting up DevRev based on each team structure.

Let’s start with the definitions.

1. Product Centric
2. Tiered
3. Chaos

**Product Centric** refers to teams where you have on or a few dedicated subject matter experts for each part of your product (or each of your products). This can be combined with a tiered approach but should still roughly center around products or parts of products.

Pros: Allows for in depth subject matter expertise, build relationships with specific PMs/Devs

Cons: Information may be siloed, in case of absence high impact if there are only one or two people per part

**By Tier:** There are typically 2 or 3 tiers. Tier 1 is the first point of contact and typically does routing and may handle simple account issues. Tier 2 are typically more technical and can perform troubleshooting tasks. Tier 3 is usually the Support Engineers who can and do write code and do advanced troubleshooting

Pros: Gives some sense of career progression, faster first response time

Cons: Negative impact to CSAT due to switching agents multiple times, unnecessary cost as many Tier 1 tasks can be automated

**Chaos:** Chaos is a bit of a dramatic word to use here but it’s at least descriptive. This is usually a very small team. Any agent answers any conversation incoming. In the case of email support they may not own a conversation end to end and that conversation is just answered by whoever sees the next response first

Pros: Minimal information siloing

Cons: Lots of context switching, lowered CSAT due to agent switching

## Which Structure is the Best?

All three have a place depending on the size of your organization, type of customer, and product.

If you are an **early stage startup** **with only one or two support agents**, a formal tiered approach does not make sense. A product centric approach also does not make sense as there are not enough people to have knowledge redundancies if someone is out for the day. A **chaos** **approach** here works best. My recommendation is for agents to see all of their conversations through from first pickup to close to reduce the number of handoffs. Research has shown that the more times a conversation changes agents, the lower the CSAT score will be. You can take an informal tiered approach here in addition to the chaos method. If a support agent has done all they reasonably can to resolve an issue, now it may be time to share the conversation with a developer or product manager.

If you are an **early stage startup with no support agents** however, a **product centric approach** makes the most sense. While I admire a CEO willing to roll up their sleeves and answer incoming customer support queries so their engineers can focus, there is important context in those conversations that your engineers and product managers will benefit from. If youThose who work on a specific product/part should answer conversations related to their work. This reduces context switching and time to resolution. This approach is challenged however if you have parts or products that haven’t been launched yet. Here you need to make a decision whether the ability to reduce context switching for groups whose work hasn’t launched yet is more important than the ability to respond to customers quickly. I’d recommend using as much automation as possible and sharing some of the workload across the teams. Context switching can be valuable if it gives broader insight into the overall product.

If you are at a stage where you have e**nough support agents to dedicate one or two to each part/product**, I’d recommend taking the **product centric approach**. If you only have enough agents for one per product/part, pair up so each agent actually becomes a subject matter expert on one and highly proficient in another thus creating knowledge redundancy in case the subject matter expert is out. 

Last, as teams **grow and scale**, there is a natural urge to fall into a tiered system. I’d urge you to resist this as long as possible. Instead of having a Tier 1 to answer “easy” or “known issue” type questions, consider why those questions are being asked in the first place. Is there a way the product or system can be improved so no one ever asks those questions again? Create automations and knowledge articles around them in the interim. You may still want a **Tier 2 and 3 and this can be done while remaining product centric**. Tier 2 should be subject matter experts in their respective products/parts and perform advanced troubleshooting. Tier 3 should act as mini product managers interfacing often with engineering, product, and marketing to communicate technical questions/needs, product requests/needs, and clarification on marketing materials. Before you reach a tiered system, these functions should be owned still by the subject matter experts from the product centric approach.

## How do I do this in DevRev?

First, take a moment to assess the current organization in your support team. Are you currently taking the best approach for you or should you try out a new method? Once you’ve decided, it’s time to onboard and implement DevRev.

If you’ve already set up your account and integrations that’s great! If not, visit our [documentation](http://devrev.ai/docs). You can get started without all of these steps but will get the greatest value if you are fully onboarded.

### Set up your Ticket Vistas

**Chaos:**

Untriaged, Triaged, Closed sorted by Date

These allow each member of the team to see Tickets that have yet to be triaged, the ones in progress, and just as importantly the ones recently closed so you can let your end users know in a change has been deployed in their Conversations.

**Product Centric:**

By Part(s), Group by Status

Breaking your Tickets down by product provides each owner/group a quick reference to what is most relevant to them. Grouping them by Status allows each owner/group to quickly see which have been recently closed to update those Conversations and which are awaiting triaging, in progress, etc.

**Tiered:**

Untriaged, Triaged, Closed sorted by Date

Similar to the Chaos method, this allows each member of the team to quickly find what’s most relevant to them.

**Tiered + Product Centric:**

By Part(s), Group by Status

Similar to the product centric method, it provides the information of the Tiered approach and the Product centric approach while keeping the Products/Parts separate

## Coming Soon:

Custom Inboxes - Sort your conversations

Flows - Write all the automations you desire
Routing - Assign incoming conversations to your team based on their strengths

SLA - Keep your team informed of SLAs

CSAT - Gather feedback about your interactions with customers

Want a feature not listed? Use the PLuG widget on our site to send us a message or email us at support@devrev.ai

Support & DevRev

On Wednesday, June 22, 2022, members of the DevRev circle had an opportunity to meet and listen to Martin Gontovnikos. Gontovnikos previously worked with Auth0, where he successfully led growth and marketing efforts and helped the company grow its ARR from $0 to 9 figures. He is currently a co-founder of and partner at HyperGrowth Partners. The talk focused on Gontovnikos’ experience with PLG (Product-led Growth).

“PLG is using the product to drive revenue,” said Gonto. “What that means is that because what you're using is the product, what matters about PLG is that you focus on the user and their experience.”

He went on to elaborate on how typically the focus is on the decision maker but has now shifted to the user. The overarching idea was that if the user has a good experience, they would use the product as well as recommend it to others. “User retention makes or breaks any PLG SaaS,” Gonto summarized.

He gave the example of Android apps. With the help of a graph of retention curves for Android apps, he showed that there is a strong correlation between the number of downloads an app gets and the user retention rate. 

Gonto clarified that while the primary focus at PLG company should be on the user, that’s not the only place where the focus must be. The users may bring their ideas and suggestions to the decision makers at the company, who would then decide what the best move forward would be. He addressed the presence of availability bias here and explained how the decision maker would be more likely to use a service or address an issue that they already know exists.

He then went on to address where it makes sense for companies to do PLG. The first question that he proposed was whether the user has a say in the decision? “The idea here is that if the user doesn't have a say or their opinion doesn't matter to the decision maker, then doing product-led growth doesn't make sense,” he explained.

Furthermore, doing PLG is effective when the product is useful for a small team. Gonto explained how it is easier to get small teams to test out a product, who can then recommend it to other teams at their companies and if enough teams use the product, the company can buy it. Conversely, if the product is not useful for a small team and needs to be adopted by the entire company, then PLG is going to be difficult and ineffective. In a similar vein, PLG is more effective when the product’s usefulness increases as more teams across a company use it.

Additionally, the product needs to have a good UX and onboarding so that it is easier for teams to start using it and that they want to continue using it once they start.

Gonto then went on to talk about the role of marketing in PLG. “Something that, to me, is important about marketing is that if you're targeting the user, something you should always do is start with doing some habits research,” he said. “The research is focused on what the user does on their day to day, how they do it, how they think about it, what they do?”

Talking about his experience doing market research at Auth0, he said, “We looked for developers on Twitter that we had as followers or similarly we looked at Linkedin for developers from different companies that we thought were interesting like an enterprise one, a startup one and something like that and we just contact them with a twitter DM or with a linkedin invite telling them, hey we're doing research, I want 30 minutes of your time for a call and we’ll offer you 100 bucks. That’s it. We just asked questions using that.”

Gonto emphasized that community is a must for marketing. “Creating a community is creating support for your users to help each other and slowly move in the same direction,” he said. 

DevRev has embraced this need for community with our exclusive and limited DevRev circle. DevRev Circle is a community of entrepreneurs, developers and investors who are passionate about learning and sharing their knowledge about product-led methodology to build successful businesses. The group provides resources, advice, and networking opportunities that can help your business achieve PLG goals, including talks like these. 

Those interested can find out more about DevRev circle [here](https://devrev.ai/circle/).
The full video of the circle talk with Martin Gonto can be found [here](https://vimeo.com/723631805).

Circle talk: Martin Gonto

PALO ALTO, CA--July 14, 2021--[DevRev](https://devrev.ai), a new business software company focused on bringing developers closer to customers and revenue, emerged from stealth mode today, to work with early adopters in making the product generally available in 2022. The startup launches with $50 million in seed funding and a highly experienced leadership team headed by Dheeraj Pandey, Nutanix (NASDAQ: NTNX) co-founder and former CEO and current board member at Adobe (NASDAQ: ADBE). 

Pandey is DevRev's co-founder and CEO, alongside co-founder Manoj Agarwal, former Nutanix SVP of engineering. Backed by investors including Mayfield Fund, Khosla Ventures, and several industry luminaries, DevRev has already recruited more than 75 people and is relentlessly focused on making itself "customer zero" this year. 

“Today, every company is a software company, yet we isolate developers (dev) from customers and revenue (rev)," said DevRev CEO Pandey. "By removing the bureaucracy between makers and consumers — with APIs, design, and an opinionated engagement model — we will empower devs to create customer-conscious products and businesses. That’s our mission: bring dev and rev together!”

DevRev aims to make life meaningfully simpler for developers so they no longer have to work across silos of systems. Driven by design-first, API-first, and machine intelligence culture, DevRev will enable developers and customers to communicate and collaborate with each other socially and in real-time.

“Being product builders ourselves, Dheeraj and I have both felt the pain in leaving developers in the back-office," said DevRev Co-founder Agarwal. "With a headless dev-centric CRM vision, we are looking to bring developers to the forefront of decision-making and real-time customer collaboration.”

Using the platform DevRev is creating, the developer will be able to connect their code to production issues and customer interactions in a singular unified experience. The company’s offering will help developers create modern product-led growth (PLG) companies that are cloud-centric and service-oriented.

“As People-first investors who partner with entrepreneurs at the inception stage, we are honored to support Dheeraj, Manoj and the team at DevRev with seed funding,” noted Mayfield Fund Managing Director Navin Chaddha. “We believe their focus on elevating developers to business leaders by removing the barriers to revenue leverages the Rise of the Individual movement, and will help them grow into an iconic company. We look forward to watching them build an innovative new category and a long-lasting developer community.”

"Often the code, which developers end up writing or modifying, has little to no input on how customers use their product and its features," said Khosla Ventures Founder and Partner Vinod Khosla. "DevRev's bold, yet simple vision to bring developers closer to customers is one of those groundbreaking ideas we feel will impact every single company in the future."

A true post-pandemic company, DevRev is remote-first and maintains purely digital operations, using social platforms to recruit talent, generate ideas, and build a community around its product. With automation, search, and a unique product-led candidate experience, the company has built a stellar team of DevRevelers in less than six months. The company is building its team in Austin, Bangalore, Ljubljana (Slovenia), and the San Francisco Bay area.

**About DevRev**

DevRev is a business software company that brings developers and customers together in the era of product-led growth. The company is building an API-first dev-centric CRM that leverages data, design, and machine intelligence to empower developers to build, support, and grow their business. In times of anemic NPS and high customer churn, DevRev strives to create the world's most customer-centric companies led by happy developers. Grok and grep more on DevRev via the [web](https://devrev.ai), [Twitter](https://twitter.com/devrevinc) and [LinkedIn](https://www.linkedin.com/company/devrev/).

DevRev launches with $50 million in seed funding and a Dev-Centric CRM for the Product-Led Growth era

SaaS coupled with free pricing options has created a market for developers where they can quickly iterate with customers through their code to create apps at the speed of light. All you need is GitHub for your code, Slack for collaboration, and AWS to host your service. These intuitive developer first tools have enabled thousands of startups to reach millions of people across the globe with their new ideas. An engineer with the right APIs can build features and integrations which previously required several project teams to execute for years. And imagine if you have a thriving community of customers and developers who are collectively building your product- the possibilities of a customer-led product development are limitless.

We at [DevRev](https://medium.com/devrev/the-why-and-what-of-devrev-f0485e0b97dc) believe that this phenomenon will redefine the way companies have been thinking of [Customer Relationship Management (CRM) platforms](https://financesonline.com/list-10-best-crm-software-tools/). CRMs that were considered sales, support, or marketing tools will evolve into managing the relationship between the developers and their customers. The Developer CRM plans to change the traditional models that ignore the customer and the product in the tedious agile project management process of churning out sprints with bugs and features. Dev CRM aims to provide a platform for the developers and their customers to jointly work on the product in a “bazaar” like model which has its roots in the open-source community.

![image](https://cdn.sanity.io/images/umrbtih2/production/1ddf3bf61dbbbe28e207ad94538478472a06036b-1400x933.jpg?w=1400)
A bazaar in Jerusalem — Courtesy Unsplash


**Origins of the bazaar in open-source**

Software industry was heavily licensed and commercial vendors made sure that developers could not study, change or share source code of their software products. Richard Stallman started the [Free Software](https://en.wikipedia.org/wiki/Free_Software_Foundation) Foundation in the mid-80s to revive the founding spirit of collaboration and curiosity among developers which was prevalent since the early days of computing. Free software foundation gave birth to the freedom-respecting [GNU](https://www.gnu.org/home.en.html) operating system where hackers could create, share and modify the source code.

It wasn’t however till the mid-90s that the “open-source” word came to being when Eric Raymond wrote “[Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)” and started the [Open Source Initiative](https://opensource.org/). The open-source revolution was a rebellion against the unfair “tax” software industry imposed on the makers of that age. Hackers of that age were getting increasingly impatient with how the industry was killing their creative freedom. Not only was the software free but even the development process for the software was decentralized and open for hackers to contribute. Thus came about the free “bazaar” model of software development which was contrary to the command and control style of a “cathedral” model.

![image](https://cdn.sanity.io/images/umrbtih2/production/1a60cd24c49c99772fbd7912c17226a87a803eef-1400x933.jpg?w=1400)
Alex Kotliarskyi on UnSplash


It almost sounded too good to be true at that time. A “free and fair” utopia where everyone gets to “share and care” for each other’s code. Developers started with fundamental building blocks of operating systems and databases to build their metaverse on top of it. The bazaar was open for business, the only problem was that the rules of the bazaar are still not codified and continue to evolve like the code.

In his seminal paper and later a book titled “[Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)” Eric S Raymond writes:

*Linux evolved in a completely different way. From nearly the beginning, it was rather casually hacked on by huge numbers of volunteers coordinating only through the Internet. Quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback from hundreds of users within days, creating a sort of rapid Darwinian selection on the mutations introduced by developers. To the amazement of almost everyone, this worked quite well.*

When I read this, I am almost forced to draw parallels of this style of software development to our current [CI/CD](https://www.redhat.com/en/topics/devops/what-is-ci-cd) (Continuous Integration Continuous Delivery) methodology in the devops cloud native world. Also, the industry has now universally accepted the practice of releasing Minimal Viable Products (MVPs) and everyone gets feedback from users almost immediately and builds iteratively. While there are several things to learn from this model, I will focus on the software development style of the bazaar in the rest of this article.

Numerous open-source projects have followed the bazaar style of software development and became an integral part of our day-to-day lives. Github is the de-facto platform where open source thrives. Ironically, the biggest detractor of open source software [Microsoft bought Github for $7.5 billion dollars](https://news.microsoft.com/announcement/microsoft-acquires-github/). According to a [2021 study by Synopsys](https://www.securitymagazine.com/articles/92368-synopsys-study-shows-91-of-commercial-applications-contain-outdated-or-abandoned-open-source-components#), 70 percent of the audited code was found to be open source . This number was only 36 percent in 2015. Microsoft’s Visual Studio code editor is an extremely popular open-source repo in Github with over 107k+ stars and 19K+ contributors. (DevRev is hosting a [hackathon](https://devrev.ai/hack0/) to develop a VScode extension powered by [OpenAI Codex](https://www.youtube.com/watch?v=SGUCcjHTmGY) to make developers’ lives easier with AI).

**The evolution of the software bazaar**

In a series of articles, I will go through the evolution of the bazaar from the days of Linux to Web 1.0, Web 2.0, and now Web 3.0. A story where the bazaar always made it easier for the underdog “hacker” to build their idea and disrupt the incumbents, one which always thrived on decentralization and innovation to power its activity. This bazaar also thrived on chaos and collaboration to produce one of the most resilient and reliable systems humans have ever built. Bazaar, almost self-governing and self selective, was inclusive to those who could code but still excluded the majority. A bazaar that was supposed to be fair yet gave tremendous control and advantage to a few. A bazaar that took many forms since its inception — .com, Internet, Social Media, Big Data, Cloud, DevOps, SaaS, Crypto, and Metaverse.

A bazaar that reminds us of the chaotic and lively bazaars of the Middle East and Asia where “artisans” adorn hundreds of shops in meandering lanes and customers experience diverse aromas, colors, and most importantly seeking serendipity in their normal and boring lives. In the bazaar, interactions are not transactional but the belief is in creating trust through personalized care. The bazaar might look chaotic but there is a method to the madness which has endured through civilizations.

A bazaar where the customers are finally free to try out SaaS goods and services without hitting a paywall. A bazaar where the quality of the product speaks for itself and everything is product-led. A bazaar where you could host your product in the cloud and reach out to anyone in the world. A bazaar where the developers can build, operate, support, and grow their businesses. A bazaar where customers can lead the makers to the product.

**10 principles of a Developer CRM**

I have tried to distill the lessons shared by Eric S Raymond during his open-source journey in the 90s with Fetchmail below. These ten principles hold true even today and apply not only to open source projects but also to any commercial software, especially SaaS. To me, these are fundamental to the thesis of Dev CRM and what DevRev is hoping to achieve by rethinking the agile software development process.

**1. Write, rewrite, and reuse code**

Initial Linux code was borrowed from Minix, a tiny Unix-like OS. Eventually, the Minix code was rewritten and most of it went away but it did provide the initial skeleton to the infant which would become Linux. Open source communities like Discord are thriving on GitHub with developers reusing code from javascript libraries and contributing from across the world.

![image](https://cdn.sanity.io/images/umrbtih2/production/7289ba10a094885bf13b42a1de70974b40d329cd-1400x1107.png?w=1400)
Discord Open Source Community on GitHub https://octoverse.github.com/sustainable-communities/

**2. Start small and iterate**

You often don’t understand a problem until you build an initial solution. This is particularly true for software and gave rise to the “hacker” culture. Linux went through several iterations before it became such an elegant and powerful OS. The Linux archives are a great resource for curious minds. This holds true for any feature you build in your product as it goes through several iterations in its API or UI design. The process of crawl, walk and run which needs to be memorialized in a SoR just like the Linux mailing lists as they are a treasure trove of context for anyone looking to learn and contribute to code. This also helps through the “hacking” process where small ideas and optimizations can turn into side projects and evolve into mega projects later. The Apache Software foundation is a classic example where a bunch of users came together to support and maintain the HTTPD web server written at NCSA. They started to make incremental changes, bug fixes and shared information on how to improve it. Today more than 65% of the web sites in the world are powered by the HTTPD web server. The Apache Software Foundation exploded and gave rise to the “Big Data” movement with popular tools like Spark, Presto,

**3. Release early and release often**

Early and frequent releases were a culture that the Linux community had nurtured from the early days. Even though it was something as complex and critical as an operating system, the buggy releases flew off the pipeline real fast. This was a testament to the trust folks had in the community to do the right thing and their user base to bear the pain of buggy software. Software developers should also do incremental commits on their branches to make integration easier and more frequent. It is common for SaaS companies these days to have weekly releases with “feature flags” to make sure they can incrementally roll out and test features with their users.

![image](https://cdn.sanity.io/images/umrbtih2/production/cf6260955dc42b083a6b844a3a19475ab2bcece2-1400x1866.jpg?w=1400)
Courtesy : Manasvita S. Unsplash

**4. Users as partners**

If your tool is for developers, a lot of users will be coders too. Because the source code is available in an open-source model, they can be effective co-developers as well. Users can help you with debugging, triage, troubleshooting, and even suggest fixes. This almost creates a flywheel which increases the velocity and shapes the direction of the product. In Linux, the Lisp code pool was user-driven and the collaboration was fuelled through the internet. In the SaaS world, GitLab has applied this principle to build an open core software development platform where the users can contribute to the code and build as partners. DevCRM creates a process around which companies can pivot/micro pivot to find the elusive product market fit.

**5. Empowered user community**

The bazaar style advocates empowered users who have direct access to the developers and the prioritization of their bugs and features. The roadmap should be shared transparently and there needs to be feedback loop to any new features released. This builds the new age moat for your business called “community” and helps your product become a platform with all the goodness of network effects. DevCRM brings the customers into the agile software development process of the developers.

![image](https://cdn.sanity.io/images/umrbtih2/production/cc979e0710b1d05efbe22f09b4fb82a2456d493d-1400x2100.jpg?w=1400)
Courtesy : Kobu Agency on Unsplash

**6. Linus’s Law — More eyes on code = all bugs are shallow**

Bugs are especially hard to tame when the tester is looking outside in and the coder is looking inside out. They tend to talk over each other. It becomes much easier when both have source code visibility and can communicate with the same mental model. It’s even better when beta testers can not only look at symptoms but also the underlying root cause and code. This saves time for the developer as well.

**7. Collaboration at scale**

For folks who have worked on software projects, we all know that adding more developers necessarily does not lead to greater velocity. As more people are added to a project or codebase, communication and collaboration drains time and also more bugs start to creep in. Imagine running an open-source project with so many contributors.
The open-source community scaled this through a hub and spoke model. The the “halo” or peripheral developers worked on independent parallel tasks which required no communication; whereas code change reviews and bug reports streamed through a small core group that had to communicate and collaborate amongst each other. This style of organizing product teams has especially gained popularity in today’s age when you have platform or core teams that work with independent feature teams through loosely coupled microservices.

**8. User’s idea is your feature**

Recognizing good ideas from users and being self-deprecating and truthfully honest about them is probably the most important part of gaining your user’s trust. Easier said than done. This requires courage and humility. By accepting and making their ideas into features, you make them “owners” of the product. More importantly you should maniacally mine all the user ideas and pick the ones which could be the next killer feature. Also its very important to build these features very closely with the users so that they can stay as pure as possible. It is very easy to lose those nuances as the idea comes to life in code. Dev CRM will be critical to take customer ideas to develop product features.

![image](https://cdn.sanity.io/images/umrbtih2/production/72b4ca3895b51e1a2b0362b5fb6600648e12acc7-1400x1180.png?w=1400)
Reddit : r/ProgrammerHumor

**9. Think hard about the problem**

“More often than not when I have hit a dead end while trying to solve a problem. I end up asking myself if I am solving the right problem or am I asking the right questions to understand the problem”. This especially holds true when we are encountered with design problems. The assumptions and understanding of the customer’s pain point is critical to the development of a feature. In the open source world-community boards have been critical in surfacing user’s pain point and fostering discussions through “Threads”. These “Threads” have time and again inspired several developers to come up with ideas and build great products.

![image](https://cdn.sanity.io/images/umrbtih2/production/d53f05da65df73b8ac9c90275a17762e56d78589-1400x1607.png?w=1400)
Reddit : r/javascript

**10. Less is more**

Last but not least, do not hesitate to throw away code or features in your product to make it more elegant and simplistic. This is especially true in a self-serve product-led era where the user has to discover and love the product without any guides or training. Eric aptly summarizes -
‘‘Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.’’
Conclusion
These 10 principles of software development hold true even today as the release cycles have become shorter and more rapid. Yet, as a developer or even product managers, we have to constantly remind ourselves of these software development principles to get closer to what matters the most when building something new — our customers.

10 software development principles that power a Dev CRM

Modena, a small town in Italy, is known for two unique characteristics. In some culinary circles, it is known for the balsamic vinegar that this town produces. But more prominently, Modena is also known for being the headquarters or in the vicinity of some famous car manufactures like Ferrari, Lamborghini, and Maserati. What is not widely known about this town, though, are two words that have been embedded in its Coat of arms for centuries and describes this town’s motto — *Avia Pervia.*

The words loosely translated means make hard paths simple (to travel).

If you believe we are witnessing the third industrial revolution with practically all aspects of human interactions turning digital, then you know that every company is turning into a software company. In fact, one would argue that the last 15 months have only accelerated that catalysis with one added additional twist — A lot of companies have not just turned into software, they have started to use more and more AI in invisible ways.

As accelerated digital journeys drive more data, I believe Machine Learning (ML) and AI have opened up new frontiers and a new way of building and running an organization. I believe this has also pushed us to the cusp of a dramatic new shift in how products are made, operated, and eventually sold to and used by customers.

If you believe that the humble developer/engineer is at the heart of this new revolution, given that all digital is code, you are not alone. Over the years, code has become akin to an assembly line of building products and experiences. You build something; you ship it, someone starts selling it, and at some point, customers start signing up and using the product. However, unlike a traditional product, digital companies are creating experiences where the creation process does not stop after you ship the code. In fact, most of these products and experiences have an operating dimension, a support dimension, and a growth dimension, all revolving around the customer.

Over the years, as companies have poured billions of dollars into building the right product experiences for their customers, the developers, engineers and the makers have gotten further and further away from the customers. Further and further away from the revenue.

If you believe, as an engineer/developer, that things could be better, that creation doesn’t stop at shipping code, and driving relentless improvements is as critical as building new features, then you are not alone.

If you believe that building and managing, growing, and nurturing are parts of the same coin and if you believe that you have a say in how things could be better, you are not alone.

If you believe that design and code are an integral part of the creative process and that the only reason a company exists is because of the customer and their relationship to the product, then we have something in common. We have embarked on a lofty vision of putting developers closer to the product, the customers, and revenue, and we are excited about the opportunities, the avenues, and the terrains we intend to open up and explore.

We are looking for engineers, designers, makers who share the same beliefs and ideals as us and those who believe that there is hope on the horizon when it comes to solving hairy problems of how to run a company in the modern era with the help of ML and AI.

It is not every day that an opportunity comes knocking with the germination of an idea which, when addressed with full intention, could change the way future organizations can work for the better. It is not every day that you get to work with the best of the best who drive you to build something better and become a better human being in the process.

If you believe that all of this resonates with your own core values; If you believe in Avia Pervia, then you are one of us.

Come work with us.

[https://devrev.ai/you](https://devrev.ai/you)

If you believe

As an introvert, not every office environment is right for me. 

I’ve had some miserable experiences where I've felt trapped, uncomfortable, and unproductive because of my environment and the working culture. 

I’ve always been drawn towards startups because they have endless opportunities to learn and create value; however, the stereotype that startups are nonstop, highly collaborative, in-person environments exists for a reason… those are real! 

## Things to know about this introvert

There is a general misconception that introverts don’t like being around other people. 

My colleagues are generally shocked and don’t believe me when I tell them that I am an introvert because I'm gregarious and deeply engaged when interacting with others. 

I’ve even built my career around finding ways to make people’s lives more efficient, productive, and enjoyable. Because at the end of the day, **I love people!**

But in order to be most effective in every area of my life, I need time to recharge and reflect. I like to think deeply about my experiences and the problems I’m trying to solve, and I cannot do that in a crowded noisy office. 

I often do my best thinking on a walk or journaling with a cup of tea on a Sunday morning so if a startup wants to maximize my value, I need some space and flexibility to recharge and reflect. 

## 4 Things to Look for When Evaluating a Startup to Join

**Flexible Work Culture**

This is the most ideal state for a startup to be in. It signals to me that they trust their employees to get their work done by their deadlines however they see fit. 

Even if I did not need some peace and quiet every once and a while, this is a great indicator that a company cares about you as a person as well as their bottom line. 

When a startup realizes its employees have other needs besides sitting in a chair at a desk for 8 hrs, my heart sings. 

I want to be here in the next several decades so being able to take breaks without taking time off to go to the gym or a doctor's appointment is hugely important to me. 

The change of environment and context switch allows me to synthesize the work I’ve done that day. 
 
**Remote Work Friendly**

Beyond working when you want to work within a flexible work culture, the ability to choose where you want to work is key. 

I love connecting and collaborating with my colleagues in the office, but I find the feeling of needing to be “on” for them exhausting if I have to do that every day. 

I need to have the flexibility to work remotely for at least a few days a week with no questions asked.

This allows me to spend time in quiet places where I don’t have to be as “on” and can focus on deep work. 

**Distributed Teams**

I find that having a global team is a great indicator that office norms within the company are such that you will not be trapped in the office from 9-5. When people are in different time zones it’s only fair to switch off who has night or early morning meetings, which consequently means your work day is unlikely to have your boss constantly checking in to make sure you are in your seat from 9-5. 

Even if the team is not globally distributed, not having everyone be able to co-locate for a meeting means the startup is going to have meetings on Zoom or some other web conferencing platform. 

This, in my opinion, is the greatest gift to an introvert and completely levels the playing field for introverts to participate more in meetings. 

Our defaults are often to listen, reflect, and share our opinions. Because of this, we often have a harder time sharing our opinions because we cannot get a word in. 

During face-to-face conversations in groups, there is rarely a pause for introverts to reflect on what's been said because someone else has jumped in with their response the second another person has finished their sentence. Because we don’t have the time to reflect, we rarely share despite having a lot to contribute to the conversation.

When you are on a Zoom, there is a slight delay (whether it’s real or just perceived) where people wait to ensure the other person is done speaking. This small moment provides introverts the opportunity to reflect before sharing their opinion since everyone is taking a pause. It is now just as likely for the introvert to speak as an extrovert I've found. 

**Culture of Reflection**

This is a big indicator not only that I’ll fit in for the organization, but also that the organization will be willing to change when faced with new information. 

The ability and willingness to pivot signals to me that they are more likely to reach profitability. It signals that they have a culture of testing and evaluating what went right and what went wrong during a project, and that they’ll apply those learnings to make products or services more effective. 

How I evaluate if the startup's culture is a culture of introspection is by the questions asked of me during the hiring process. Asking questions like “Tell me about a time when you were able to change or pivot a project when receiving new information or expectation? ” is a good indicator that they want you to use the new information you’ve learned to update your plan. 

The best thing I’ve seen to signal this was at my current company, DevRev. Everyone has to complete what they call You.io. It’s a 15 question survey that asks you to reflect on your past experiences as well as prompts. Nothing has signaled more to me that a startup cared about reflection than this, and fortunately it came true. 

**Good luck out there fellow introverts! I hope you find your best fit startup too!**


Choosing a startup as an introvert

**Synopsis:**
Learn how integrations became the glue that binds the SaaS world and their importance to any SaaS startup.

If you look at the offering of almost any SaaS company today, you will inevitably find a list of third-party services with which they integrate. This holds true regardless of industry, whether it is a financial services company like Stripe, communication household names like Zoom and Slack, or a developer focused player like GitHub. The trend is not limited to large established companies – smaller startups also tout their integrations as selling points. [Zluri](https://www.zluri.com/integrations/) (2020), [Phyllo](https://www.getphyllo.com/coverage) (2021), and [eqtble](https://www.eqtble.com/integrations) (2021) all prominently feature integrations from their homepage. 

Integrations are also called “apps”, “zaps”, “connections”, “sources”, “add-ons”, and “plug-ins''. Regardless of their name, they all do more or less the same thing which is integrating a SaaS company’s offering with another service.

## What is an integration?
In its simplest form, an integration connects two different services and allows them to interact and share data. Some concrete examples include the Zoom add-on for Google Workspace that allows you to add a Zoom meeting to a calendar event or, my personal favorite, the [Giphy integration for Slack](https://slack.com/apps/A0F827J2C-giphy) that lets you respond to messages with topical GIFs.

## Why are integrations so vital to SaaS?
Take a second and think about all the services you regularly interact with on a daily basis. I imagine the list goes something like this: Email (probably gmail), a messaging tool (Slack), a video conferencing tool (Zoom, Teams or Google meet), a work-tracking tool and some sort of CRM. If you are in the software world, I would also add in a hosted VCS (GitHub, GitLab, BitBucket) along with CI/CD tools. These are a minimum set of services; there would be dozens of other less commonly used ones. To put a concrete number to this, a [survey](https://productiv.com/resources/the-state-of-saas-sprawl/) by [Productiv](https://productiv.com/) found that a typical department within a company uses 40-60 tools. Departments like Security, Engineering and IT use even more. 

These various packages cost money, but there is also a cost to productivity. Contrary to popular belief, our brains do not multitask but rather context switch. This requires disengaging your attention from one service and bringing it to another. Then the process takes place again going back to the first service.

Data duplication often leads to a further productivity hit as you copy/paste from one service to another. Wouldn’t it be better if machines could coordinate between the different services for you? This is where integrations come in.

Integrations enhance the experience of working with multiple services, reducing context switching, automating manual steps, aggregating data, and allowing you to utilize specialized services to enhance the core services of your everyday life. And this benefits more than just the services end-users. SaaS companies can leverage the power of integrations to quickly add missing functionality via a complimentary service. They can also embed the service itself into an already existing ecosystem. 

## How are integrations built?
Software products, even before SaaS, used extensions and plug-ins to extend core software functionality. Some pre-SaaS examples include extending Emacs via Lisp or creating a plugin in Java for the Eclipse IDE. But knowing how to extend Emacs via Lisp did not help at all if you wanted to extend Eclipse via a plugin.

In contrast to the extension capabilities of old, the (REST) API is the SaaS de-facto extensibility standard. And APIs are no longer just meant for extensibility either – there are entire services that are API-first. Their APIs are the service. This makes knowledge of how to work with APIs wide-spread and applicable to nearly all SaaS applications. 

So far we have talked about extensibility of SaaS services and not integrations but an integration is nothing more than a specialized extension for two services. An integration is typically built by extending (using the API of) service A and extending (using the API of) service B to allow them to interact and share data. If we are continuing our glue analogy, the APIs of service A and B are where we would put the glue on to bind them.

Rest APIs are not the only means of integrating SaaS products, entire companies dedicate themselves to integrating SaaS products in various ways. Some of these, which we will talk about later, even allow you to “integrate” various SaaS products yourself in easy-to-use flow-builder UIs, but it should be noted that for those services to offer those DIY integrations, they themselves have almost certainly extended the API for you and are merely providing a pretty (and useful) layer on top of it. 

There is a little more to the story of building integrations such as the proliferation of SDKs,  the various authorization mechanisms, push vs pull, and event or batching, but APIs are at the core of it.

### Marketplaces and distributing integrations
Since an integration connects two services, it is often built by one of the services or in partnership with both. One common strategy to leverage others to build integrations for you is to offer a marketplace. A marketplace formalizes the process of creating and distributing integrations. This lowers the barrier for other services to integrate with your service. Not every SaaS company can build a marketplace but virtually any SaaS company should be capable of building an integration for an existing marketplace. Take the example of Datadog which has a [very well defined process](https://docs.datadoghq.com/developers/) of how others can build integrations for the [Datadog Marketplace](https://docs.datadoghq.com/integrations/). As a result, they have over 500 integrations – about half built by others for them.

## The business of integrations
Integrating various services is so vital to the SaaS ecosystem that entire companies are dedicated to integrating these services in various ways, they include:

### iPaaS
iPaaS or **integration Platform as a Service** is a platform that allows for the integration of various services, whether cloud or on-premises. These tend to be geared towards larger or more complex use cases and are often very powerful and configurable but require some expertise to set up and run. Examples include:

- [Workato](https://www.workato.com/) ([~$5.7 billion valuation](https://techcrunch.com/2021/11/10/workato-storms-to-a-5-7b-valuation-after-raising-200m-for-its-enterprise-automation-platform/) in 2021)
- [SAP Integration Suite](https://www.sap.com/products/integration-suite.html)

### iSaaS
iSaaS or **integration Software as a Service** is quite similar to iPaaS but may not be as configurable. The tradeoff is that these services are typically easier to use and set up, making them preferable for smaller to medium sized companies. Examples include:

- [Zapier](https://zapier.com/) ([~$5 billion valuation](https://www.forbes.com/sites/alexkonrad/2021/03/08/zapier-bootstraps-to-5-billion-valuation/?utm_source=ForbesMainFacebook&utm_medium=social&utm_campaign=socialflowForbesMainFB&sh=786f6da21c8e) in 2021)
- [IFTT](https://ifttt.com/)
- [Pipedream](https://pipedream.com/)

### Workflow Managers
Workflow managers are more purpose oriented, most iSaaS or iPaaS solutions may be able to accomplish what workflow managers do but those solutions would require more configuration and potential complexity. Examples include:

- [Unito](https://unito.io/)
- [Exalate](https://exalate.com/)

### Data Integration Platforms
Data integration platforms are another related category but with an emphasis on collecting and aggregating data from the various services instead of coordinating their interactions. This can include normalizing the data to make it easier to query or transforming it to deliver it to a different specific destination. 

- [Fivetran](https://www.fivetran.com/)
- [Airbyte](https://airbyte.com/)
- [Twilio Segment](https://segment.com/) - A specialized Data Integration platform for customer data

### Built-in Integrations
All the categories above allow users to build their own workflows or have an opinion on how two or more different services should interact with each other. The integrations in this section are built (or commissioned) specifically by a service to interact with other services. This comes with a built-in opinion of how the native and external services should interact. For the end-user, it eliminates the need to have a third service or platform just to manage integrations. The negative for the service providers is that they have to plan, build and maintain a potentially large set of integrations (one per external service). For this reason, built-in integrations tend to be limited.

### Integration categories are blurry
It should be noted that the categories above are somewhat blurry. A SaaS company may fall into more than one category. For example, a “Built-in” integration provided by a service may actually be built by leveraging an iSaaS or data integration platform. In fact, a common solution for new startups to leverage the power of integrations is to utilize existing integrations platforms. It’s much easier to plug into an existing ecosystem like Fivetran and Zapier than to build hundreds of custom integrations. 

## Integrating with DevRev
DevRev understands the value of a connected world. Not only are we connecting Dev to Rev, but we are also harnessing the power of integrations with the tooling you are already using to make it possible. It doesn't matter if you're talking with customers over Slack, email or a widget on your App. DevRev connects your customer (Rev) conversations, requests and usage with your product and builders (Dev). This allows you to avoid manual copying, context switching, and provides a richer set of data to make informed product-building decisions. Keep an eye out for our upcoming marketplace and flows and see how they can help you connect your Devs to your Revs.

Integrations: The glue of SaaS

In the last few months, I seem to have developed an obsession with watching YouTube videos.

I LOVE watching all kinds of inspirational videos and TED Talks whenever I can steal a few minutes. Some videos leave you feeling warm and inspired, and you feel like going to your desk and banging out a seminal creative piece yourself.

And then you sit in front of your screen blankly, and nothing comes to mind.

All the beautiful narratives and examples of the most prominent brands and trends by leaders and influencers suddenly seem to disappear into thin air.

Meanwhile, you still have stuff to do. Create documents, research, write code, or other things you do for your job, maybe even make YouTube videos.

This is reality. A reality, where all that grand-sounding fables and advice do not seem to matter anymore.

**And this is why it is so special when you are doing something inherently uninspirational — like researching which business software to choose, and you suddenly run into elegant interaction design in a trial experience.** This encounter may ever so subtly or significantly influence your purchase decision.

This happened to me recently.

We at DevRev are in the process of building a zero-touch experience based on [Product-Led Growth](https://devrev.ai/articles/all/product-led-growth) (PLG) principles. As I was going through the trial experience of HubSpot and a few other marketing tech stack providers, I imagined it would be good to capture and share some examples of truly elegant PLG principles currently in practice by some companies. What follows below is my interpretation and opinion based on those trial experiences:

**1. All you need is an email address**

![image](https://cdn.sanity.io/images/umrbtih2/production/badc3f4fe093a85076c7eb8ab6660bf98ed07ef7-1400x391.jpg?w=1400)

Three examples of trial pages requiring only an email address to start the experience

Ideally, your users should be able to get started with your product with nothing more than an email address. This seemingly simple principle usually has a remarkable impact on the overall experience. For example, in one of my previous jobs where we created a PLG -based experience, our conversion rate went up to 36% on the sign-up page when we switched to only asking for an email address to get started.

Simply requiring an email address to start a trial doesn’t mean that you will not have other valuable information about your prospective customer. There are some excellent examples like Zendesk and HubSpot (see screenshots below) that allow you to get started with an email address, then they progressively ask for additional information.

In addition, if you are building a PLG-driven experience, consider giving users the extra option to get started with other services they may already be using, like Google or LinkedIn.

**2. Free for life**

When it comes to offering experiences to prospective customers before purchase, you essentially have two broad categories to choose from:Offer the product as a trial or follow a freemium strategy.

I should mention that some companies follow a hybrid approach which entails providing full access to all functionalities for a limited period and then downgrading users to a free version of the product at the end of the trial.

In the trial category, you typically have a period during which either the entire product or some of the functionalities are free. Then, at the end of the trial, the user decides to either go to a paid version or the access goes away. In some cases, you get to continue to use a minimal set of functionalities.

In the freemium category, you have some functionality that is free for life. This is usually good for a vendor when your primary goal is to build a community, but it singularly fails if your product requires significant hand-holding or training to use.

HubSpot follows a freemium strategy, and this works well because the product is dead simple to use. The interaction design subtly guides you towards more usage and eventually towards paid features, bringing me to my next point.

**3. Progressive discoverability**

![image](https://cdn.sanity.io/images/umrbtih2/production/257bdd88a91217447b78259422b445db3d9daa31-1400x587.jpg?w=1400)

Example of how Hubspot clearly marks premium features in an elegant design

As soon as you sign up with HubSpot, helpful guides nudge you towards completing some specific tasks. When you gradually complete these tasks, you often run into clearly marked “premium” features.

Now, I am willing to bet that the interaction design was probably based on some data that showed how completing specific tasks leads users to “discover” some premium features and thus a higher conversion rate.

This is also a beautiful example of Product Qualified Leads (PQLs), but more of that in a future blog.

**4. Do This Then That (DOTT)**

![image](https://cdn.sanity.io/images/umrbtih2/production/981ebcbd00443ea7c1996f06a33fe683b9aa227f-1400x976.png?w=1400)

Example of in-app nudges to drive adoption

Product-led experience is typically grounded in the goal of trying to get users to adopt your product as quickly as possible without having them fall off the features fatigue cliff. This phenomenon is quite likely in a zero-touch experience.

This is why easy and engaging onboarding is critical to any trial or freemium experience that helps users discover features by guiding them to complete tasks. Put another way; you want the learnability of the product to be as intuitive and engaging as possible from the get-go.

Tools like WalkMe are excellent for implementing adoption-friendly tasks, and this is another area where the HubSpot trial experience shines. When you first sign in, not only do the guided tours help you discover new features through tasks, there are also helpful visual cues to show how far you are from completing those tasks. The more tasks you complete, the more likely you will use the product and the more likely you are to end up choosing a paid version of the product.

**5. Three-click thinking**

![image](https://cdn.sanity.io/images/umrbtih2/production/c453c88026f7ae8f99131f961945c852f7821fdf-1400x712.png?w=1400)

Couple of examples of three-click thinking in trial experiences

One of my favorite design principles for building an elegant PLG experience is three-click thinking. There is something about the magic of threes, especially around completing tasks, that makes things a lot easier.

I see this more commonly across trial experiences these days than I remember coming across a few years ago. When you are building your trial or freemium onboarding experience, think hard about what features are more compelling to demonstrate in the experience. If you can boil it down to three steps, you will gain bonus points from your users, and you will be rewarded with more engagement.

**6. The invisible hand of support**

There will be segments of your trial users who are either not an avid fan of the guided tours or who are already familiar with your product. They might want to leap over the guardrails and go straight into advanced features. When this happens, and those users run into any issues, you will want to avoid ‘silent failures.’

A silent failure occurs when a user encounters an error or doesn’t understand the intended use of a feature. Instead of getting the right solution for their issue or question, they instead grow frustrated and stop using the product. As a PLG product manager or creator, you are often left scratching your head trying to figure out why users are not adopting your product if silent failures happen a lot. A common symptom of this issue is a high sign-up rate but then a shallow conversion from free to paid users.

To prevent a silent failure, it is critical to have two things as part of your PLG experience: telemetry data about usage and a chatbot backed up preferably by intelligent automation and humans when needed.

Using the HubSpot example again, if you have questions or want to raise your hand to get support, right there on all screens, you have a friendly chatbot that you can invoke to either search for a solution or to have someone call you to hold a human-to-human conversation. You also have the choice of searching answers in the community forum or knowledge base article portal. What’s slick is that the chatbot knows which screen you are on and starts with some helpful links for the screen that you are already on.

**7. Reduce the cognitive load**

When you are in the business of making software, the users will often inevitably run into inherently complex concepts. To simplify matters, you can rely on making some assumptions on behalf of the users and then allowing them to override those decisions if and when they want.

A good example is when you are looking to import a CSV file into HubSpot. You have to make some choices, like mapping fields, when you upload a file into HubSpot. However, if you decide not to make those choices, the guided tour takes over and tells you that it has made some decisions on your behalf. This still shows the end state of the task, and if you want to override the decision, you can still do so with one click of a button.

**8. The user is always in control**

When there are choices to make, the users may indeed face a cognitive overload. This doesn’t mean, though, that you should remove all choices to make the experiences simpler. Instead, follow the #6 tenet above to reduce the cognitive load.

However, when you provide choices, it is essential to note that you are sending out the message that you care about all the users, and different users may choose differently. There is more than one way to complete the task, which could be an out-of-the-box experience for some, but provide more guided support for others.

**9. Design for the masses, not the power users**

In my experience, when you are doing research or reaching out to your end customers to get feedback, the most opinionated users with the loudest voices are typically the power users. IA quick caveat: This is not a sweeping generalization, rather an observation based on my own experience.

Over the years, as a product manager, I often went down the path of listening to the most vocal users and not paying attention to whether that was an edge case for a power user or something of benefit to most users. In hindsight, I feel all trial user experiences should be built for most basic users, **not** the power users. However, you can provide a gradation of experience in a trial where you can identify and then separate your power users by offering them the choice of self-selecting a deep-dive experience. We did this successfully at one of my previous jobs, where power users could choose some deep-dive topics and self-select into an experience inherently built with non-trivial use cases.

**10. Remember and personalize**

![image](https://cdn.sanity.io/images/umrbtih2/production/54f7e1fa8cfe6e614ebdd0a305c63c4a54473d70-1400x835.png?w=1400)
Delighting customers with simple and elegant design

There is nothing more satisfying than jumping into an experience right where you left off the last time. The continuation and “memory” of the system of what you did and what you should do next is a compelling user experience, in my opinion.

There are some outstanding examples of this within HubSpot. When you log back in, the “home” screen shows you where you left off and how far away you are from completing the overall task. This kind of experience makes you feel that the experience is tailored to you personally and demonstrates the company’s empathy for its users.

A lot of work goes into thinking through and building a PLG experience, and I hope describing 10 principles proves helpful for those embarking on a PLG journey.

Please do feel free to reach out to me directly if you have feedback or comments on this article because no one likes a ‘silent failure.’

10 Product-Led growth PLG principles in action

My daughter was afraid to go to school. It was the first day of middle school, and suddenly from being the oldest in elementary school, she was the youngest, walking alongside the hallways of students 6 years older. As we drove to school, I said to her, “make a friend, it will be easier”. I could almost hear her inside voice, “hrmph, easy for you to say”. But who am I kidding – it was intimidating for me then, and it is even now everytime I enter a room full of people.

Friends are a huge part of what makes school more fun, and frankly everything more fun. Life is just better with friends. And if there is one thing at the core of the tech industry, it’s connections – with people, with systems, and connecting to what matters. 

## Better with friends
At DevRev, our friends are many – they are our coworkers, our customers, our community, our investors, as well as systems and 3rd party software. We befriended many systems from day one, such as GitHub, Jira and Slack. Sometimes, we may be the first to reach out and say, “Can we be friends?”.

Today, we announce the humble beginnings of the DevRev Marketplace. It’s where we hope to connect with many new systems, enrich our existing relationships, and just supercharge our user workflows. We have a common purpose, to make life better for everyone, and especially for our users.

DevRev Marketplace is where our users explore and get snap-ins, extensions of your DevRev experience. They are powerful ways to extend the functionality of DevRev by connecting with external systems, automating your workflows, or simply personalizing your experience. For example, the Slack snap-in scales your customer support in Slack by enabling a real time bi-directional sync so Slack conversations are always in sync with DevRev tickets, and customers are never in the dark. Our GitHub snap-in extends DevRev to work in close conjunction with your GitHub workspace, so status of your developer issues is always code driven and real time.

## Meaningful connections
A meaningful connection is like a marriage meant to be, or like best friends forever. It should feel easy. It’s easy because communication is seamless and you are a snug fit. When DevRev connects users with new ways to extend their experience, sometimes with another system, we think about three core principles.

**Organic discovery**

Discovery must be organic – it’s all about the context: the right place at the right time. The key is to become discoverable everywhere, whether on Google, in your own communities or others, and even inside of the app. Be discovered, when they are looking. 

**Easy to use**

Once discovered, unlocking value should be seamless. Give users the autonomy to unlock value, without having to go to their admin for permissions, or their managers for budget. It’s easy to install, configure and get started on their own, in a matter of minutes.

**Creates value**

Value creation is crucial, for our users and also for our community. We aim to extend our users’ experience, by connecting them with other systems they use, sharing information effortlessly, and offering users new ways to work, or simply eliminate work with automations. Everything we build, we hope our community can extend with additional powerful ways to create value.

## Enrich your Dev and Rev connections
DevRev Marketplace will help create a new kind of CRM, Developer CRM. We believe a CRM cannot live in a silo in the front office, and rather customer, aka Rev data must flow across to the Dev teams and back, including cross functional teams such as developers, product managers, support engineers and more. An ecosystem is built on relationships, and ours includes relationships with APIs, SDKs, webhooks and low-touch ways for community members to create value. 

At the DevRev Marketplace, akin to an App Store, you can discover snap-ins that add new functionality, bring a dash of delight to your day, and enhance your DevRev experience. As a community member, you may build and distribute your snap-in in the future. 

We begin this journey with 10+ snap-ins that will add new functionality to DevRev and extend our users’ experience. Go to devrev.ai/marketplace to learn more. 

**GitHub**

DevRev’s [GitHub snap-in](http://devrev.ai/marketplace/github) helps eliminate work about work — and especially the status meeting. We enable more developer deep work time, with machines doing more so developers spend time on what matters most. GitHub snap-in create value to developers across several fronts:
* Automatic status updates based on GitHub events, such as branches, commits, PRs
* Autocreate and manage issues so developers don’t need to, so your work is always account
* Schedule PR reminders such that PRs are never stale, and teammates know the status of issues
* Create tasks for PRs such that every PR review is accounted for and so you can track them
* Track status of your builds, and keep [GitHub Actions](http://devrev.ai/marketplace/github-actions) in sync with your DevRev issue

There’s a lot to love about GitHub! DevRev extends the awesome GitHub experience, and empowers developers to build great software, while making more time for what matters, their customer and product.

**Slack**

Slack is a great way to stay connected. It’s also where several organizations engage with their customers. It may sometimes be an organizational challenge though, where discovery and traceability can be a nightmare, “Where was that Slack customer thread?”  

Our [Slack snap-in](http://devrev.ai/marketplace/slack) enables you to have more efficient customer feedback loops. They help you converge customer conversations, support tickets and developer issues:
* Create DevRev support tickets that are in bi-directional sync with Slack customer conversations
* Get DevRev ticket notifications on Slack, tracking the lifecycle of the ticket and related developer issues
* Provide visibility to customers on all of their requests so they are never in the dark
* View DevRev ticket status without ever leaving Slack
* Run commands to perform quick DevRev actions

If you’ve been running customer support on Slack, and are keen on improving your customer feedback loops, then our Slack integrations will help you be more efficient, bringing structure, traceability and transparency.

**Jira**

Bring your developer issues and coexist delightfully with Jira, and transition to DevRev at your own pace. The Jira snap-in enables customer support teams to coexist with Jira with bulk import, 1-way and bi-directional sync, so updates in Jira reflect in DevRev and vice versa. The sync works on new issues as well as updates to existing issues, and is feature rich with bidirectional sync of objects, fields, attachments, links, comments, as well as custom attributes.

Our [Jira snap-in](http://devrev.ai/marketplace/jira) enables you to tightly integrate with developer issues in Jira, so you can run truly converged customer support in DevRev.

**Convergence**

DevRev’s converged system of record tightly couples the core objects of the platform – work, identity and parts. Our [Support convergence](https://devrev.ai/marketplace/devrev-converge) snap-in ensures that customer conversations, support tickets and developer issues are converged, with information flowing seamlessly across developers, product managers and support engineers. Here are powerful ways you can drive convergence between your customer, the Rev and your team, the Devs
* Automatic ticket updates in customer conversations
* Automatic issue and ticket updates 
* Automatic updates between parent and child issues

Enable this [snap-in](https://devrev.ai/marketplace/devrev-converge) so you never have to context switch across disconnected customer support and development systems. Let machines eliminate menial tasks, so you never have to ask questions such as “where’s my feature request?”

## Build with us!

Come check out several other snap-ins on the DevRev Marketplace. If you have feedback or requests for new snap-ins, please reach out to marketplace@devrev.ai. We look forward to building and learning with you, and also soon opening up the DevRev Marketplace for our community to build and co-create value.


DevRev marketplace: Connect with what matters

SiliconANGLE

Led by Nutanix’s founding CEO, new startup DevRev launches with $50M in funding 

PALO ALTO, CA--October 18, 2021--DevRev, a category-defining software company focused on connecting developers with their customers, today shared that the company will be announcing itself as Customer Zero and unveil the first look into its platform at its first-ever live event on October 20, 2021. In addition, today DevRev also introduced several resources aimed at developers, including a Hackathon with prize money worth $30,000 and an exclusive private community called DevRev Circle for developer entrepreneurs.  

**DevRev Day and Product Preview**

On October 20th, DevRev Day henceforth, the company is seeding an environment to connect  with its newfound community -- to learn from and with them. During the event, attendees will hear from co-founders, Dheeraj Pandey and Manoj Agarwal, and have access to sessions with Vinod Khosla, founder of Khosla Ventures, and Abhay Parasnis, Adobe CTO. 

Additionally, DevRev will tell its own story of evolution on why the company has become its own Customer Zero during this extremely critical discovery phase of product-market fit, and how DevRev will:
- Use their platform to build software, making remote engineering delightful and social
- Gather real-time feedback and stay close to early adopters
- Migrate off legacy databases and workflows to manage features, issues, and tickets. DevRev will also reveal why this decade will all be about in-app experiences.  

“During these formative days, we want to take a moment to acknowledge how far we’ve come, and celebrate DevRev Day with our community of friends and well-wishers,” said Dheeraj Pandey, CEO and co-founder, DevRev. “We are aspiring to change how digital businesses are built and operated. That will require an immense learning mindset with the community.”
Pandey will share an exclusive, first-time-preview of what DevRev’s platform will look like, and share with audiences more about the vision for DevCRM, the dev-centric approach to building customer-conscious products and services. Given its Product-Led Growth (PLG) roots, the company expects to interact frequently with its community of alpha and beta users in the coming months, as it unveils a next-generation CRM suite of services to power PLG focused organizations.

**Circle Membership Program**

DevRev’s Circle Program is one of DevRev’s largest investments to date, and provides members access to:
A private community of developer entrepreneurs, including industry experts from VC firms and former enterprise tech employees
DevRev’s Discord server, hosting monthly insider sessions with startup founders and tech leaders -- such as Vinod Khosla, Navin Chaddha, and other notable developer entrepreneurs --  discussing how to build, support, and grow software businesses in today's product-led era
Training and educational content related to ML/AI, design and data engineering
Scholarships for Udacity courses
A chance to influence DevRev’s company roadmap, early access to the product prior to general availability, and the ability to enter into the Hackathon. 

**Hackathon**

Developer entrepreneurs will have the opportunity to enter into a Hackathon, kicking off November 1st, where they will build out a prototype and present to potential investors. The winner’s prototype will be included as an application of DevRev’s open source ecosystem and will receive $30,000 as prize money, sponsored by Mayfield Fund. This is a testament to DevRev’s commitment to creating a product that caters to developers needs through sourcing what is most important to them and creating an open dialogue between DevRev and its customers.

“As we start to bring our .ai vision to life, we want machines to take the mundane chores off the developer’s plate,” said Manoj Agarwal, co-founder and President, DevRev. “Like Netflix a decade ago, this hackathon is about co-creating AI value with external developers, many of whom will not be our employees, but will be valuable teachers to learn from nonetheless.” 
Barely a year since inception, DevRev is approaching 100 employees and continues to grow, as it invests in its product and builds its PLG muscle around growth and support engineering. For more information about these programs visit devrev.ai; for additional details on DevRev Day or to view the conference, see here.

**About DevRev**

DevRev is a business software company that brings developers and customers together in the era of product-led growth. The company is building an API-first dev-centric CRM that leverages data, design, and machine intelligence to empower developers to build, support, and grow their business. In times of anemic NPS and high customer churn, DevRev strives to create the world's most customer-centric companies led by happy developers. Grok and grep more on DevRev via the web, Twitter and LinkedIn.

DevRev announces themselves as customer zero and shares first-look at product

Building a company from ground-up is an excellent learning experience. You soon realize, for instance, that hiring a team member means you’re also embracing their families. A family coalesces into a strong support system that enables the person to give their best to the building of a company.

Parents, spouses, children, siblings, partners, significant others — they know and understand us. Our familial bonds form an *invisible* support system whose role in our productivity can’t be understated.

In the last few years, we’ve realized that the concept of *invisible* support systems also applies to machines. How so? Well, it takes some explaining, but it’s pretty much like this:

When I write an email these days, a mail app finishes my sentences for me. Somewhere, in some far-off server farm, a database has untold volumes of written sentences — including my previous emails. An application built with artificial intelligence and machine learning (AI/ML) sifts these emails for patterns. Somehow, the app knows how I’d like to write a sentence when I’m only halfway through.

And then the *invisible* hand writes the rest. Remarkably, it does it so well that I almost feel like sending somebody a thank you note.

**That’s serendipity.**
It doesn’t happen by accident. Somebody designed this moment. They used [empathy](https://www.linkedin.com/pulse/closing-empathy-gap-bedrock-building-awesome-product-manoj-agarwal/), [discoverability](https://www.linkedin.com/pulse/first-discoverability-serendipity-manoj-agarwal/) and learning automation to create moments of happy magic when products do exactly what we want. We don’t have to ask. It just knows. And it delivers.

![image](https://cdn.sanity.io/images/umrbtih2/production/0f55d59958119647e03003fe1c9ed3787f714d00-1400x652.png?w=1400)

It’s happening in more apps every day. Shopping sites show custom lists of complementary products. News feeds are personalized to reflect the stories we click on most often.

They’re designed for utilitarian purposes but they make room for happy magic. Serendipity makes a connection deep in the user’s brain. It triggers positive emotions like gratitude and amazement.

How does this design happen?

It starts with empathy — truly understanding the user’s situation at every point in the user interface. Real-time data reveals user intent. AI/ML engines analyze the data, using statistical analysis to predict the user’s expectations and desires at just the right time.

**Three pillars of designing for serendipity**
How should we design for serendipity? Before starting, we should spend an inordinate amount of time seeking and grasping the most powerful word in user delight: context. The entire experience is then about creating that happy magic around the context of the user.

*“Seek first to understand, then to be understood” –Stephen R Covey*

These three pillars are necessary and sufficient to truly understand context:
<ul>
<li>Data: You must meticulously collect data from all possible sources within the context and carefully apply the right filter to seek the truth. For this, you must also have the computing muscle, network bandwidth, storage efficiency and programming talent to deliver on the promises of your user experience. It all has to be optimized for performance, efficiency and economy.
<li>Design: The user experience must make room for happy magic. It could be a widget with related content, that has the full context of the problem and can ask “would you like to do this next” or a list of the three most likely activities the user expects to do next. Everything has to be strategically placed where the user is most likely to need it — at the precise moment.
<li>Machine Intelligence: Machine learning algorithms must be thoughtfully engineered and painstakingly designed. The recommendations must be carefully crafted with context in mind for the human and the machine to be two sides of the same intelligence coin.
</ul>

![image](https://cdn.sanity.io/images/umrbtih2/production/211c19080cf9a0537845f6ae804b7e885c95780b-1400x647.png?w=1400)

Learning algorithms will make their own decisions, getting smarter (with human feedback) over time. Learning automation is always about statistical likelihoods, not certainties. You don’t want to leave crucial components of your user experience design to chance. You want it to work like you designed it — every time.

**Everybody can design for serendipity**
It’s tempting to think that sophisticated user experiences designed by the likes of Apple and Tesla are out of reach of everyday startups. Well, that’s just wrong.

Open-source development frameworks give every startup the tools to design their own happy magic. We’re using them in our startup. We’d be crazy not to.

The same is true of data science and learning algorithms. These and many more high end computing capabilities and intuitive low code/no-code development tools are bringing more power and development speed to the people every day.

Of course, bringing AI/ML into the user experience raises a lot of questions. How much user data should we collect? How do we keep it secure? How do we monitor the progress of learning algorithms to avoid crossing boundaries of privacy?

Answering these questions requires a thoughtful analysis of what users will expect and what they will not want. Again, this goes back to my point about empathy.

![image](https://cdn.sanity.io/images/umrbtih2/production/bdf5f1cb73b67114bfe4aa572f375dc86d76b4a3-1000x311.gif?w=1000)

We always have to design for the entirety of the user experience. We can’t introduce things our users never expected.

So, the challenges are many. As are the risks. But the rewards of combining design and empathy to produce serendipity are too great to pass up.

**Let human connections be our guide**
There’s nothing like that point when you’re in a conversation with a family member or a close friend who knows you so well that they finish your sentence for you. Your eyes lock. You smile and laugh in unison.

That’s the moment my email app aspires to when it finishes my sentences. Of course, it’s just a machine. Our devices can’t replicate the happy magic we get from human interactions.

![image](https://cdn.sanity.io/images/umrbtih2/production/445680552ca21b97791a4c36f6835d38f5f6e2d3-1400x906.png?w=1400)

But we can design for serendipity, building machines inspired by the *invisible support systems* our families provide.

In closing, I’m dedicating this article to the families of our team building our new startup. Their strong support — not always seen, but always felt — makes us able to bring our best to work every day!

Designing for moments of serendipity

When introducing data tracking into your product there are about 2 and a half approaches.

1. List everything that happens/is clicked on that you can think of
2. List questions you’d like to answer about your product then determine what data is needed
2.5. List basic things you’d reasonably like to track then add elements as you find questions the existing data doesn’t cover


My suggestion is to use the second approach however it’s important to discuss the others to understand the value and when a different approach might be appropriate.

**Note**: For anyone reading this that is brand new to data concepts, the easiest way to think of it is like an index card. The front gives you what the event or object is, and the back of the index card has specifics about that card. For example, you may have an event for every time someone logs in. The front of your index card would say something like user_login. The back of your index card would have information like user_id, timestamp, and geo_location.

## Data ≠ Information ≠ Insight

There is an important distinction between data, information, and insight.

**Data** can be either quantitative (numbers) or qualitative (not numbers). It is raw input that is stored for future use. By itself is essentially meaningless but without it information and insight wouldn’t be possible.

From data, you can come up with descriptive analytics which tell you what has happened in the past such as DAU, conversion rate, or how many times unique users clicked a particular button. You can also use it to come up with predictive analytics which attempt to tell you what will happen such as predicted DAU next week or predicted conversion rate during a sale. This is **information**. You have taken raw data and now can form short sentences with it such as “on Monday we had 50K unique users log in.”

However, descriptive and predictive analytics are useless unless they can be turned into actionable **insights**. This requires more research than a single query. Insight is information with context. Good insight is information with context that leads to action. An insight might be “On Monday we had 50K unique users log in however only 15% of those completed a target action, of the remaining 85%, 75% of them closed the window after less than 2 minutes. We took a representative sample of those users and conducted 10 user interviews, 8 out of 10 indicated that they could not find the button needed to complete the target action because it was not visible without scrolling to the bottom of the page. Changing the layout to accommodate smaller screens or changing the location of the button should positively increase the number of users that complete the target action and reduce drop-off.” Of course, if you don’t have the right data or don’t pull the right information from that data, you won’t be able to reach the end goal of generating these insights.

## List Everything Approach

Usually the knee-jerk reaction is to start listing all of the events that you think are important to track. You may start with general groupings such as logging in, then break that into smaller actions but it is essentially an attempt at finding an exhaustive list of every event you may need.

The problem with this approach is you will inevitably miss something, and are likely collecting data you will never use.
This also treats data as though it were by itself useful however as discussed above, we know data is not useful without context.

## Question First Approach

This approach may take more time however it is time well spent. It requires knowledge of your product, an understanding of insight vs information, and some understanding of how data works (see index card analogy above).

Identify a list of questions you may have about how the end user interacts with your product.

1. For this step I encourage you to get input from everyone who might be interested from developers to marketing.
2. When creating this list, don’t worry about how you will answer these questions. There is always a way but focusing on the how first is often an innovation killer.
3. Set the list aside and come back to it a few times

From the list of questions start breaking it down into events and objects you’d need to query and the attributes each event/object would need. (You may only need to query events if end users don’t create things that are then stored within your platform)

1. Be as thorough as you can but the next step will help you cover any that you miss
2. Use this as an opportunity to break down the questions you have to understand intent and come up with questions you may have missed.

Come back to your list of questions and choose the most important ones (or all if you’re feeling ambitious). Write either an actual query or pseudo code for each question. If you don’t know how to do this, listing the event/object and fields you’d need will usually suffice.

1. This shows why each event/object you’ve listed in your data structure is needed
2. It also serves as a reference when you have the data and actually go to run these queries


Now go look at what data collection you already have (if any). Assess what you can get, and if there are any events that aren’t possible to collect, for example if they happen on a different platform, think of proxies you can use that will get you close.

1. The reason we come up with a dream data structure first is in the age of cloud based databases, it is more cost effective to store data that is easy to query even if there are redundancies than optimized data storage that requires very complicated queries. The time to write and debug these queries costs more than the extra storage.

Implement the final data structure!


This process may mean that you miss some events that you later want however you are guaranteed to have the data needed to answer the most important questions that currently need answers and minimizes collecting data you will not need.

This approach puts insight at the forefront so the true purpose is never lost.

## List then Questions Approach

This blends both approaches. You may be in a position where you aren’t ready to start in depth user analysis but want some surface level information. There are some basic things that are pretty universal such as tracking page visits for web based products and logins for both web and desktop products. This will at least answer some simple questions like “how many people come to the site” “how many of those log in” “how many purchases” “where are my users” and “what time of day are they using the product.”

From this foundation you can over time start adding as you encounter a question that can’t be answered by the data you already have. This is also the approach you’d continue with after using either of the above methods to add to your pursuit of insight.

Question first approach to data gathering and analysis

We are witnessing intense competition in the CRM industry. Customers are more aware of their options and want more features, better modularity, and cheaper costs. Salesforce has lost its market dominance as companies look for Salesforce alternatives.

Despite the competition, there is room for new players because of the demand. CRMs that cater to particular niches aregaining traction.

The global CRM market was estimated to be worth 53 billion USD in 2021 and is expected to rise to over 100 billion USD in this decade. 

According to this report, the market shows a growth rate of 13 % annually (CAGR).

The above report indicates the importance of CRMs to companies. 
Initially, People used CRMs in B2B companies. Now, some CRMs cater to B2C companies that don't just focus on sales.

A one-size fits all approach is no longer an option, and customers are looking for niche capabilities that cater to their business.

Today the world of CRM has a somewhat chaotic market distribution. 
The market leader, Salesforce, has a 23% share of the US market. Other legacy providers such as Oracle, Microsoft, Adobe, and SAP jointly hold 20%. 

That means new CRMs have 50% of the market share, and their piece of the pie is growing. 

With so many CRMs in the market, it is crucial to pick the right one based on your requirements. 

It's no longer necessary to spend exorbitantly on Salesforce. There are plenty of Salesforce alternatives that cater to specific tasks at affordable prices. 

## Trends in the CRM market

Before we get into the Salesforce alternatives, let's look at the current trends in the market. 

### AI

AI is getting integrated into all industries. With CRMs, AI can provide customers with accurate forecasts and lead generation reports. 
AIs can analyze data such as activity, sales, and emails and provide insights. It can analyze customer patterns and help improve customer retention.

AI automates monotonous and manual work. This allows sales teams to focus on important tasks and the business to streamline its operations. 

### Automation

Automation has become an essential element of CRMs. You can schedule emails and messages for a particular time or after a specific action. 

AI-enabled chatbots have helped many customer care operations, where the bot takes all the necessary information required from the customer. If needed, a human overlooks the situation and provides a solution. 

This reduces man-hours for a company, and companies can complete the task with fewer people.

### Modularity

A few years back, companies would use CRMs only after reaching a specific size and once business operations became complex. 

Nowadays, small businesses can afford CRMs because they are modular, readily available, and cost-effective. That’s why Salesforce alternatives have had so much success. 

Customers want pluggable CRMs. These CRMs can easily coexist with the technology stack companies use.

These CRMs are feature precise, i.e., you only pay for your use. A fully managed SaaS CRM is the key to the future of this industry.

### More than Customers

CRMs should be appropriately named xRMs (where x stands for anything), as they offer more than just relationship management. We have Salesforce alternatives that cater to a variety of niches.

Companies have been successful in managing customer relations with CRMs. Now, businesses are looking forward to this level of management with every interaction of the business.

Every entity a business interacts with comes under the lens of xRM. This includes vendors, marketers, contractors, etc. It's not limited to external relations; you can also manage internal ties between departments and employees.

### Connectivity and integration

CRMs of today are not a stand-alone service. They must be integrated with communications systems within a company—slack channels, Microsoft teams, etc.

This is why Salesforce added a new slack feature to keep up with the competition.

CRMs must be able to input data from all these streams. Data coming from IoT and Product details can help interactions with a customer if there is a complaint. It enables you to provide a quick solution in case of any system issue.

### Developer Focussed

CRMs, for a large part, have targeted B2B companies. But they have been ineffective in B2C companies. 

That's why DevRev created a DevCRM. This CRM caters to companies that build products around general users. 

Users can directly interact with developers and voice out concerns. Developers can use this feedback to fix user pain points. 

A DevCRM allows developers to be more involved in the company instead of being on the sidelines. 

## Top Salesforce Alternatives for Your Company

## 1️⃣ Hubspot

![image](https://cdn.sanity.io/images/umrbtih2/production/0e8acfa0d47859832d4f5cfa0056f5880a18a901-1440x721.jpg?w=1440)


Hubspot is a CRM that became successful using the freemium model. You can use most of the functionality for free, like Figma. Only if you want more features you'll have to pay and upgrade your plan. 
Hubspot is a CRM that helps companies with their growth on social media and other channels.

First off, this CRM offers email automation. You can send bulk emails with CTAs and links. The drag-and-drop editor lets you customize your email template. Hubspot provides detailed analytics and metrics to understand unsubscribed, bounce rate, and CTR. 

With Hubspot workflows, you can automate repetitive tasks. You can integrate workflows with Slack, Linkedin, Zoom, and more. That way, you can create workflows with all your favorite apps. 

You can notify your team members automatically when a new lead is generated.

Hubspot also helps you track your ads. You get all the information in a neat and organized manner. 

Hubspot also makes the lives of social media teams easier. You can create drafts and schedule posts for all your favorite social accounts. 
With list segmentation, you can differentiate all your different contacts based on your parameters. This helps you connect with your customers with a more personal touch.

## 2️⃣ Zoho: The Best CRM for Invoicing

![image](https://cdn.sanity.io/images/umrbtih2/production/2e4ca46b0902ee4c5c01b1c32efcc672dbad2ae0-1440x721.jpg?w=1440)

When you move from Salesforce to Zoho, you'll wonder why you were breaking the bank before. Zoho is a powerhouse that helps companies manage invoices, grow revenue, convert leads, and more. 

Zoho offers all the traditional CRM features such as lead management, sales and marketing automation, account management, etc. 

One of the reasons for Zoho's success is its open developer APIs. Companies and developers can use these APIs to suit their needs. You can use the rest APIs to integrate Zoho with a third-party application. 

The notification APIs get you notified when data changes in Zoho CRM.

Another reason why Zoho is remarkable is the customization. You don't have to use a bland layout like in Salesforce. Instead, you can make the Zoho CRM your own with the Canvas Design Studio. 

If you are a B2B company, Zoho is one of the best options for a CRM. 

## 3️⃣ DevRev: One of the Best Salesforce Alternatives for PLG

![image](https://cdn.sanity.io/images/umrbtih2/production/fd81dfc0238167930186c73c7aea49fb21906913-3840x2298.jpg?w=3840)

In the previous section, I talked about DevCRM and its importance. 
Only customer-centric companies survive in this day and age. A community of happy users and developers helps companies achieve product-market fit and exponential growth. 

I would be understating if I called DevRev an app. DevRev is an ideology that empowers companies to excel with product-led growth. 

DevRev helps developers and product managers understand what users want and need. Instead of building unnecessary features, companies can optimize their MVPs and build from there. 

Adding DevRev to your product is simple with the PLuG SDK. Users can give feedback with a simple chat box. This feedback reaches the developer directly.

This simple approach allows developers to have ownership over their features. They can make necessary changes and update features based on user pain points and requirements. 

## 4️⃣ Freshworks

![image](https://cdn.sanity.io/images/umrbtih2/production/08e790e6de0adc378d19577bb90706c8be73d505-1309x655.jpg?w=1309)

The Freshworks CRM offers tools for sales, marketing, HR, IT, and customer teams. They have different tools for different needs. 
They have Freshmarketer for marketing, Freshsales for sales, Freshdesk customer desk for managing revenue and customers, and Freshteam for HR work. 

You can try out these tools on a free trial with your company team. Freshdesk also offers two free tools — Freshpin and Freshstatus. These tools help in monitoring live websites and events. 

With Freshworks, you can manage your contracts, collaboration, pipelines, tasks, and quotes. You can also automate tasks with their AI tools.

Connecting with customers with the CRMs phone and email support is easy. That way, you never have to leave the CRM. 
It also gives you insights into your engagement. You can then use these insights to optimize your sales pitches for different contacts. 

## 5️⃣ Netsuite

![image](https://cdn.sanity.io/images/umrbtih2/production/85080f5ab1c2697c776973b0d001e7e0502b9cec-1440x721.png?w=1440)

Netsuite is another CRM that focuses on sales and customers. It provides all your supplier, partner, and customer information in one place. 

Just like the other B2B CRMs, it offers sales force automation, marketing automation, lead generation, and sales forecasts. With the Netsuite CRM, you easily access all your information across the entire customer lifecycle. 
The main reason to get his CRM is campaign management. It helps companies execute their marketing plans across different channels. 
It also offers great customization, reports, and analytics. 

You can use the workflow builder to automate processes and connect your orders with your inventory data, saving countless hours. 

## 6️⃣ SAP CRM

![image](https://cdn.sanity.io/images/umrbtih2/production/09feceaef428ecf5370ae1156e9dd02dd66c3c22-1440x721.png?w=1440)

The SAP CRM is part of the SAP Enterprise Resource Planning Business Suite. This CRM helps companies meet customer expectations.
Sap CRM offers different sub-modules to manage different tasks. 

Here's a list of some of the common sub-modules — Sales, marketing, analytics, service, and Hybris. 

Most of the sub-modules are self-explanatory. The Hybris sub-module helps companies manage all of their marketing and E-Commerce needs. 

SAP CRM mainly targets large corporations. Take SAP CRM analytics, for example. It helps big companies decide on future strategies by providing information about current product acceptance, retention rates, customer satisfaction, complaints, etc. 

## 7️⃣ Microsoft Dynamics 365 CRM

![image](https://cdn.sanity.io/images/umrbtih2/production/b66b0bf5e394335148b637c64722ac1d07b60c2c-1440x721.png?w=1440)

Dynamics 365 offers customizable solutions for all your business requirements. You can make use of multiple CRM tools in tandem to fit your requirements. 

Dynamics 365 focuses mostly on Sales. They help companies grow their business with an event-driven sales process. They do this by understanding high-quality leads and clients. With the help of pipelines, the entire process of contacting and selling becomes easy. 
The CRM lets customers connect with companies easily using multi-channel service options and AI service bots. That way, only if needed, agents will speak to customers. Otherwise, AI bots can solve most problems. 

The CRM also streamlines your entire customer service process. It helps your company improve by analyzing feedback, surveys, and discussion forums. 

It also makes onboarding new customer agents easy with in-app learning options. 

## 8️⃣ Infusionsoft

![image](https://cdn.sanity.io/images/umrbtih2/production/edaf06514804dc8e6c02248abd4eeee7f0c44fca-1440x721.png?w=1440)

Infusionsoft is one of the top CRMs that pops up when you search for Salesforce alternatives. 

Infusionsoft is a CRM that helps you with sales, marketing, E-Commerce, and content management. 

Their goal is to improve the length of customer lifecycle relationships. New users get personalized training to learn the CRM. It typically lasts between 4–12 weeks. 

The fact that it has an onboarding process indicates that it is difficult to learn and has a steep learning curve. 

It is also much more expensive than the competitors mentioned above. 

## 9️⃣ Zendesk Sell

![image](https://cdn.sanity.io/images/umrbtih2/production/7aa86ff0194f01df2667eb4891f312cfe7e4e603-1440x721.png?w=1440)

This CRM helps you manage all of your sales. If you want to enhance your customer experience and improve customer experience, you should choose this over Salesforce. It is also much cheaper. 

You can try out this CRM with a free trial. After that, the prices are still affordable. 

Zendesk Sell has features such as sales reporting, analytics, mobile CRM, email and text automation, sequencing, and tracking. 
It also helps you create targeted prospect lists like most CRMs. 
Companies that have used this CRM have commented that it has helped them make data-driven decisions and improve sales with a better customer experience.

## 🔟 ClickUp

![image](https://cdn.sanity.io/images/umrbtih2/production/5204495ae2fc62bb22fc3cc18b76b36c2f7817c2-1440x721.png?w=1440)

The ClickUp CRM is for people who like using apps like notion and Trello. This CRM helps you organize and improve your customer relationships with lists, Kanban boards, and tables. 

It helps you note down the company's goals and track progress. 
You can integrate ClickUp with Slack, Zapier, Github, and countless more apps. 

This CRM is great for companies that are more product and design oriented. 

You can make your ideas concrete and create the entire flow with whiteboards. 

## Why New-Age Companies Need a DevCRM 

A DevCRM is essential to motivate employees. Let's look at DevRev to understand this better. 

DevRev brings all of a company's tickets, issues, and tasks to one place. "Trails" helps developers understand the relationship between good features and customer impact. 

Developers will get an emotional connection with users. When they see the direct impact of their work in solving problems, they get motivated and stay with the company. 

Developers like to get straight to the point. With DevRev, pointless meetings are thrown out of the window.

This past decade, companies have been unsuccessful in retaining employees. They thought that employees wanted goodies and stock options. They were wrong. 

Developers want only one thing — impact. That's what DevRev gives developers. 

If you use DevRev, you get happy customers, leading to happy developers. Two birds with one stone. 

Top 10 Salesforce alternatives and competitors in 2022

“Will I be writing code for the product?” the first-ever candidate I was interviewing for our marketing team asked.

I was mildly bothered. “Why does it matter?” I thought. Then I realized that the concept of product merging with the marketing website is a relatively new concept for someone about to graduate college.

“You will be writing code for a Product-led Growth (PLG) experience,” I answered, only to quickly realize I had opened up the door to more questions rather than answering what was asked. The interviewer had become the interviewee!

At this point, just like my interviewee, you are probably asking yourself the same questions — “Wait a minute. Did you say a marketing team? Why does a marketing team make a developer its first new hire?”

I am glad you asked.

Picture this. You are part of a startup marketing team. I am willing to wager $50 that you have conversations with others in your company that often go like this.

-*We need a website with personalization.*

-*We need a CRM.*

-*We need <fill your technology or vendor of choice>.*

If this sounds familiar to you, then you probably already know that a few months later, usually, the conversations tend to take on a different tone:

-*We need to create free trials for our product, and the trial experience needs to talk to all our marketing tools so that we have attribution!*

-*Should we hire an agency, or should our engineering team work on integrating our marketing website with our product?*

Then, a few months further on, as more and more people join the marketing team, the cacophony of frustration around impediments to go faster starts reaching a shrill pitch.

If there is one thing that has proven itself as a stark reminder over the last 12 months, it is this: **Every company is now firmly a “code” company.** Business processes and customer experiences within a company are increasingly being driven by code, and some companies, one might argue, have already turned into code.
These code-driven companies have to maintain features and continuously fix bugs irrespective of whether they sell physical products or code-driven products and experiences. It is thus appropriate to think that marketing too, in many ways, has turned into code.

It used to be that marketing teams would create content, hold webinars and run campaigns to drive prospects to sign up. Now, it is about getting your products into the hands of your potential customers as quickly as possible, providing an elegant experience, and earning and retaining their business in a seamless zero-touch experience.

**Yes, this new way of operating it even has a name — Product-Led Growth aka PLG.**

When building these experiences, you need to think through your customer’s end-to-end journey. How does someone discover your product? What happens when they sign up? What authentication method do you plan to use for trials? What happens to customer data once someone signs up?

A picture similar to this one below starts to emerge:

![image](https://cdn.sanity.io/images/umrbtih2/production/f643401e2a02b3f3e46292f4845f3733648e3386-1400x879.png?w=1400)

An intersection of Marketing and Product

By now, you will have realized that a lot of what marketing does today has started to overlap somewhat with product experience. So now that we have established how marketing’s role is changing, let me ask you: Who do you need to build your customer journeys? Who do you need to think through data flows and integrations? Who do you need to write and maintain code?

A software engineer, of course. The sooner a marketing organization accepts this, the faster they will get the market to understand and to test a product-market fit.

Let me explain.

A software engineer will tell you straight up how to build a website that has a clear separation of code and content, how to rely on APIs instead of putting everything inside a monolithic system, and how to integrate with other systems, including the core product. In addition, a software engineer can also design for an experience that relies on real-time communications to bridge the gap between your prospects and your team.

In addition, here are some additional benefits you gain when you as a marketer invest in a developer and a growth engineering team early on in your PLG journey:


**Create a trial experience** — A well-regimented developer and a development team can help you build a compelling trial experience grounded in customer journeys and interaction design. Sometimes this is an extension of the product and, at other times, it may be an instantiation of the product for a shorter term, for example, a Test Drive experience. However, it is the interaction design, tightly knitted with your nurture campaigns, that will help in building a continuously delightful experience for your prospects and customers.


**Build a resilient and scalable system**: A good developer also designs for scalability so that if and when you are lucky to go through a hockey-stick growth curve, your systems don’t keel over. An architecture that considers not just how to scale elastically, but does so in a cost-effective fashion is something software engineers have to think through before writing a single line of code. As a bonus, your website gets rewarded with better SEO ranking if your performance scores are high.


**Create a data-driven experience**: Just like your product, you need telemetry information to understand some of the attributes that may have a higher correlation to trial users turning into paid users, aka markers for Product Qualified Leads (more of this in another blog). You need to build the foundations early on to read into daily metrics and to provide recommendations to the marketing team to improve the experiences incrementally.


**Automate**: One of the most significant advantages of having software engineers in your team is the DRY mindset often used in programming. DRY stands for Don’t Repeat Yourself. This line of thinking enables developers to look at existing manual tasks and to build an automated process that saves your team hours of effort.

Hopefully, at this point, you realize why it is critical to build a developer/engineering team in your marketing organization before you hire anyone else. Hopefully, just like my interviewee, I have convinced you that the lines have started to blur between writing code for marketing vs. writing code for the product.

In the end, we are all serving our prospects and customers through code these days, and you need outstanding engineers and creative professionals to think through how to build delightful experiences. Feel free to leave a comment if you have an opinion on this topic or have other ideas and would like to collaborate.

Why should a developer be your first marketing hire?

Customer Relationship Management (CRM) as a practice has been prevalent for decades. The value of the global CRM market was USD 52.4 billion in 2021. It’s expected to expand at a CAGR of 13.3% from 2022 to 2030 for good reasons.

CRM, as the name suggests, was primarily used to collect extensive customer and prospect data, yet it remained isolated from the support systems like Zendesk and Freshdesk where a lot of valuable customer feedback and data is also captured. 

More recently, we saw an emergence of support systems identifying themselves as Support CRM but the information about the customers are often duplicated and spread over different systems. As more and more companies are moving towards a product-led methodology, we looked at 10 alternatives to Zendesk for tech SaaS companies based on a number of different attributes. Read on to learn more.

## Have You Geared Up?

Poor customer service is the top reason for websites facing abandoned carts, high drop-off rates, and lower adoption and churn. Since customer service agents are often the intermediaries, they do not always have the power to eradicate the problem immediately.

The complaint goes through a whole chain of service teams, Project managers, Product leads, and Designers, and only then do the developers (the ones who can actually fix the bug) get some work assigned to either fix or work on new features that the customers are requesting through customer service agents.

We need tools to bridge this gap between the front office customer support agents and back office engineering teams for a smooth to and fro and a speedier resolution of issues. This is where  Dev CRM tools come into play. 

They are revolutionizing the tech space with features like AI, Conversational UI, Self-service, and Mobile CRM, to name a few. 
If you are looking for traditional support management tools, Zendesk is often a choice for companies looking to implement a ticketing system. 

## A Support Tool Built For Ticketing

Some of Zendesk’s attractive features are

- **Ticketing systems** — a file of client & customer concerns.
- **AI-powered automation** — customer support & marketing.
- **Dashboard** — team progress analysis.
- **Self-service** — knowledge-based training.
- **1000+ integration** — track all shareholder requirements in one place.

Zendesk is a reliable management platform in the customer service sector that ensures multichannel support, integration with top apps, and smooth operations. You might think it’s time to switch to Zendesk, but you should take a step back to see the larger picture.

Do all the features they provide fit your organizational needs perfectly? Does the industry you belong to demand highly functional live chat support, or does it require more of a managerial and integration platform?

While this Customer Experience (CX) solution may be apt for companies like Shopify and Venmo, your company might want to look for other platforms more geared toward tech SaaS companies, such as DevRev.

## Why would you need Zendesk Alternatives?

Just like one size does not fit all, one CRM tool cannot work well with every business. Many of Zendesk’s features have their own set of anti-perks, such as a high price range, complex setup, and huge learning curve, which some companies cannot afford for reasons of their own.

Not every tool in the market is beneficial to you. Dedicated business management tools are available to serve your distinct business needs. The key is to pick and choose the right combination for you, similar to purchasing the right beauty formula for your skin type.

While evaluating diverse solutions to improve your business, ensure you cover bases and competencies in “evaluation and contracting, integration and deployment, benefit and backing, and precise product capabilities.” That way, you can position your business for success and scalability.

Staying ahead of the CRM revolution can give your business the edge, so keeping yourself up-to-date is essential. Here is the best amongst the Zendesk alternatives in the market today. Your go-to SaaS tool to boost business and product growth.

## 1️⃣ DevRev - The New-age CRM platform

![image](https://cdn.sanity.io/images/umrbtih2/production/fd81dfc0238167930186c73c7aea49fb21906913-3840x2298.jpg?w=3840)

We all know customers call the shots, and what better way to ensure CX satisfaction than to build in public and adopt a product-led growth strategy?

[DevRev](https://devrev.ai/) is a developer and customer-centric platform that uses API-first integration to connect the maker and the user directly. With no barriers between the two, the communication gap is closed, and bug fixes are almost immediate.

In times of remote work, much is lost in the back-and-forth between stakeholders and their various tools. Overlooking even one flow can dig holes in your roadmap.

Integrating DevRev in your early stages can help formulate a system where work directly impacts user and business outcomes. It connects data from various sources and streamlines the process through PLuG SDK, Trails, and Vistas.

**Plug SDK**— Integrate it into your application and gain the power to nudge and guide your users through the app. For instance, if a user raises a concern in the checkout process, the developer who built it gets notified and debugs at the source. You can build a trustworthy solution when you put away the bots and empathize with your users.

**Trails** — Trails are where the software draws a map across components, microservices, capabilities, and features. This way, you can monitor and visualize the construction and consumption statistics. It is like a roadmap on steroids.

**Vistas** — Vistas disrupt the market with an evolved ticket and system management. Think of it as a jira+slack+zendesk where a converged system of records enables oiled cross-team reporting and communication.

## Other Zendesk Alternatives

Along with Zendesk and DevRev, you can use some of these tools as supporting tools to elevate the experience of working in your organization.

## 2️⃣ Zoho Desk

Zoho is a context-aware customer service help desk that provides high-quality features with minimal integration, such as ultra-wide customization domain and automated workflow operations with reporting and analytical capabilities.

Their AI feature-Zia can speak to customers, auto-tag tickets, and access the knowledge base to find the apt solution. They provide solutions by industry, role, size, and operations of an organization.

## 3️⃣ Hubspot

![image](https://cdn.sanity.io/images/umrbtih2/production/0e8acfa0d47859832d4f5cfa0056f5880a18a901-1440x721.jpg?w=1440)

Hubspot’s Service Hub offers a comprehensive CRM framework with back-end features for businesses to manage front-end touch points like gathering customer service data and enhancing acquisition, retention, and expansion, amongst others.

The all-under-one-roof system of tools makes it easier to switch between building marketing, sales, and support team solutions.

## 4️⃣ Slack

![image](https://cdn.sanity.io/images/umrbtih2/production/0d1b6866eb7155cf13db691d47b8d090337406cb-1440x721.jpg?w=1440)

Need lightning-quick navigation of channels, introduce someone to your workspace, discover files and documents at an instant with advanced search modifiers or keep your developers updated on the new designs uploaded to Zeplin after every iteration? You got Slack!

It is a team collaboration tool that has got something for businesses of all sizes. With instant messaging, file sharing, and extensive integration, you can stick to the same app and summarize the work executed across all platforms.

## 5️⃣ nTask

A project management tool with powerful native modules allows for quirky features like monitoring project performance through in-built Gantt charts, automating task repeats to the desired frequency, and connecting issues to projects using smart metrics.

It uses a human-friendly kanban board to organize and assign tasks, keeping it secured with two-factor authentication. The mobile app makes it easy to keep track on the go.

## 6️⃣ Twilio

![image](https://cdn.sanity.io/images/umrbtih2/production/554c368360ad09356d140a34406e6d7f8522f6cf-1440x721.jpg?w=1440)

A cross-platform customer engagement solution that helps companies communicate with their audience on their channel of choice. Their API integration empowers businesses with features like reminders and alerts to context-aware software-based contact centers.

Twillio Engage, Frontline, and Flex, the latest additions to the suite of data management and analytics by Twilio Segment, cover the entire span of the customer lifecycle — from marketing to sales to customer service.

## 7️⃣ Clearbit

![image](https://cdn.sanity.io/images/umrbtih2/production/3ab2710e42551cb9658a1e239686862598c41f8e-1440x721.jpg?w=1440)

A sales intelligence software that helps you grow your business by sorting through data points of over 250 public and private data sources and creating actionable marketing opportunities.

Simply put, it is the marketing data engine for elevated customer and stakeholder interactions. It is the tool to connect with a user on a personal level by identifying prospects and understanding the intention of the user on your platform.

## 8️⃣ HelpJuice


It is an easy-to-use knowledge-base management solution that relies on the self-service module to help all stakeholders and customers navigate platforms easily. Your customer support team can cater to more instantaneous pain points and high-value tasks.

You get a closer look at what grabs the attention of users and the impact certain features make. You can then tailor the experience to fit your audience using cutting-edge analytics and comprehensive customization.

## 9️⃣ Intercom

![image](https://cdn.sanity.io/images/umrbtih2/production/49352493045b6cbdb39af19dbbb9c03ae1ba907f-1440x721.jpg?w=1440)

It is an Engagement OS that closes the gap between a business, and it’s customers. The ongoing dialogue system streamlines the communication with clients, enabling businesses to build authentic relationships through their sales and growth funnel.

Besides simplifying access to customer support, Intercom allows creating an in-depth knowledge base accessible to all on mobile and desktop at all times. Once a call is done with a client, you receive a full report of the customer pain points, the conversation’s development, and the issue’s status.

## 🔟 Freshdesk

![image](https://cdn.sanity.io/images/umrbtih2/production/08e790e6de0adc378d19577bb90706c8be73d505-1309x655.jpg?w=1309)

Freshdesk advocates real-time information and documentation updates, which uses collision detection to ensure multiple employees do not simultaneously overlap on the same ticket.

A self-service customer support portal caters to small and medium-sized organizations. Its intuitive and easy-to-use interface keeps the learning curve small, which makes onboarding new workflows quite simple.

## Conclusion

We have picked out a comprehensive list of top business and customer management software from the constantly evolving technologies, as the most viable options for Zendesk alternatives. Most features can be repetitive, which every organization needs, but the key is to identify the correct permutation and combination of tools for your business.

Business requirements change as the product evolves, like the tools you invest money and time. Keep an eye out for disruptive tools in the market from the get-go and provide a well-structured foundation for you and your team

10 Zendesk alternatives to power your organization with Product-Led CRM

## Becoming a DevReveler
Having spent nearly a decade building enterprise software, I continue to be motivated by the impact technology enables. My passion will always lead me to find ways to create products of lasting value that transform the way people work.

I am optimistic that the biggest opportunity for work transformation lies in connecting the maker toolchain to customers. That is what drove me to join DevRev and lead the Product Management organization. My role is to help us rev from zero to one, as we create a new product category which enables developers to build products, support customers and grow their businesses in today’s product-led world.

## Meeting DevReveler #1
I came to DevRev from Salesforce where I was Vice President of Product Management, heading up the roadmap and strategy for Salesforce Anywhere, a real-time & intelligent CRM collaboration application. After joining Salesforce through the acquisition of MetaMind, I led a subset of Salesforce’s Einstein AI products including Einstein Voice, Einstein Voice Assistant and Einstein’s Deep Learning Platform Services.

I was first introduced to DevRev while the company was in stealth mode. It was quite a serendipitous experience that brought us together. I was chatting with a close colleague about my passion for end-user experience and the intersection of machine learning and design, and he quietly hinted at a new startup that shared these same enthusiasms. It was a vague introduction due to DevRev still being pre-launch, but the ambiguity of it all piqued my interest and it didn’t take long for me to recognize our vision and passions aligned.

Diving into a new adventure
I believe that timing in life is everything. When an opportunity arises that you feel like you can’t miss out on, the best thing to do is to take the plunge. That said, I had an amazing journey at Salesforce from the day MetaMind was acquired and appreciate the mentorship I received there.

While at Salesforce, I was able to help start its applied AI Research team and the Einstein product portfolio with Richard Socher and John Ball. A couple of years later, I got the chance to work extensively with Salesforce CEO, Chair and Co-Founder Marc Benioff on Einstein Voice Assistant and Voice Apps. I then finished my time at Salesforce collaborating on Salesforce Anywhere with Bret Taylor and Kevin Gibbs at Quip.

All of these experiences shaped my product mindset but the hardest part of moving on was leaving behind a team of amazingly talented product managers, designers, and engineers with whom I was so fortunate to collaborate with during my time at Salesforce.

## Transforming the product development experience
What attracted me to join DevRev were the people, the culture and the vision. The fact that we are building a lasting company with a long-term mindset for how we get there, makes DevRev feel like a place where I could happily spend the rest of my career.

Coming to DevRev, the biggest adjustment for me has been starting from scratch at a new organization and ensuring that I invest time in building relationships with my colleagues across not only the engineering, product and design team but also with all of my cross-functional peers.

I’ve been working on product-led growth (PLG)-focused products almost my entire career. As a product manager, I relate deeply to the problem we are solving, which makes building a product for this space feel natural to me. Every pain point, every metric, every process we look to improve for our customers, I too have experienced first-hand. I’m excited to find creative ways to improve how dev teams operate and influence the future of SaaS.

The potential is limitless, so I like to ground myself in how we execute in the near-term. In many ways, the future is already moving in the direction that we are headed. Every business is truly starting to think like a software company, and every software company is becoming PLG-focused. Ensuring we are building the right tools and user experiences to make every organization successful is what I find most exhilarating.

At DevRev, we are transforming the product development experience and delivering joy to end users. I recommend anyone that is motivated by the problems we are solving and the impact of their work to reach out to be a part of this journey.

My journey from CRM to DevCRM

Trying times often produce unique brands. Salesforce started in 1999, just before the infamous dot-com crash. Nutanix, Uber, and Slack were founded in 2009, in the trough of the global financial crisis.

Our startup, [DevRev](https://devrev.ai/), came together late in 2020, with the world in the grips of COVID-19. We’ve grown quickly, with most people working from home in North America, Europe, and Asia. We have had a monumental fund-raise. And we’ve brought stellar people together to turn a fundamentally disruptive idea into successful products.

Throughout the pandemic, we learned three critical lessons to make remote work, work:



**Conscious Hiring**: building mutual trust with candidates without ever shaking hands.


**Conscious Operations**: SaaS makes it so much easier to start and scale a new business. However, autonomy and automation are keys to an employee-conscious business.


**Conscious Teams**: Zoom is good, but for long-term decision-making and relationships, seeing people face-to-face is gold.

Before we go further, it would be remiss if we didn’t start by saying that the pain and loss of human life this pandemic has inflicted worldwide is heartbreaking. Unfortunately, a lot of suffering continues, and we cannot lose sight of that. We hope that humankind emerges stronger out of this global crisis, like we hope to do at DevRev. People are our greatest asset, and the lessons learned in assembling them during this lockdown will be etched in our memories forever.


**Lesson 1: Recruitment and the “Why Not” Challenge**
The other day, we hired a developer halfway around the world and she joined *the same day!* That’s almost unheard of before the pandemic. The physical world brought immense limitations that didn’t make us think outside the box. We call it the “tyranny of status quo.” COVID helped us invoke first principles way more than we ever could have imagined: *why not.*

When we recruit new talent, we can visit top colleges in every continent without ever stepping out of our homes. Similarly, applicants don’t have to travel cross-country and sit around for hours waiting for interviewers to talk to them.

Everything about remote-only recruitment can be turned into a competitive advantage: the breadth of candidates, the depth of discussions, and the ability to turn candidate experience into self-service. We can watch them code live — yes, in real-time! We can provide feedback at lightning speeds. And we can get them onboarded exceptionally fast.

In over 20 years in the tech industry, we have learned that many breadth leaders rarely get to talk to candidates directly, unless they’re the hiring manager. EAs are too protective of their schedules. Calendly is our new EA. Greenhouse APIs are our new scheduler. Tray.io is our new recruiter!

Speed is our new friend.

**Lesson 2: SaaS without self-service is a dying breed**
We are amazed at the number of cloud-based software tools our company could try out for free and then pay only for the ones we loved. We like the subscription economy. But we love the consumption economy. Welcome to the era of PLG!

![image](https://cdn.sanity.io/images/umrbtih2/production/a17663a64cb19d071b4716fa4c18c746f8828432-1400x861.png?w=1400)

There are delightful tools for recruiting, hiring, collaboration, communication, accounting, payroll, expense management, project management, employee success, banking, and cash management — pretty much anything we need. And guess what: we didn’t have to talk to a single salesperson to use these services, nor did we ever have to visit a brick-n-mortar office to incorporate in 3 continents. Unthinkable before COVID. Possible because of COVID.

Everything we needed was in Google Workspaces, Slack, Zoom, Notion (Wiki), Discord (community), BambooHR (HRIS), Gusto (payroll), FindEm (sourcing), Greenhouse (recruiting), Ease (benefits), Okta (identity), Figma (design), Brex (banking), Miro (ideation) and so on. All said, we’re using more than two dozen SaaS products, and we’ve become the masters of stitching them together via Tray and Pipedream.

*Integration is king. Employee experience is paramount for remote workers. Developers are the magic without whom there is no “ops” in People Ops.*

P.S.: No wonder we worship #Dev.

**Lesson 3: Zoom is good; a fist bump is golden**
Until a couple of months ago, we had not met a single team member in person. We hadn’t even met each other for almost 15 months until both of us were double-vaxxed. DevRev was seeded in the parallel universe of Zoom; such was our trust and conviction in the idea.

![image](https://cdn.sanity.io/images/umrbtih2/production/b36f894bb8a5eb6d8373b2c2faa37bab1a9a20bd-1400x934.png?w=1400)

There is no pride in how it all transpired though. We wish for the pandemic to get over soon. Building trust, context, and purpose is not easy without touching each other’s lives in person. Building a career is immensely hard, especially for new college grads, without the serendipity of the office environment — the appreciation of colleagues (dopamine), the mentorship of buddies (oxytocin), and the mastery of solving complex problems (endorphins).

Work for us will forever be hybrid. We have to think global and act local. Only then can we resolve the inherent tensions between autonomy and purpose, experience and youth, deep work and broad work… we and I.

**Sapiens, and the Imagined Myths**
Microsoft was forged in the ’70s and ’80s amidst oil price shocks and economic stagnation. Ditto for Apple. Google’s formative years were the years after the 2000 crisis. Amazon got forged during the ’08 crisis, as did Netflix. The best companies make the best of difficult times. Shocks make them antifragile. Stories of survival and adversity form the urban legends that “tribes” use to navigate the highs and lows of company-building. Harari speaks of this in Sapiens:

![image](https://cdn.sanity.io/images/umrbtih2/production/cf142d4348ee293a04bb19bf5734422ac065e60d-1400x934.png?w=1400)

The pandemic years will define the collective consciousness of our people. The bonds forged during this lockdown will shape the future of our company. The concrete we poured to fight this virus will form the foundation of our organization.

The stories of COVID-19 will shape the *Sapiens* of DevRev. 🍀

Founding a company during the pandemic

When someone brings up artificial intelligence, often what comes to mind are uncanny valley robots who are secretly plotting to overthrow their human overlords. The reality isn’t quite as glamorous and at least for the foreseeable future, will never be like that. While artificial intelligence has come a long way since the 1950’s, we won’t ever reach a point in time where developers are obsolete, no matter how advanced AI gets.

A developer’s job is not just composed of writing code; they have to consider everything from integration to scalability to customer wants. I’d argue that the code writing portion is only 15% of a developer’s job. While we won’t ever reach a point where AI can do the remaining 85% of what a developer does, we are fast approaching (and maybe even at) a point in time where AI offers an incredible amount of value to that 15% and it may seem silly (or even impossible) to go back to a time where we coded without it.

**What does offering value to developers mean?**

Offering value to developers means that a developer’s workflow is improved. This can take many forms but in the context of AI, some examples include code auto-completion (such as Tabnine or Github Copilot) or even code generation from natural language, such as OpenAI’s Codex. Regardless of what form this value-offering AI takes, the common thread among the products that offer the most value is that they are disruptors.

**Disrupting the tech industry**

Recently, I had the [pleasure of speaking](https://youtu.be/Xkz9awCvnRY) with [Vinod Khosla](https://www.khoslaventures.com/team/vinod-khosla) of Khosla Ventures. Khosla has been involved in the tech industry since 1980 and he is no stranger to disruptors. His VC firm, Khosla Ventures, has invested in some of the most successful companies in every industry, ranging from DoorDash to [OpenAI](https://openai.com/).

I actually got the term “disruptor” from my talk with Khosla. I asked him if he had a core thesis that he followed when choosing which companies to invest in and he said:

*“I work on the things that are hugely disruptive… I don’t mind a higher probability of failure as long as the consequences of success are consequential.”*

For Khosla, this has always come back to tech and recently, has been focused in the area of AI. I asked Khosla how he has seen AI driving change (and disruptions) in the tech industry and this is what he told me

*“The power of technology has now enabled it to enter all parts of society not just the tech parts of society… technology was a tool for technology spaces and now it’s a tool for everything.”*

It’s an accurate statement: you’d be hard pressed to find a company that isn’t trying to leverage technology to better their product and improve their customer’s lives. The entry of technology into all spaces has subsequently meant the entry of AI into all spaces and already, AI has shown uncapped potential to improve the developer’s workflow.

**OpenAI’s Codex**

One of Khosla’s investments is OpenAI, which I’ve mentioned several times. They started as a natural language processing focused company whose goal was to generate human-like text. (Think early chatbots like Cleverbot but with magnitudes more training data and expansive neural networks.) They’ve made huge progress in the area of NLP with GPT-3 which has been widely applauded as one of the best natural language text predictors there is. 
**More recently, they unveiled Codex, which leverages the power of GPT-3 to produce code from natural language.**

**Codex’s functions do not just stop at generating code from comments: it can also generate comments from code, debug, translate between coding languages, and a myriad of other functions.** It makes the 15% of a developer’s time that is spent coding much easier and enjoyable. [DevRev](https://devrev.ai/), like Khosla, recognizes this and have teamed up with OpenAI to host a [hackathon](https://dvrv.ai/hack0mb).

**Hacking our way to a better future**

DevRev’s [Coding With AI Hackathon](https://dvrv.ai/hack0mb) has one goal: 
**usher in a new era of coding with AI through the form of a VSCode extension.** Participants of the hackathon will gain access to OpenAI’s Codex to power their VSCode extension. You can see a demo of my extension [here](https://youtu.be/Xkz9awCvnRY), which is followed by my chat with Khosla.

You can also get my extension code [here](https://github.com/devrev/hackathons/tree/main/hack0/codex_extension), which I plan to continuously improve and debug.

While my extension only has two functions, code generation from comments and comment generation from code, the list of features your extension can have is only limited by your imagination; 
**I encourage you to solve the problems that bug you the most as a developer and, in the process, get a chance at winning $10,000!**
While I understand that the thought of AI can sometimes be scary, as someone who works in the field, I also understand that AI comes with enough limitations to prevent it from ever overthrowing me (or any other developer). I implore you all to learn more about AI and even participate in our hackathon to get some hands-on experience with AI. Feel free to also join our [Discord server](https://dvrv.ai/discord) and ask questions there.

Why AI won’t replace developers and why it will make our lives better

Dheeraj Pandey on leaving Nutanix to start CRM startup DevRev

Like any self-respecting middle-aged man, when I turned 40 a few years ago, I took up long-distance running. For me, this involved buying a lot of shoes and gadgets and one of them was called Milestone Pod. 

The gadget was a Bluetooth device that you put on your shoe and it was supposed to record your pace, length of your run, etc., and give you tips on how to increase your pace. Right before I was about to go for a long run, I opened the pod, put it on my shoes, and tried to connect it to my phone for the first time. To my surprise, no matter what I did, the pod refused to connect with the phone. I tried for about 15 minutes then got frustrated and decided to just go for the run the old-school way, without a gadget.

When I returned from the run an hour later, I had a support email from Milestone Pod waiting for me. The email said that it was detected that the Milestone Pod that I was trying to connect was faulty which prevented it from pairing with my phone and a replacement device had been dispatched to me at no additional cost.

I was blown away by the experience. This was truly a product-led support experience, an automated flow driven by the usage of the product. 

In order to build a product-led support system, today you have to handcraft connecting multiple systems like a conversation widget, a support ticketing system, and a work management system (for example Intercom, Freshdesk, and Jira). However, despite connecting disparate systems, you still don’t have an elegant way to tie it back to your product capabilities and features. 

Now imagine you had a conversation widget that you could embed in your app with a few lines of code and all your customer conversations immediately get linked to Tickets which in turn get connected to Issues (a way to track Developers’ work) which in turn are tied to you actual product capabilities and features (code in your code repository).

This immediately opens up bi-direction sync between your product features and customers through the work going on within your engineering teams. 

This is exactly what we launched today on[ Product Hunt](https://www.producthunt.com/posts/devrev-plug). DevRev PLuG, the first app on our platform enables companies to provide an elegant product-led support experience. Not only does this eliminate costly multi-product stack and expensive integrations and overhead, but it also puts the makers, and the developers in sync with how the product is being used by end-users and the feedback pouring in from the front office. For startups looking to achieve Product Market Fit (PMF), they now have a solution that helps them prioritize work across their teams that are truly impactful to the end users and customers and consequently the entire business.

Starting today, you can sign up for beta in a zero-touch fashion from our website and we hope you use it and provide us feedback and engage with us both on the Product Hunt website as well as our social media channels and help us make PLuG better. If you have questions, feel free to ask or just say Hi from the PLuG installed within DevRev. Just like inception, we are supporting our users through our instance of PLuG.

We are live on Product Hunt

8 is a lucky number in Chinese; It’s pronounced [bah] which sounds like the character for generating wealth [fah]. While my first 8 months at DevRev have not yet generated wealth in the traditional sense ($$$), it has generated wealth in other ways. And since I figured it was finally time to stop saying I would write and start actually writing, here are the top 8 things that have generated the most “wealth” for me in the last 8 months at DevRev.

![image](https://cdn.sanity.io/images/umrbtih2/production/95b77895206291a3959f6993aabcb9c0cf044536-1400x776.jpg?w=1400)

The characters for “eight” and “generate wealth”

**1. Read and comprehend**

Yeah, I know, super basic, but I couldn’t exclude it.

Growing up, I was one of those kids that would go to the library once a week, check out 8–10 books, read them, then return the books and repeat the process the next week. Unfortunately, by the time I got to high school, I read a lot less and my tolerance for reading long periods of time dropped. Towards the end of my college career, I decided to pick up reading again. While I found that my reading speed was still quick, my comprehension skills were abysmal; I often had to reread text once or twice before truly understanding it.

You might be thinking “But Violex, you’re a software engineer. Why do you even need to read? Just write your code.”, which is a fair enough argument. However, all the best software engineers I know have high reading comprehension skills and tend to be avid readers as well. Think about it: while writing code is integral to my job, I can’t do that well if I don’t understand the codebase first. Writing code without understanding the existing codebase is like trying to put in a puzzle piece blind; you don’t even know if your piece is part of the puzzle, let alone what it looks like in the grand scheme of things.

In addition to reading the codebase (or at least some of it), reading comprehension also comes in when doing code reviews. Since I am in my early career, I’m not requested to review that much code, but every time that I am, I find that the more I work towards reading and comprehension, the quicker and more pain-free the process is. By working on reading comprehension, I’ve been able to do my job more and more efficiently.

**2. Build solid habits**

When I was in college, my life was in disarray; I would sleep at odd hours, exercise sporadically, and nothing about my lifestyle ever seemed consistent. While it worked for me at that point in my life, after I started at DevRev, I realized that I seriously needed to establish solid habits because the effects of my habits were no longer isolated to me. Having solid habits is the foundation of having a healthy and productive lifestyle.

While there is certainly no one-size-fits-all in terms of habits, I’ve found that establishing habits around integral parts of my existence (sleeping, eating, and exercising) has not only improved my quality of life but has also made establishing more complex habits easier. I’ve learned a lot of what I practice from various books but the one I recommend the most is James Clear’s Atomic Habits. Clear clearly (haha) breaks down how to establish habits and build them up.

![image](https://cdn.sanity.io/images/umrbtih2/production/2c16170d1ce1a008c408aa74751cef1f7ef2efee-1400x880.jpg?w=1400)

Image credit James Clear, author of Atomic Habits

If I could offer one piece of advice though, it would be to 
**never skip habits twice in a row**. Nobody is perfect, certainly not me, so having days of skipped habits is going to happen. However, if I skip a habit, like working out, two days in a row, I’m far more likely to continue skipping it, which builds up a habit of not exercising. Technically, everything and anything can be considered a habit, as long as you do it 
**consistently.**

**3. Put everything in your calendar**

Yes, everything. While you don’t need to tell your coworkers you are getting a colonoscopy between 2 pm and 4 pm next Tuesday, you should at least block it out with an event titled “busy” in your calendar to signal that you are busy. I even put personal events that occur outside of 9–5 in my calendar. Because [DevRev](https://devrev.ai/) is a global company, blocking out time for personal things is sometimes necessary as my personal time may be another person’s working time.

Another trick I’ve found to be useful is to set up working hours. As much as I love my job and coworkers, I refuse to have meetings before 8 am and after 8 pm and working hours lets my colleagues know when I am officially on and off the clock. (It’s still possible for someone to schedule a meeting with me but they are forced to acknowledge that it’s outside of my working hours.)

In addition to work benefits, having an organized and updated calendar also helps me visualize my work life balance; Google Calendar has even come out with insights about time spent in meetings.

![image](https://cdn.sanity.io/images/umrbtih2/production/18bd5e9fc4081d02f8f55dd11b983040fdf42aff-322x533.png?w=322)
Google calendar insights

Making sure my calendar is up-to-date helps others be respectful of my time and vice-versa. It also helps me be respectful of my own time :)

**4. Listen more than you speak**

I believe it was one of our co-founders, Dheeraj Pandey, who said that one should listen two times more than one speaks. This holds particularly true for me at this point in my career. Because I work at a startup that values ownership and believes in the power of youth, I am often asked for my opinion, which I’ll happily give. However, it’s when I hear the opinions and thoughts of others that I gain the most; I am surrounded by people who usually have at least a decade of experience on me and each time they voice their opinions, I gain insight.
The colleagues that I most look up to actively practice listening more than speaking as well. I think it’s human nature to want to hear yourself talk and in this day and age, being loud is often equated with being important or being correct, but this is very anti-productive. Think about it: you already know what you think so if you truly want to gain information or insight, you should shut up and listen to what others think. This isn’t to say you have to agree with them or even value their input but how will you know if they have valuable input if you don’t even listen to them speak?

**5. Say goodbye to comfort zones**

I am a self-proclaimed backend developer. Unless you count copy-pasting code from StackOverflow to cobble together a website as frontend development, I have zero frontend experience. Despite this, I have spent the last two weeks working on our product’s frontend.
While I won’t get into why, I will say that this is one of many times where I’ve stepped out of my comfort zone and each time it happens, I learn something new. For example, after three weeks of working on the frontend code, I’ve developed not only more respect for our frontend team who tirelessly work to build something beautiful and usable, but also a far better understanding of the relationship between frontend and backend. I’ve been able to see where the backend code I normally write fits in and this allows me to be a better developer overall.
For the tech industry in general (and I’m sure other industries as well but I only speak to what I know), staying in comfort zones actually results in not just a stagnant but a declining career; if you’re not willing to step out and learn and experience more, then you’re outdated.

**6. Take ownership**

At DevRev, the 
**owner’s mindset** is really emphasized. At its core, having an owner’s mindset means that you are 
**personally invested** in the product and the product’s success, or lack thereof, reflect on you. While this may sound like the opposite of work-life balance, it really isn’t; having an owner’s mindset means that you want to work to better your product because it belongs to you.

The owner’s mindset doesn’t just stop at the product; it also applies at the company level as well. Owners don’t just follow examples; they lead by examples. Whether it means owning up to mistakes, taking on new responsibilities and projects, or even making new colleagues feel welcome, for me, being an owner means being personally invested.

Even though I’ve only been working at DevRev for eight months, I’ve done my best to get my hands on and contribute towards a little bit of everything. This hasn’t just meant working on frontend things as a backend engineer — this has also meant owning things in realms like publicity and hiring, which are both outside of what a “traditional” SWE does. However, by taking ownership of these things as well as my “normal” duties, I’ve gained a higher sense of clarity about both DevRev as a company and as a product. This heightened clarity allows me to perform better and hopefully inspire others to do the same.

**7. Be stretchy**

This is directly taken from the book [“Stretch” by Scott Sonenshein](https://www.scottsonenshein.com/stretch/). In this book, Sonenshein breaks down two concepts: stretching vs. chasing. Essentially, stretching makes the most of resources while chasing exhausts resources in the pursuit of more. While DevRev is not exactly a “typical” startup thanks to a [hefty seed round](https://techcrunch.com/2021/07/14/former-nutanix-execs-launch-new-startup-with-50m-seed-round/), we are consistently reminded to stretch and not chase. Having a stretchy mindset leads to innovation because making the most of resources often means utilizing those resources in nontraditional ways.

Prior to DevRev, I definitely leaned more towards chasing; if I needed to hammer in a nail and didn’t have a hammer, I’d buy a hammer. However, after joining DevRev and learning more about stretching, I’ve realized that I’ve wasted countless resources because of self-imposed limitations. Who’s to say that a shoe or a tape dispenser or a book can’t be a hammer?

While there are some things in life that I believe are worth chasing (my personal picks are gold jewelry and leather goods), pivoting to stretching instead of chasing day-to-day has meant that my resources (whether it be money, time, energy, or something else) have increased since the resources I do possess have increased in use and as a result, I’m spending less resources overall to pursue wealth.


**8. Fail often and fail fast**

There was some cheesy quote on my middle school science teacher’s wall, something about how Ben Franklin didn’t fail 1000 times before making a working light bulb but how the light bulb just took 1001 steps to make. Ben Franklin controversy aside, I actually really like that quote. (Another quote I like also came from a middle school classroom wall: “Shoot for the moon and land amongst the stars”… but I digress.) Without trying to be too deep, the light bulb quote is essentially saying that failure is not just part of the process, but integral to the process.

![image](https://cdn.sanity.io/images/umrbtih2/production/096b68e92158ea45d2c8da94e9050d1ba0629b0e-960x540.jpg?w=960)
Photo credit to Qimono on Pixabay

One thing that quote doesn’t cover, however, is failing fast. This is tangentially related to being stretchy as it’s also about conservation of resources; failing fast means that when something isn’t working, then it’s best to cut losses and move on. This doesn’t always mean entirely pivoting away from a goal; sometimes this can just mean re-evaluation of the current methods to reach that goal. In the context of the lightbulb quote, out of the 1000 failures, there should be at least 400 unique failures.

For example, theoretically, if you throw a ball at a wall infinite times, it is bound to pass through once. However, reality isn’t theoretical and if you sat throwing a ball at a wall over and over again hoping for it to go through, you’d realistically be an idiot. Essentially, failing over and over again by repeating the same process is a huge waste of time and resources. Ideally, you should learn from each failure and every new iteration should be different in some way.
The last eight months have been a whirlwind; in addition to starting work at DevRev, I also graduated from university, moved to a new city, and got a dog.

![image](https://cdn.sanity.io/images/umrbtih2/production/54ce74cb92282801aa4e51d33c8295658ceff5d6-1400x1866.jpg?w=1400)
Ranger!
However, despite all the changes in my life, the eight things that I shared with y’all today have helped me stay centered, focused, and productive, giving me more energy and motivation to work on a product that will generate wealth for developers everywhere. However, that is yet to come so I hope you’ve at least gained some wealth in reading this article :)

Eight things I learned in eight months as an engineer at a tech startup

## Enter Your Startup
You are a humble newly-hired front end developer. Perhaps you’ve faced the gauntlet of higher education and triumphed over a handful of carefully-designed course projects. Perhaps you’ve embarked on every developer’s ultimate vision quest and crafted a personal portfolio site. Perhaps you’ve even saddled your trusty steed and traversed a few Udemy courses.

But now… you find yourself in a whole new world, a terrifying, overstimulating landscape; where the project specs are vague and nothing is ever “finished,” where technologies seem to change faster than you can learn what they do, where collaboration is king… you’re in the real world now, and you work for a tech startup.

The High Council has already given you your first quest: you must construct a page for the app. It seems simple, but don’t let yourself be deceived…

## Begin Your Work
You are surrounded by mentors: wise old sorcerers perched cross-legged atop staggering mountains of experience. They look down upon you with gentle smiles, their robes billowing in the wind. One look in their eyes and you can sense that what would take you weeks to accomplish, they could conquer in a few keystrokes. But they will only help you so much, for they are occupied with the greater demons which threaten the kingdom, and this mission is yours to stumble through. They will be there when you need them, to lean over your computer and type mystical commands you didn’t even know existed into your terminal, but they will not make this mission easy for you. Don’t forget that they were once just like you, back when they were just starting out: when people used to write code on stone tablets and power computers with hamster wheels. If they hadn’t struggled back then, they would never have summited their mountains. You must begin to climb.

Suit up and cast the age-old incantation: git clone. You’re suddenly transported to a terrifying labyrinth. You’ve seen React code before, but never at this scale. Pages upon pages, components upon components. You can’t even begin to understand how it all holds itself together. And what’s this? TypeScript? Since when did you have to worry about types?! Don’t let yourself be overwhelmed! You don’t need to master every corner of the repo — chances are, nobody has. Start by finding where to look. Unsheath your Chrome DevTools, command-F like a madman.

You’ve found where your page needs to go! This is the spot, obscured behind seven layers of ambiguously-named folders. There should really be some documentation for this. But remember, this is a startup: the documentation is in your heart. 

Oh! What’s that you’ve written there? “Hello World!” Look into the divine orb of your local environment and you’ll see it there, written out in the app! You made that happen! You’ve already navigated the maelstrom of typescript and contributed to a real-life app! We’ll make a wise old sorcerer of you yet! Now, surely, you’re ready to begin building.

Every builder needs a blueprint. Venture out, humble developer, to the land of _Design_.

## Acquire Your Mockup
You climb a thousand ivory steps leading up into the sky, and emerge in a palace of clouds. The feng shui of the furniture is immaculate. The air smells faintly of sandalwood and hums with the gentle notes of a distant harp. This is where The Designers live. They worship a divine spirit known as Figma. One of the designers glides towards you and unfurls a scroll to reveal a mock-up of the page you need to create. You almost have to look away, it’s so beautiful. Every text block is perfectly sized, every icon meticulously aligned.

You take the mock-up and hurry back down the staircase to your desk, almost stumbling over yourself. You won’t let the designers down!

You begin crafting the page exactly as the designers envisioned it, one piece at a time. You find existing components within the repo, you even create your own when you need to. You’re on a roll now: making commits and watching the hours fly by. You wind up at a new part of the page. Perhaps it’s a table of users, or a list of tasks, or some conditionally formatted settings. Whatever it is, it’s chock-full of data that you don’t have! Suddenly, the quest feels much more daunting.

How will you get this elusive data? It’s time, humble developer, to visit the caverns of _Back End_.

## Uncover Your Backend
You don your spelunking gear and travel 100 fathoms underground through a system of booby-trapped caverns. Here you are, in the impregnable fortress of the back end developer. The walls are covered with massive futuristic screens displaying precise metrics, self-deprecating memes, and high-stakes infrastructure-related Slack debates. The air-lock doors close around you and a scanner ensures you have all the necessary dependencies installed before granting you access to mission control. A developer appears before you in the form of a ten-foot-tall hologram. Every single one of these developers hosts a wealth of constantly-evolving knowledge, and they communicate using strange alien words from another planet: they speak of WASMing the Styra Docker into the Cloud Rego and microservicing the Mongo Harness deployment through the binary CI/CD archetypical archetype binaries. 

The hologram reaches into their cloak and produces a stone tablet of data contracts. It’s all the information you need to harness the power of the API within your code. They hand-crafted these API endpoints just for you, so that you can seamlessly access and modify the massive streams of data coursing through their underground fortress of logic, bridging the gap between backend and frontend.

You clutch the tablet to your chest and clamber out of the underground tunnels. You won’t let the backend developers down!

## Hit Your Roadblocks
Back on the ground, you find that even though you thought you’d assembled everything you’d need, you’re stumbling more than you’re making progress. This is when a harsh lesson surfaces. Those designs, those API endpoints? Well, they’re actually works in progress, just like your page is. You’re so used to the world of planned-out courses, where every project is handed to you prepared to be completed from start to finish. Here in this new world however, everyone’s projects are rubbing up against one another.

Some API endpoints are returning errors. Some parts of the design mockup are either outdated or impossible to implement. Sometimes the designs call for a wealth of data which the API endpoints you’ve been provided with just aren’t able to provide. Other times, the format of the designs don’t seem to align with the page’s purpose as it was explained to you by the project manager. And if only those endpoints were built a tiny bit differently, it’d save you a hundred lines of code!

The days go by, and your progress dwindles. You can’t imagine yourself summiting any mountains or slaying any dragons any time soon. You wake up and mount your trusty steed every morning full of frustration, knowing you’ll just be waiting to get unblocked from two different directions and praying that by a stroke of luck, those updates to the backend and the designs will actually give you the resources that you need to build this page.

You find yourself thinking: _Shouldn’t this be somebody’s job?! Making sure these different teams are actually on the same page? Making practical decisions about what needs to be done so that the page can actually be built any time soon?_

That’s when it hits you. There’s more to this adventure than you thought.

## Advocate for Your Work
The designers are up above you, casting down rays of beauty. The backend developers are below you, adding structure to your world. But only you are on the ground, where the humans (for revenue purposes: customers) live. Don’t let yourself underestimate your importance, humble developer! In fact, you’re responsible for the only part of this whole system that the users are tangibly interacting with! Remember that they create those API endpoints for you! They design those mockups for you!

They are lofty sorcerers full of wisdom, to be sure. But you are one too.

Once you recognize that these intimidating sorcerers are your colleagues, and that you are theirs, you can realize your true power. You are the _Frontend Developer_. You are the bridge between design and backend, harnessing their infinite powers in the mortal plane. You don’t just answer to them, you work alongside them. If you think they should do something differently, for the sake of the app, let _them_ know. They would do the same for you.

If only your quest could be as simple as to _build the app_. You could wrap it up in a few days and move on to the next adventure. But the reality isn’t so simple: your true responsibility is to _make the app happen_. You have to build it, sure. You also have to bring together the pieces you need to build it. You have to make sure that they’re the right pieces, and let people know when they aren’t. Sometimes you have to compromise to get something done sooner rather than later. Sometimes you have to ask other people to compromise. Sometimes you have to stretch yourself beyond what you thought capable: learn enough Figma to design your own mockup rather than waiting; familiarize yourself with the backend code enough to understand what’s causing bugs and help to fix them. Whatever it takes, make the app happen.

A long and dangerous road awaits you, humble developer. Don’t lose sight of your own power, and you’re sure to reach the summit…

Also, maybe don’t wait too long to submit a pull request because you’re scared of getting your code reviewed, leading to a request that’s way too big to review in a reasonable amount of time. That’s what I did, and people got kind of mad at me. So that’s probably some good advice too.


A budding adventurer’s guide to frontend development

_“This is f***ing crazy. Every single player is seeing a different deal!”_ It was 2017, I had just deployed an AI-driven sales infrastructure for a gaming company, when I saw messages like the above from our most fanatic players. I remember being excited that our users had even noticed that we were customizing their experience. But, my elation came crashing down when I realized that the initial model we deployed didn’t move revenue at all. In fact, it took many more months before we found the winning approach. Along this journey I learned a lot about building a very responsive and nimble AI infrastructure.

Fast forward to half a decade later and now that user-centric design is the cornerstone of Product-Led Growth, it is all the more important to deliver customized experiences to your users. However, as I learned the hard way many years ago, it is equally important to quantify the impact of your customizations and have an infrastructure in place that makes it easy to iterate upon. Towards that end, this article is designed to help PLG startups plan out their roadmap by giving a sample architecture to strive towards. Of course, the author would in no way claim that the described architecture is the best for everyone, or even the best AI architecture in general. The hope is that this can be a useful starting point for debating the merits of different approaches.

In order to avoid vendor-specific debates polluting the discussion, I’m avoiding naming any specific vendor or open source product. However, I am describing the specific requirements that each of the boxes below should satisfy and why. This should help you flesh out your specific infrastructure with your unique preferred solutions.

## Stage 1: The Base App
Let’s start with the most simplistic App. Let’s assume that this has some kind of user interface and it is backed up by a database. Yes, this looks cartoonish, but it is surprising how many Apps can be described in such simple terms if we bundle all of the middleware-related optimizations in the “App” bubble below.

![image](https://cdn.sanity.io/images/umrbtih2/production/27f9806aa6d8c060ea5eeaffe77186d7d74d11e7-537x124.jpg?w=537)

Now, the backend could be any kind of database really, but it has to support a high degree of concurrency since millions of users will be using the App simultaneously (we hope, right!). Also, the most common access pattern involves selecting and modifying a small number of rows at a time. Databases that are optimized for such a usage pattern traditionally come under the umbrella of OLTP  (Online Transaction Processing) Databases. This includes what are fashionably called NoSQL or Document Databases.

## Stage 2: Observability
A very natural next step on the base App is to provide some storage mechanism for the various log files that all of the application code and included libraries will spit out. These can be redirected to any log storage solution as long as it provides the ability to search for patterns and can alert your DevOps team in response to unusual errors.

In order to help your DevOps team extract more structured meaning from the log files, specific metrics will be added to track critical activities in the App. These metrics can be something as simple as 
- the number of successful and failed logins, 
- the real-time revenue (in case of gaming apps), 
- or the number of users using some key functionality of the App. 

These metrics are designed for DevOps to quickly identify any anomalies and not necessarily to slice and dice the App usage by user groups. As such these metrics could include low cardinality dimensions such as the country name (which can have a few hundred unique values) but not necessarily the user identifier (which could be in millions, right?).

These metrics are typically sent to a time-series database that provides a simple interface to receive records such as:

>time=t country=us device=iphone6 event=login count=1  

The database should provide the ability to create dashboards on these metrics and also provide some form of alerting on anomalies. For example, if the number of logins from the UK suddenly drops then the DevOps team should be notified. Note that if the number of logins from a particular user were to drop then that is not something of concern to DevOps, but it would be more interesting to the Business Ops team which we will describe in the next stage.

![image](https://cdn.sanity.io/images/umrbtih2/production/10654c3b16806496a94299b8dba05f3643926933-537x213.jpg?w=537)

## Stage 3: Events
The next stage in our hypothetical App’s evolution would be to add Events. Simply put, Events are highly structured objects that capture key activity in the App. They can be thought of as an extension of metrics to include dimensions of high cardinality. In fact, they could even be extracted from log files. The key feature of Events that distinguishes them from Metrics is that _**Events are used by Business Ops to analyze the health of the Product from a customer usage point-of-view while Metrics are used by Dev Ops to analyze the health of your Product from an infrastructure point-of-view.**_

For example, the metric that we recorded earlier could be extended to an event as follows:

>time=t country=us device=iphone6 event=login userid=u first_login=t1 tier=free count=1

Notice that the presence of a high cardinality dimension such as userid makes it difficult for time-series databases to handle them efficiently. Notice that we also added a couple of extra dimensions first_login and tier to this event. We would typically add a number of such additional dimensions as we will explain below.

These events are sent to a queue from which a stream processing service is used to create real-time dashboards:

![image](https://cdn.sanity.io/images/umrbtih2/production/b76e1366544f6ef04d5d02d8355397002a96d90f-537x262.jpg?w=537)

The dashboards, for example, could show the number of logins by age and by user tier. This can help Business Ops folks identify churn trends in different user cohorts. Here we can see the importance of augmenting the events with additional dimensions. If we didn’t have the first login time or the user tier in the event then the dashboarding service would have to lookup the user details from the OLTP database which would in turn make it unrealistic to have a real-time dashboard.

## Stage 4: Data ****house
The final stage in the pre-AI architecture is to create a home for all the data that you are gathering. This is a place where you can archive all of your events and if necessary join them with the full contents of your OLTP database to perform very deep business analytics. This stage used to be called Data Warehouse and later Data Lake and more recently Data Lakehouse. Labels aside here are the key aspects of this stage:
- Cheap immutable object storage to archive your past events.
- A replica of your OLTP database to avoid analytics workloads from impacting your App’s performance.
- Some analytics database service that can join data from both of the above sources and allow you to query it in a high-level language like SQL.

![image](https://cdn.sanity.io/images/umrbtih2/production/bd8440acaf96cd55dbae135b3a736ca2185c6b48-537x445.jpg?w=537)

An Analytics database is optimized for a very different access pattern than an OLTP database. While the latter works very well for concurrent access to individual rows, the former is designed to scan over very large partitions and perform aggregation or windowing operations. It is also quite normal for such databases to be synchronized every few hours or even once a day. Since the main use of this stage is to monitor long-term business trends, this delay is not significant.

## Stage 5: Model Training
Now that we have a baseline architecture, we are in a position to understand our user behavior. We can start building Machine Learning Models to try and predict various things about our user such as:
- Will a user log in to the App tomorrow?
- Will they spend money on the App?
- Will they use Feature X?
- Will they like to converse with another user Y?

These models can subsequently be used to customize the user experience, but first we need to be able to do a lot of exploratory analysis. Some kind of a Notebook service (for example Jupyter Notebooks) that can be connected to your Analytics Database and have access to a number of libraries for data munging, scientific computing, and model training can be used by Data Scientists in your team to come up with some concrete ideas. At this point the Data Scientists can directly save the model in a Model Storage or set up an asynchronous job to periodically pull data and train a model.

![image](https://cdn.sanity.io/images/umrbtih2/production/7b4b4edb7cf2d80b8ba19c74ad9036f2b98c25b2-530x384.jpg?w=530)

The key aspects of the Notebook service should be that it should be easy for the Data Scientists to share their work with each other, perhaps even version control their analysis. In addition, they should be able to directly share their analysis with non-technical folks.

An Asynchronous Jobs Framework can be very simple, such as a service that runs a single job periodically. Or it can be much more sophisticated with an ability to create a DAG (Directed Acyclic Graph) of Jobs that allows for very complex and large-scale distributed data processing. The Model Storage, on the other hand, can be as simple as a cheap immutable object store.

## Stage 6: Model Serving
Once we have some interesting Models of user behavior we can try to customize their experience. For example, if we think they would enjoy using Feature X, but they haven’t used it yet, we can suggest it to them. Or if we think they are about churn then we could give them some enticing offer that could persuade them to engage a bit more with App. However, it is not very easy to deploy a model, and proper choices made in this stage will determine whether you are able to actually deploy any AI in your App or if the modeling work of your Data Scientists remains a curiosity!

The key component that is needed in this stage is an Online Feature Store. This component listens to all of the events in real time and creates relevant features for each user. Some of the features could be summary statistics such as the number of times that the user has used Feature X in the last ten minutes while other features could keep bounded sets of records such as the last 50 items that the user has browsed in the App. The exact set of features depends on the model that we wish to deploy and the features that have been used in that model by the Data Scientists.

A component known as the Model Serving provides the ability for the App to quickly make any real-time prediction that is needed to customize the user experience. This component queries the Online Feature Store and looks up the specific model from the Model Storage to compute the desired prediction.

![image](https://cdn.sanity.io/images/umrbtih2/production/543f8822a066111c9eaa54e9250792fbe5721a24-536x504.jpg?w=536)

Sometimes the Model Serving layer can preemptively compute some predictions and store it in the main OLTP Database for very common predictions. For example, every time a user logs into the App we might want to compute a time-to-churn estimate and store it. Subsequently, every microservice within the App can directly lookup this estimate and use it to customize the experience.   

## Stage 7: Experimentation Platform
As I said in the beginning, it is not enough to deploy cool models, it is also important to measure the impact of these models and ensure that they are achieving a business objective. The key change in this stage is the introduction of an Experimentation Platform where Data Scientists can allocate populations of users for the test and control groups of their experiments.

Once a user is part of an experiment they may experience a new behavior in the App or they may continue to see the baseline behavior if they are in the control group. Typically, the new behavior is used in conjunction with a predictive model, for example we might want to measure if an enticing offer can reduce churn among at-risk users. However, even simple things like design changes in the App can be part of an experiment. 

The existing events architecture has to be changed somewhat to account for this new stage. We need to tag every single event with the list of experiments that the user who triggered that event is a part of and whether they are in the control or test group for that experiment. The augmented events allow the real-time dashboarding service to measure the metrics for each experiment and estimate the lift that each experiment is causing in those metrics. Typically, the Data Scientist who creates an experiment will specify an objective metric that they are trying to improve, for example engagement with Feature X, as well as a guard-rail metric that can’t be allowed to worsen, for example churn.

![image](https://cdn.sanity.io/images/umrbtih2/production/bedc319dfe83814c5cf6bfda98475aad95314f7a-536x328.jpg?w=536)

Now, an experiment may fail to cause an improvement in which case if a guard-rail metric goes too low the experiment has to be rolled back. On the other hand, if a statistically significant improvement is observed in the metric, we may want to automatically deploy it to the entire population. In practice, most experiments fall somewhere in between. In other words, they don’t make things worse, but they don’t lead to a significant improvement. A good Experimentation Platform can also help identify how large a population of users is needed to get significant results, specifically if the expected improvement is vey small.

## Conclusion
In summary it is not enough to build models, we should be prepared to objectively evaluate each model and pass over any approach that fails to deliver clear value to our customers. The key is to have an architecture that allows for quick innovation. In this article I have avoided going into some of the trickier aspects such as online models that learn continuously or tenant-specific models for multi-tenant Apps. There can also be many other aspects of your App which might require tweaking to the above stages. However, one can always evaluate an AI architecture by measuring the three key things:
- How long does it take to build and evaluate a model on offline data?
- How long does it take to deploy a model to production?
- How long does it take to safely evaluate a model in production?

**Epilogue:** In case you were wondering what happened with the models that I deployed in the gaming company back in 2017. Well, I never quite built a model that created sales deals that generated more revenue than the baseline because the baseline were human operators who were very hard to beat! However, we soon realized that because these models could do as well as the humans, we didn’t need humans any more for sales, and we could use them to generate creative content in the game to increase engagement. This brings me to the final point: AI folks can build all manners of predictive models, but they can rarely predict what metric their work will actually impact.

7 stages of developing an AI architecture for Product-Led growth

I love meeting people, don’t get me wrong. Especially as things open up, I cherish every connection and conversation more than ever before. Simple things like meeting for coffee, taking a stroll, and a good old fashioned phone call are the highlights of my day. This article is not about these kinds of meetings. Rather, meetings that are useless, especially when they can be automated by machines. Join our mission to end useless meetings.

## Why developers hate meetings

In my previous company, we surveyed 100s of developers and I interviewed over 30 developers. What I learned is that developers don’t arbitrarily dislike all meetings. What they really dislike is inefficiencies, poorly planned and poorly executed meetings. Developers operate on a maker’s schedule, and need time units of 4 hours at a minimum for deep work. A single meeting at the wrong time can disrupt a whole afternoon, splitting their focus time into smaller units that are hardly enough to get set up and into the zone. Developers and makers need more focused time. And meetings are disruptive when developers want to get into the zone.

![image](https://cdn.sanity.io/images/umrbtih2/production/ad55b0f4705de9aa5a2963cc1903c38f6911a231-900x280.png?w=900)

This is the inherent tension between managers and developers. As Paul Graham notes, managers are on a different schedule. Managers get stuff done through meetings, but if they are powered with information and the ability to act, they will have less meetings too.
In recent years, organizations such as Facebook and Atlassian mandated “no meeting” days to address this problem. The intent being to increase productivity with “no meeting” days, traditionally a single day each week where meetings are banned. It allows space for people to focus on deep work tasks and also puts pressure on meetings the rest of the week to be more focused. In my experience, this comes at the cost of scheduling overflow and especially when team members are in time zones across the globe, it causes inconvenience and may sometimes stall the progress of the collective team.
You can also be maniacal with your calendar, blocking time and clustering meetings to maximize focused work and most importantly learning to say “no” to meetings when they are useless. Personally, I believe this has far better results, and drives a culture where people respect each other’s time.
In software development and the world of agile and scrum, there are many types of meetings. In a single sprint that spans 2 weeks on average, you have a sprint planning meeting, daily standup meeting, sprint review meeting, sprint retrospective meeting. Many of these meetings are “status” meetings. If everyone had the right information at hand, these meetings could virtually be non-existent. If everyone updated their Jira tickets, we would have what we need. Yet, why do we have so many status meetings?

## What hurts more, updating Jira or going to useless meetings

This brings us to the main point here, if everyone had the right information, they would meet far less. We could eliminate status meetings completely, if everyone knew what was going on, and how they needed to support each other to achieve team goals.
The problem with existing systems like Jira is that developers have to change context moving from one system like GitHub to another like Jira, and also who likes “work about work”? Shouldn’t we just focus on work, and not take any time away from meaningful work? Typical activities that take makers away from their skilled work -
- Gaining clarity and alignment
- Communicating about work
- Searching for information
- Switching apps
- Chasing status of work
Getting everyone aligned on the big picture is absolutely critical, as we describe here. It’s hard to stay motivated and produce valuable outcomes, if we don’t know how our work aligns with customer value and company goals. Once you are aligned with the “why” (the customer) and “what” (the product), we can leverage technology in such a way that it helps your work, eliminates meetings and gives you more time for focused work.

## Get real time updates through GitHub

Information should be available to all, and technology can one day eliminate many meetings and give valuable time back. Here are 6 ways technology and specifically GitHub data can stop the meeting madness:


## 1. Automatic status updates
Connect GitHub with your work management system, and ensure your work stays in sync between the two systems. Associate GitHub commits, branches and pull requests with issues and automatically update status of work so you never have to leave GitHub and your deep work time. Your team members have visibility of your code activity in the context of the assigned issue, without you having to slack them on a status update, or join a daily standup.

![image](https://cdn.sanity.io/images/umrbtih2/production/ec68b470b957c737c992e3904ab82b026ae6a8ad-1400x162.png?w=1400)

## 2. Jira tickets or it didn’t happen!
Don’t sweat tickets. If you choose to start coding and have never linked with a work ID, you shouldn’t have to sweat it. Machines should automatically create tickets that track all associated commits, branches and Pull Requests. Your work is always accounted for and more importantly your team members have visibility and know what you’ve been up to, resulting in fewer interruptions. Never create tickets, unless you really want to.

## 3. Let em know you are stuck
Code reviews can slow you down as a team, especially when there isn’t good code review hygiene such as raising huge pull requests and not doing self reviews. Code reviews require focused attention and time, and can also get lost in the reviewers inbox. When code reviews are stuck for more than a day, the system should nudge the reviewer. At the same time, the system can update the ticket on different stages of work, and how long code reviews are taking, ensuring everyone has visibility into where things are. This data can be aggregated to understand how to influence great code review practices, and improve the organization’s ability to ship faster.

## 4. Understand the codebase
Starting at a new company or a new team is overwhelming for most people. The codebase is new and the style of programming could be different than before, and software needs to be understood before developers can contribute. Instead of relying on documentation that can get stale quickly, or schedule a slew of meetings, technology should crawl your codebase and provide real time answers to questions such as, what are the microservices and components and how are they related to each other? What is the code, artifact and deployment related to each service? What are the core dependencies, and who are the people in the sphere of knowledge and influence?

![image](https://cdn.sanity.io/images/umrbtih2/production/32d6ce36d1afbb18cb2c62221226556c92cafcd6-7680x4320.png?w=7680)

## 5. How time is spent
If you know how you’re spending your time, you’ll know whether or not you’re on track to accomplishing a goal. This is a question that we must answer for an individual, a team and the organization as a whole. How many times have managers been asked, “what is your team working on”, “what is the organization’s investment allocation to different activities”, “what products and capabilities should we invest/divest in”. These are extremely important as companies scale, and existing systems should automatically generate this information from the source of truth, from its code activity in GitHub.

## 6. Help me Help you
When stakeholders have visibility into the right information, they have the ability to make tradeoffs and decisions. Product Managers, for example, want to help and it is difficult to do so when they are unaware of engineering measures and activities that developers are spending their time on. They should be empowered with information without requiring a meeting, or waiting till it’s too late risking customer and product. Imagine if systems can synthesize information around a development team’s activities, and empower stakeholders with the ability to understand the current state, weigh in on tradeoffs and help make quick decisions.

## Make a cultural shift
Meetings have earned a terrible reputation in the workplace, but meetings are not always useless. They should not be meant as a memo or just provide status updates though. Next time you have a meeting, ask yourself -
As a meeting creator
- What is the objective and desired outcome?
- Is this really a meeting? Or is this a memo or status update?
- Do we have the right information and people to achieve our desired outcome?

As a meeting attendee
- What value can I bring to this meeting?
- What happens if I don’t attend the meeting?
- What are other higher priority tasks that I should be spending time on?

## As a management team
- How can technology eliminate “memo” and “status” meetings?
- Do employees feel comfortable saying “no”?

## What are the best ways to connect, build relationships and celebrate?
Teams rely on meetings to coordinate work and people, and good meetings provide an opportunity for people to align thinking, socialize, enjoy each other’s company and express joy or frustration. For developers, meetings can help build relationships with support teams, customer success managers and product managers. So when something goes wrong in your production, this relationship helps you communicate better and resolve things faster. Meetings are also extremely useful for one-on-ones to foster relationships. However, technology when used properly can eliminate wastage and an abundance of meetings out there.
Not all meetings are bad, so let’s use them carefully — “Meetings should be like salt — a spice sprinkled carefully to enhance a dish,” says Basecamp founder and CEO, Jason Fried. “Too much salt destroys a dish. Too many meetings destroy morale and motivation.”

Six ways you can use GitHub data to stop the meeting madness

BusinessInsider

These founders tapped into their network from an Indian university with famous alums like Vinod Khosla to raise $50 million for their startup, DevRev

**Summary**: Consumer-grade experience is the future, regardless of the industry you may be in. It will be table stakes to customers, and how you align to high growth spaces as a business leader. After spending six months in a Product Led Growth (PLG) software startup I have learned to make the pivot and I offer a few learnings for others on a similar journey, (1) you just have to get started, (2) build a community to engage with and learn from, (3) “build or die” and (4) leverage PLG strategies and tools (not agencies) to create coordinated nudges and process across sales and marketing teams. 

**The power of Sales-Led Growth (SLG)**

After a two-decade career spanning retail, industrial, and healthcare businesses at a top US retailer and large multinational industrial company I pivoted. I walked away from what I know deeply about (traditional sales-led business) and dove right in, not just into software, but a product-led growth (PLG) software startup. Some people think I am crazy, but I am even more certain now that product-led is not just the future of SaaS it is the future of all business.

![image](https://cdn.sanity.io/images/umrbtih2/production/665080246b2f36a662b2fb704a84cd00689c1862-3376x4220.jpg?w=3376)

Lately, all you hear about in Corporate America is ‘transformation’. Every company has realized data is king, and the winners of the next decade in business will be those that build a consumer-grade experience, no matter what business model or industry they are in. Jeff Lawson sums this up in his book Ask Your Developer when he asserts “every industry is becoming a software industry…because there is a Darwinian evolution playing out… ‘Build vs. Die.’”1 The criticality of this is you have to build your customer-facing infrastructure in a way that allows you to know them deeply and at scale. 

The autonomy and knowledge of front-line sales has long been the bellwether and true north for a company. This was valuable because they had the greatest amount of signal from the market and customers. However, since this was not data-driven those that could bang the table loudest steered the ship. Additionally, trying to implement anything without the attention and 100% buy-in of this group proved to be fruitless. The next era of product-led will end this battle between sales & marketing to make better business decisions, as Jeff Hardison from Calendly recommends in his recent article, “1. Don’t fight each other and 2. Don’t fight the data religion”.2

![image](https://cdn.sanity.io/images/umrbtih2/production/afe15bba1574b6a75765a3ac257e48aa5fd7651c-6000x4000.jpg?w=6000)

**Leading the pivot**

Transformation sounds easy. So why does it fail so often or only take a company so far? I have watched two Fortune 100 companies from up close miss the pivot. First in the 2000s when larger retailers failed to recognize the threat online commerce was posing while their own employees’ behavior had completely shifted. Then again in the 2010s when B2B failed to see preferences lean toward consumer-grade experience vs. the “old pal” sales relationship.

If you live in a world where your only signal from the market is the voice of sales and NPS, it's time for a reckoning. How will you see around the corner and plan a winning strategy for your business?


If you don’t acknowledge that no matter what industry you are in, your customers already expect more than what you are delivering, then you have missed the pivot.


Every company should be singularly focused on how to deliver a more consumer-grade experience. This is how you align to a high-growth market space and win. If brick-and-mortar retail would have thought this way sooner, they would not have invested billions into stores vs transforming their eCommerce presence. If large multinationals would have thought this way sooner, they would not still allocate the majority of marketing spend on traditional marketing.

Product-led can work in traditional companies too. Who has tried Miro, Figma, Canva, or Slack in the past year? If you have, then you’ve experienced how pervasive product-led is and how it spans all industries and business models. The question for anyone shouldn’t be when to transition from SLG to PLG, the question should be how to do it faster.

![image](https://cdn.sanity.io/images/umrbtih2/production/ca991fe19445d8a0bcf2a7f874a843eefdc24eba-2706x1394.png?w=2706)

**The power of PLG (our learnings so far…)**

To be consumer-grade, you have to meet customers where they are, aka the watering holes, and ensure your customers can find you when and where they go looking. I saw this in action while living and working in China where the lines between B2B and consumer-grade were already blurring years ago. Companies had been built into empires positioned purely to help traditional B2B companies make this shift. The business model was to work directly with large online commerce platforms and establish branded and B2B ‘shops’.

You don’t have to pay an agency to do this for you. Before pivoting myself, I spent almost a full year and over $1M working with an agency to build a more consumer-grade experience for our customers. Since coming to DevRev I have seen how you can build your own consumer-grade experience by working with your Dev team and leveraging other PLG solutions much more efficiently.

If I were assembling a playbook on this pivot and finding product market fit, here’s what I’d tell you to do:

1. Figure out where your customers are and meet them there by setting up a community…it is never too early or late to do this. Canva has done this brilliantly as outlined in this article3. At DevRev, before we ever launched a beta product we had 2,000+ community members ready and waiting.
2. Learn (get more data!) about your potential and existing customers by engaging with them… at DevRev we asked our community about their use of Development tools and pain points. This helped us roadmap our product and prioritize our prospect pipeline.
3. Build a place where your customers can engage…direct them where to find out more about what you are offering and keep it simple! The hierarchy of your product(s) can develop and evolve. Users should be able to try your product, without talking to anyone, at a minimum give them a chance everywhere you can for a customer to express interest. Any company can make sure there is always a call to action!
4. Leverage coordinated nudges…market studies and cold calling are a thing of the past. Instead coordinate nudges from your community, application, and customer success / customer service / sales teams — this gives you more data! about the user and their behavior vs acting on stale 3rd party information. 
5. Become an ‘automation freak’…this term was used by one of my favorite PLG prospects I have met thus far, and it is a mantra we live by at DevRev. It means, figure out what can be automated from data collection to nudges to Slack notifications and more. It ensures you know when an important event occurs and should tie back to a success metric. 

The pivot doesn’t have to be complex, if there is one thing I have learned in my transition it's that sometimes you just need to start to get started. It doesn’t have to be planned and structured, just get the inertia going. It won’t be perfect, but you will keep the customer at the center by asking yourself: what would you expect as a consumer of your product, how do YOU search, learn and buy?

The more you build a presence for people to find and engage with the more data you will have and the more you will learn. As you do this your front line will pivot from the loudest people to your product. Having your product and data as your front line will allow you to move from wanting to being PLG through a data-driven approach.

Truly being able to pivot will also require a tight connection between your teams, and a collaborative vs. combative approach. Tethering your growth (marketing) and customer-facing (sales and customer support/service) teams together to do this successfully is the only way to build an efficient and scalable product-led growth company.
 
 

**Bio**:

Mollie Holland is currently responsible for Revenue at DevRev, a software platform that connects makers to customers. Before DevRev she worked at 3M, a Fortune 100 company with $35B in revenue and 95,000 employees worldwide. During her time at 3M, she held various global leadership roles including responsibility for corporate transformation initiatives, global business strategy, management and marketing of categories over $5B in revenue.

Mollie has also worked at Target Corporation, also a Fortune 100 company and the 2nd largest retailer in the US in Merchandising and Account Management at a Marketing & Advertising agency in Minneapolis. Her educational background includes an MBA from the Carlson School of Management and a BA in Political Science from the University of Wisconsin-Madison.

[https://www.linkedin.com/in/mollie-holland/
](https://www.linkedin.com/in/mollie-holland/)

**References**: 
1Lawson, Jeff. Ask Your Developer, Harper Collins 2021

2DeWitt, Zachary. “Notorious PLG 6.22.22: PLG + Sales Need to Hug It Out.”, Notorious PLG Newsletter, 22 June 2022, https://notoriousplg.substack.com/p/notorious-plg-61522-plg-sales-need?utm_source=email. 

3de Maine, Bridget. “How to Build a Community for Your Business - Learn.” Canva, https://www.canva.com/learn/building-community-and-business/.

Product-led growth isn’t just for SaaS: how I pivoted from an SLG career to the world of PLG

Entrepreneur's Handbook

Why DevRev will become a super unicorn

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. 

![image](https://cdn.sanity.io/images/umrbtih2/production/e84824483ff38997f2e9916f1f156a5af6146e52-623x240.png?w=623)

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.

![image](https://cdn.sanity.io/images/umrbtih2/production/92fe6ea20e6563dbe7005612cddb208966a8dc0e-577x432.jpg?w=577)

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. 

![image](https://cdn.sanity.io/images/umrbtih2/production/dcbb37baebfc59fee8bd81f2042ce68ae366cbec-525x475.jpg?w=525)

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.


A technocrat's journey: Email, Jira, Slack, and the road ahead

With my recent career change  —  now going 0→1 at DevRev  —  I’ve taken to writing more and more for its cathartic value, a way to express my journey and reaffirm my commitment to DevRev’s mission. Given that DevRev is a seed-stage startup spread across three continents, it has also proven to be an invaluable tool as we design and launch the world’s first Dev CRM. Today, we celebrate Writer’s Day at DevRev, and I’d like to point out three ways writing has served as a critical building tool in my daily work.

## Building consensus
Writing is critical to sharing knowledge and bringing everyone into our processes and decision making; it serves as a great equalizer, making your hard work accessible to team members in all time zones.

Whether it’s a meeting, a Slack thread, or a design doc with comments, forward progress relies on consensus around the ground facts. Between the folks who hardly care, the folks who have it figured out in their head, and those who aren’t ready to raise their hand, there’s a lot of reasons why discussions wrap up without clarity. Oftentimes, the end result is lower engagement: folks question why they’re pulled into meetings, or discussion threads go dark.

But by writing down key points, I’ve found that it helps frame the discussion and establish key checkpoints while the discussion unfolds. 

In more dynamic environments, this is necessary to create context and help drive maximum engagement. While we might imagine coworkers huddled together near a whiteboard, seeking experience asynchronously by perusing the team’s written documentation can be equally effective. 

Furthermore, it makes your expertise and experience available anytime, to anyone. It’s not a perfect substitute for that serendipitous hallway meeting, but it beats waiting for the stars to align and all parties to be available in person.

## Building understanding
Remote work can lead to fewer opportunities to build understanding. Perhaps even more dangerous is that it allows for misunderstandings to fester, often fracturing an otherwise productive engineering culture. 

The written word can often be that companion in an otherwise empty room, championing the cause and allowing the mind to return to neutral ground  —  a place where team members can realign and move forward together. 

The written word matches your work hours, in your local timezone, present when you’re ready and willing to consume it. And with understanding comes trust, allowing for even greater achievements to manifest remotely. 

Some more points to consider here:

- Effective written communication allows others to know you, and vice versa
- Going through the rigor of writing down thoughts can help bring clarity to our ideas
- For almost any decision, there are many relevant considerations. Allowing others to contribute to our written thoughts can help distill big decisions down to their determinative factors and guide the way forward

## Building momentum
Perhaps the most interesting aspect of writing is how it can capture the zeitgeist and symbolize closure. As you hit each milestone checkpoint, you guarantee yourself at least some forward momentum. Writing helps preserve your hard work and directs future efforts.

Personally, I’ve found great success in articulating milestones and early wins through writing; this facilitates celebration and brings teams together. In a remote environment, team identity can be vague and fragile  —  your shared wins, expressed in writing, can help solidify what it means to be a single unit. 

Writing is also an incredible force multiplier:

- Be thoughtful about what written resources are available for talent onboarding
- Ensure that brown bags, tech talks, and design reviews have associated written documentation and/or recordings for the benefits of the broader audience, both present and future
- Ask others to contribute back to the document to reinforce their understanding & keep the flywheel in motion

## Sustaining a culture of writing
Writing can be hard; it can be seen as one more step, an orthogonal skill, perhaps. To counter this inertia, we need to be intentional:

- Make written documentation a specific part of your inclusion efforts
- Be clear about where written content exists, how it can be found, etc.
- Connect it to your team’s practices

As a final note, being intentional about communicating through writing is a major step towards making our communication more inclusive and effective overall. However, it demands a generative culture where individuals are willing to self-organize to do the hard work in a scalable way. Some things to consider in this regard:

- Is writing (design docs, readouts, playbooks, etc.) a part of your team’s workflow?
- Does written communication play an integral part in how team members learn & engage? Is it shared cross-functionally?
- Is this practice celebrated and/or rewarded?
- Are peers incentivized to read and contribute to each other’s writing?
- Are counterforces preventing team members from actively writing?


The pleasure of writing

Starting a new venture in a sea of competitors is difficult. Every choice and decision is daunting.

Take marketing, for example. You have to decide what channels to use at the start and allocate budgets for each one. Next, you have to determine which leads to pursue and which to cut off. 

Imagine adding this kind of guesswork in building a product. But wait, that's exactly what most companies do. They let their sales teams determine the product based on how easy it is to sell. 

This archaic model worked when sales created the tightest feedback loop with the customer.  The product would ship in six months to yearly cycles, and by the time customer feedback was received, a feature freeze was already in place for the next release.

But that's not the case anymore. Now usage data, continuous release cycles, and freemium offerings mean customer feedback is constantly guiding product priorities on a near-hourly basis.

Today, startups need to cater to their users if they want to survive. Startups must embody the principle of product-led growth to prosper.

## What is Product-Led Growth

A Product-led growth strategy is the favorite method of marketing for new-age startups. Unlike sales-led techniques, PLG uses the product to acquire users. 

The product drives revenue, leads, engagement, and marketing. Because of so much emphasis on the product, companies ensure that it is up to the mark. 

One of the by-products of product-led growth is that companies become customer-centric. The only valid metric for a good product is customer satisfaction. That means you need happy customers. 
PLG companies take out time to listen to users and take feedback using [platforms such as DevRev](https://devrev.ai/devcrm). Developers then make required changes to benefit the user. 

It is hard for most companies to resist the urge to release features that their competitors offer. PLG companies, on the other hand, prioritize features that users want and request. 

That's why PLG companies stand out from the crowd. 

## Benefits Of Product-Led Growth

In the previous section, I talked about how PLG makes companies customer-centric and increases customer satisfaction. While that benefit alone offers immense value, there are a few more noteworthy ones. 

Growth without dependency. Product-led companies can operate at much higher margins as they can allocate resources back into the product instead of chasing leads. 

The best part is that there are no barriers to try out the product. Users get started in minutes through an intuitive experience that gradually adds more functionality and complexity. 

This is possible because product-led companies make use of freemium pricing models. You can access most of the features at no cost, like in Figma. Power users who require more features can opt for paid plans to meet their requirements. 

Thanks to free trials, users can try out the product. Once they like the product, they share it with their friends and family, which works as a form of word-of-mouth marketing. 

Every happy customer of your product acts as a salesperson allowing product-led companies to grow exponentially.

## Product-Led Growth: A Look Back

We have entered a new era of technology. Software is not just a tool anymore but a part of life. People find the best software and apps to make their lives better. Or you could say that we have entered the Age of Connected Work. 

It's important to note that this wasn't always the case. Software didn't have mass adoption before. This was largely due to a steep learning curve and high prices. Software wasn’t made to help the mass end user with productivity. Instead, it was built for executives to manage their employees better. 

Today, everyone has access to the best software thanks to product-led companies. You might be wondering how we got here. To explain this shift, I will break down the past few decades into different technological periods. 

### 1980s — 1990s: The On-Premise Era

Software in this period had to be installed from a physical box. These software programs were both expensive to build and buy.  Software was only sold to enterprises. Salespeople would try to convince CIOs of companies to buy their software. 

### The 2000s: The Cloud

In the 2000s, development costs became lesser. Companies such as Salesforce were driving software into the cloud. Sales teams used marketing-led sales tactics to sell software to non-tech execs. These execs cared about improving team productivity and getting a good investment return. 

### The 2010s: Software to All

During this period, everyone could access the best software thanks to affordability. Small business owners and individuals started using software that previously would be commercial grade. 

Developers did not have to create software from scratch. The infrastructure was better and more scalable. 

In 2016, [Blake Bartlett coined the term Product-led growth](https://dot.la/blake-bartlett-openview-venture-capital-2658161133.html) for companies that followed certain principles. We will discuss these principles in a later section. 

### The 2020s: Connectivity and Collaboration

In the current era, we have access to so many apps and software. We use Notion, Grammarly, Zapier, Jira, DevRev, and Github daily. 
Redundant tasks are all automated. That allows us to increase productivity and focus on important work. 

Companies are using product-led growth principles to leverage their product for exponential growth. 

Businesses now rely on software to carry out most tasks. It helped them operate efficiently during the pandemic when remote work was the norm. Slack, Zoom, and Teams helped colleagues feel connected while being physically distant.

## How a Company can become Product-Led

If you've been reading till now, you are probably convinced that product-led is an important factor for a company's success. 
Changing your company's approach from sales-led to product-led is difficult but not impossible. 

It starts with carrying out the following steps:-

### Create a Product-Led Growth Team

A sudden shift to a product-led approach can shock everyone in the company. It's important to help everyone acclimate to this cultural shift. Assembling a product-led team of the most dedicated members is a great way to start. 

The product-led team can strategize and create a plan to move forward. This plan will include changes to recruiting, customer interaction, features, and flexibility. 

### Understand the User Better

The user's happiness is crucial for product-led growth. User research is the best way to understand your users and their pain points. 

User research helps you understand what problem you can solve and how to offer value. You can also think of it as finding product market fit. 

User research's pleasant side effect is a smooth user experience. That's because you take time to interact with users using tools like DevRev to understand their problems. 

You can also distinguish your users by segmenting them into active, new, inactive, and churned users. You can set up calls with these users and get feedback. Prioritize the users who stop using the product the highest. 

### Small Incremental Changes to the Product

To become product-led, companies must build on the user's requirements. Flashy features with no benefit should be avoided. Only features that users need should be implemented. 

You can let a certain subset of your active groups try out your beta product whenever a feature is added. This will help your company get relevant feedback and make changes. It will also help the company to build incrementally instead of dumping a bunch of features after a year. 

### Build in Public

A company that has shifted to product-led will have to release features and get feedback early. Your users become your stakeholders and will know what happens behind the scenes. 

Users feel more connected with the founders and the company when they hear about daily wins and hardships. 

### Scale

Once you are done with the previous steps, all that is left is to scale the product. That means you must now look at the global audience. 
You will need to optimize pricing, automate the business, and use an omnichannel support system. 

You will also have to hire more people, especially in leadership roles.

## How to Measure Product-Led Growth

Product-led growth might seem very vague. You might say that everyone follows PLG. 

That's because PLG is measured on a scale. Different companies will use a different number of PLG principles. 

You can measure the extent of PLG principles used in a company with the following metrics. 

### Time to Value

This metric measures the time it takes a user who has landed on your product to a new user. 

PLG companies should strive to reduce this time. This means making the onboarding process very easy for better conversion. 

### Net Churn

This metric is used to determine the health of a company. It measures the money lost after accounting for new or expansion revenue. 

### Virality

Virality measures a product's adoption rate with each additional user. 

k = the number of invitations sent by each customer * the % conversion rate of each invite

When k is greater than 1, the product can grow exponentially with virality. 

### Customer Lifetime Value

This measures the revenue a company can expect from a single user throughout the user's lifetime. You get enhanced statistics when you use this metric on the user segments we discussed earlier. 

This metric helps you predict how much a customer is worth now and in the future. Based on this information, you can change your pricing and customer strategies. 

### Revenue per User

This is the average revenue from a user. It is calculated by dividing monthly recurring revenue by the total number of customers. It is used to determine the health of a company and its potential. 

### Expansion Revenue

Expansion revenue is generated from extra features, packs, and add-ons. 

Expansion revenue is an indicator of the loyalty of your users. Companies should focus on increasing their expansion revenue. It is cheaper and easier to sell to existing users. This will also improve the total revenue significantly. 

## The 3 Pillars of Product-Led Growth

Unlike sales-led growth, product-led growth uses the product to drive sales and revenue. PLG is defined by three pillars. 

### 1. Design for the End User

The users' needs must be put before everything else. Have you noticed that the UI of Amazon hasn't changed much in so many years? Some people might even call it an old design. But they do this on purpose to not confuse their older customers. 

If users don't like the design, they might get fed up and move to a competitor. End users are in the driver's seat of the product. Their happiness is paramount. 

### 2. Provide Value First

PLG companies release products fast to understand the market and users. They release an MVP with all the basic but groundbreaking features. Users can give feedback fast, which helps improve the product. 

PLG companies let users try out products for free using the freemium model. They provide a great app at no cost. They only hope that the user continues to use the product and upgrades the plan in the future. 

### 3. Use Market Data To Gain an Advantage

Product-led companies use the product as the primary driver for sales, acquisition, and expansion. That’s why collecting data about how users react to the product is important. This data is analyzed and used to improve customer satisfaction which results in more growth and revenue. This revenue can then be invested back into the product creating a flywheel of growth. 

The company's PLG team is responsible for analyzing data from different sources and using it to accelerate growth and find product market fit.

Why Product-led Growth Is Superior To The Traditional Sales-led Growth?

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. 
1. A product-led company has **automation** drive most, if not all, of the processes across the company. 
2. 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. 
3. 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.
4. 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. 
5. 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**:
1. 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.   
2. 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. 
3. 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.](https://youtu.be/45qhEdiwFZs)

## 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**:
1. 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.
2. 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. 
3. 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](https://vimeo.com/720338956)

**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](https://devrev.ai/landing/beta) and try out these use cases on your own.

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

If there’s one thing that decides brand success, it's customer perception. Customers today are looking to make more informed purchase decisions while being open to exploring alternatives, breaking inherent dissonance, and adopting new ideas. This often involves searching for very specific information. 

But finding the information isn’t as straightforward as it seems.

With most industries being crowded and competition at an all-time high, customers are often barraged with information they don’t need and seldom recall. And this is where chatbots come into the picture. 

## What is a chatbot?

At its most basic form, a chatbot is a computer program that mimics human interactions, automates responses based on specific query types, and redirects conversations to achieve successful escalation or resolution. 

Chat bots leverage AI and Natural Language Processing (NLP) to understand human language and carry out appropriate actions without the need for human intervention. Needless to say, customers are able to obtain specific information without having to spend a lot of time searching.

## A brief history of chatbots

Chatbots have reached a high level of maturity, especially over the last few years. But they weren’t always as sophisticated. Chatbots were a result of years of experimentation on bridging the gap between humans and computers. In fact, the first ever chatbot, Eliza was created even before the advent of the personal computer.

### Early models (Mid-60s to Late 90s):

Some of the first chatbots ever created such as Eliza, Parry, or Alice were designed to simulate human conversation. And to a certain degree they were able to generate responses based on specific input. But while these chatbots were groundbreaking at that time, they failed the Turing test, a test that establishes independent thought and intelligence. 

### The age of the internet (Late 90s to Early 2000s):

The advent of the internet age pushed development into a new phase of thinking. In the early 2000s, SmarterChild, the brainchild of ActiveBuddy Inc., was made available on AOL and MSN instant messenger. SmarterChild garnered a lot of attention with over a billion messages exchanged a day and over 10 million users at its heyday. It was also widely considered a predecessor to one of the most well known virtual assistants, Siri.

### The smartphone age (Early 2010s to present):

With breakthroughs in smartphone technology came the development of the virtual assistant. These chatbots could do a lot more than just respond intelligently—they could understand human language better through AI, NLP, and ML, perform smart actions, and have stimulating conversations. Siri, Google Assistant, Cortana, and Alexa are a few examples of the newer, more improved virtual assistants.

It’s also worth mentioning that with the recent development of ChatGPT, we’re ushering in an era in which the text generated by Chatbots are becoming indistinguishable from human speech. Exciting times, indeed!

## The two cornerstones of chatbots

Chatbots fulfill a simple function but their effectiveness is intertwined with two functional driving components—AI and data. These cornerstone principles go hand-in-hand and influence complexity and accuracy. 

### AI:
This component is primarily responsible for decision making and execution. While AI breezes through simple task automation, it may struggle with complexity. Whether that’s down to mistranslations or handling requests beyond scope, developers can overcome these obstacles by programming smart prompts that reassign the conversation to a human agent whenever necessary.

### Data: 

Data is a vital component that impacts the accuracy of output. Chatbots are heavily data reliant and the accuracy of the data built into it. The more accurate the data fed into the chatbot is, the more accurate the results. Accuracy also hingest on the chatbots’s ability to interpret the data. And so if the training module isn’t built in a satisfactory manner, it could cause malfunctions, or end up being unpredictable.

## Types of chatbots

Chatbots have innumerable use cases. Whether it’s to help IT streamline processes, help customers find a particular piece of information, or to execute routing tasks, chatbots are commonly built in three forms:

### Prompt-based chatbots

These chatbots function within the confines of a particular script, logic tree, or set of rules. The user’s input often dictates the direction of the conversation which is highly predictable. This also means that the chatbot can only respond in a set number of ways. Prompt-based chatbots are not meant to handle extreme complexity. 

### Data-driven

Data-driven chatbots are advanced programs that are context-aware and are able to execute a sophisticated variety of functions. Unlike prompt-based chatbots, data-driven chatbots have a higher understanding of data functionality and are able to use predictive analytics, machine learning, and user preferences to provide more intuitive conversation.

### AI-based chatbots

AI-based chatbots have an added layer of sophistication. They are able to process natural language, derive context, and make smart suggestions based on user intent. Additionally, they allow users to guide the conversation any way they want. What makes them unique is their ability to gather conversational data over time and create smarter responses.

## Chatbots vs Conversational AI vs Virtual Assistants: The difference

There are a lot of terms that get thrown around in this space and it’s easy to mistake one for the other. While chatbots, conversational AIs, and virtual assistants all fall within the realm of chatbots and are loosely based on the same concepts, it’s important to know that they are not exactly the same thing. The table below gives you an overview of the differences that make them unique.

## The inner workings of chatbots

Behind every chatbot is an architecture that does three very specific tasks:

### Recognizing intent

Intent recognition is the first step that chatbots carry out. The Natural Language Processing engine recognizes conceptual entities (keywords, concepts, language, etc) and numerical expressions (numerical data, dates, times, etc) within input. It then interprets this data to understand the intent of the user and the nature of the task at hand. 
 
### Mapping intent to action

Once the intent of the user is established, the chatbot needs to recognize the appropriate action that needs to be carried out. The more data fed into the chatbot, the more accurate the interpretation and mapping tends to be. 
 
### Response delivery

The third and final step is the execution of response. This may be in the form of a simple text response, starting a logic tree conversation, extracting data from a knowledge base, a response based on backend interactions, or specific redirection.

## Elevating the customer experience with chatbots

Chatbots come with a host of advantages. Forward thinking brands deploy chatbots to complement brand image and curate personalized experiences.

### Improved productivity

Chatbots are great multitaskers—they can engage multiple users at once and can be instrumental in reducing customer wait times, optimizing your support channel, and driving better engagement.

### Initiating conversations

Chatbots are a great way to start conversations with prospects visiting your website. Whether it’s pointing users in the right direction or answering queries, chatbots can help create positive first impressions while greatly simplifying navigation.

### Personalization

Chatbots are highly customizable. This means that different scenarios can trigger varied responses. For instance, the chatbot can be trained to greet returning customers in a personalized manner or point them in the direction of high value content that helps accelerate deal closure.

### Smarter conversations

Stimulating conversations are great but the ability to anticipate needs takes the customer experience to the next level. Chatbots are able to harness customer/visitor intelligence to learn preferences over time and have smarter conversations that are driven by intent. 

### Accurate qualifications

There have been numerous instances where marketing and sales teams spend a lot of time with prospects only to find they aren’t a great fit. Chatbots can be incredibly helpful in posing qualifying questions and carrying out lead qualification even before your sales teams set up meetings.  

### Intelligent routing

Chatbots are great at fulfilling predictable queries but they don’t always have a solution. And this is why they can be trained to consult, or reassign complex tasks to a live agent. This translates to faster resolution and higher customer satisfaction. 

### Proactive customer interactions

The importance of capturing customers with high intent cannot be understated. Chatbots can be programmed to notify live agents when high value customers visit your site. This allows them to proactively start conversations with prospects and leverage their intent. 

### Data efficiency

Chatbots generate a goldmine of customer data. This data can come from two avenues—preferencial data from repeated customer interactions and feedback that customers provide at the end of the conversation. Analyzing this data helps brands optimize customer touch points, tweak their website experience, trigger actions based on identified purchase patterns, and remove potential roadblocks to the buying process.

## Challenges in implementing chatbots

Like every new technology, using chatbots comes with a few imperfections of its own. Here are a few obstacles that organizations need to be aware of while implementing chatbots in their CX strategy.

### Adoption

Even though chatbots have been around a long time, integrating them within the CX experience can come at a certain risk. Chatbots using AI and natural language processing require time to learn from typical customer interactions. Visitors may not necessarily understand this since they’re often focused on their objectives. So a faulty experience may put them off, resulting in a loss of potential business.

### Security

Security is a big talking point when it comes to customer data. Naturally, first-time visitors are not always comfortable sharing personal information without the knowledge that it will be handled safely. This can raise concerns and cause visitors to hesitate and possibly turn away.

### Language and dialect

Human language is a fluid concept and humans communicate in multiple ways. Dialect and phraseology are variables that can pose significant challenges while recognizing intent. Misspelling words and typos can also trip chatbots up. And unfortunately, Natural Language Processing has a long way to go to find a solution to this problem. 

### Unpredictability

Human nature is very unpredictable. Thoughts aren’t linear and sometimes emotions trump rationale. Chatbots, on the other hand, are found lacking in this respect and cannot quickly adjust to the unpredictability of human command and emotion. 

### Apprehension

The modern customer craves a warm, personalized touch point. They expect stimulating conversations that are purposeful and pointed. Chatbots are unemotional by nature (obviously) and hence, the lack of emotion results in a natural apprehension to engage. This also means organizations looking to implement a chatbot experience have to constantly monitor, train, and update the program to behave more human-like.

### Common chatbot use cases   

Chatbots have a number of conventional and unconventional use cases. They can fulfill a number of roles across departments and functions owing to the dynamic ways they can be molded. With that in mind, here are a few ways in which chatbots can be leveraged.

- Business process and task automation
- Meeting and appointment scheduling
- Customer support and helpdesk
- Gamification
- Data monitoring and reporting
- Employee engagement and payroll management
- Website engagement and query resolution
- Prospecting and lead qualification
- Claims processing
- Healthcare advisory and information
- SaaS self help and deployment
- Retail order placement and returns

## Four crucial tips to picking the right chatbot

Irrespective of the use case, the right chatbot does more than just disseminate information; it drives conversations and is constantly evolving. Picking the right chatbot for your business may seem straightforward but there are nuances that have to be tackled. 

### Map the exercise to a defined goal

Implementing chatbots is not exactly a cheap affair. And so it’s really important to carefully align them to a singular business objective. Whether that is to improve website engagement, better prospecting or handle a large volume of customer support tickets, it’s vital that business units are able to see how chatbots address a problem and understand the value chatbots bring to the table.

### Always consider the security angle

Irrespective of how secure a platform is, there are vulnerabilities that don’t immediately meet the eye. Chatbots are no different. When it comes to customer information, it’s important to ensure it is handled, stored, accessed, and purged correctly. Choosing a solution that aligns with the latest security and compliance regulations can go a long way in putting customers at ease while sharing their information.

### Implement to improve existing processes

There is a perceived notion that newer technologies will end up replacing older ones that may just be working well. But this doesn’t have to be the case. While choosing a chatbot, consider how they can help improve processes and expand capabilities over time rather than step over and replace existing processes. 

### Leverage data

Data plays a big part in how efficient chatbots are. It’s essential to choose a solution that not only generates the right kind of data but is able to interpret, harness, and learn from it. It’s also vital to consider the effort that needs to be put in to feed, maintain, and fine-tune the program to get smarter with time.

## Final thoughts

Mark Hurd, the CEO of Oracle predicted that by the year 2025, roughly 85% of customer interactions will be automated. This only points towards the fact that chatbots aren’t going anywhere. In fact, the evolution of technology will only give rise to a smarter, more engaging chatbot experience. Not only will the chatbot predictably automate a significant number of processes but will create new avenues of work and change the way we view the world today. 
 

The Complete Guide To Chatbots And How They Elevate Your CX

SDX Central

Former Nutanix CEO Dheeraj Pandey scorches $50M DevRev launch

I am into my second month as an entrepreneur building a startup with my awesome co-founder. It’s early days, but it has been quite a ride learning and building the company one brick at a time. As we think about solving any hard problems and making it serendipitous for the users, it always comes down to making it consumable with easy discoverability first. For example, one of the problems we noticed very early on: how to make information easily available to everyone, both current and future colleagues.

In the beginning, it was pretty easy for two of us to create and share information. But as we’ve started adding more people and creating more information, the difficulties have multiplied.

![image](https://cdn.sanity.io/images/umrbtih2/production/bdbaf46b1b66fa11eb92693b442f03e5c07ad82d-1400x777.png?w=1400)

And it’s not getting easier. Every new person has an increasingly tough time finding the right information. Documents, messages, texts and other information is usually shared in various forums — internal wiki, Slack, Google Docs, Email, tech talks, presentations, various meetings, etc. Documents get created based on certain discussions, which leads to more discussions and more new documents. Anybody who hasn’t been part of all the discussions faces daunting challenges when they need to find and consume the right documents.

A lot of organizations often solve this problem for their external customers by creating a dedicated technical publication department. But what about their internal stakeholders? Why not do the same for them?

As we’ve pondered how to untangle this challenge, I’ve found myself looking back to my formative years in a small village in rural India, some 30-plus years ago.

![image](https://cdn.sanity.io/images/umrbtih2/production/64a4e6c0922cdab1f58fb0384c9a5b8a93a1ef3e-478x1000.png?w=478)

I was an eighth-grader who wanted to read more books, but I didn’t have any money to buy or rent them. I wondered: Could I have a library and become a librarian?

So, I went around to my neighbors and asked them if they had any spare books they’d like to donate to a library I was starting. It wasn’t much, just one open-air room available for a couple of hours a day. Still, I had to gather, organize, curate, and update large volumes of knowledge.

I can’t stop thinking about that microcosm of a library as we build our new company. Every day, more than a dozen of us share ideas and suggest strategies. One collaborator writes up a list of policies in a text document. Another colleague crunches data in a spreadsheet. Then there are the email chains, Google docs, slide decks and Slack chats.

*We’ve come to realize we need a simple, seamless way to handle all this information — to access it, to prioritize it, to organize it, to publish it, to archive it and to make it easy to discover for all the stakeholders.

That is, we need the skill of a librarian. Don’t they also do the same thing?*

**Celebrating the unique skills of Librarians**
Professional librarians have more duties than I can possibly list here, but their primary responsibility is to curate information — deciding what belongs in the library and making it easy for people to find it. Librarians don’t put every book ever published in the library. They make judgement calls about the best books for their users.

![image](https://cdn.sanity.io/images/umrbtih2/production/83b34265cfc8a939051d047f4dc855ae7d6927df-1064x1500.png?w=1064)

Librarians also organize information, using card catalogs and systems like Dewey Decimals and the Library of Congress to guide people to the content they want. Obsolete books go to an archive while newer, more relevant books remain on the shelves.

Why can’t the information we use every day be organized like a library?

I think it can be. Indeed, I suspect it will become mandatory as technologies become more complex, organizations become more global, and employees become more remote from their home offices.

**How would we create a business Library? Start with empathy**
I remember once at a previous job when I needed to see the company’s vision and mission statement. For some reason, tracking down the correct information was an exercise in frustration. A well-thought-out library of business information would’ve solved this problem in a few seconds.

![image](https://cdn.sanity.io/images/umrbtih2/production/71932308dc9edf57c7caa626d15f414cd9a75753-1400x1100.png?w=1400)

OK, so we all need librarians and libraries. That’s obvious. But how should businesses — and especially startups — make this happen? How do we make sure everybody gets what they need, when they need it, without friction or frustration?

As I wrote in a previous LinkedIn article, [we have to start with empathy](https://www.linkedin.com/pulse/closing-empathy-gap-bedrock-building-awesome-product-manoj-agarwal/): taking time to understand the needs and expectations of everybody who consumes information. I like to think of empathy as my North Star, the founding principle that guides the building of my business.
My empathy-driven library would have four core qualities.
<ul>
<li>Curation. Library operations would be prioritized to ensure that users get the quickest access to the most important information without digging through a pile of irrelevant content.
<li>Classification. Content would be indexed and separated into easily recognized categories and subcategories to help people browse for similar information.
<li>Timeliness. The newest information would be the easiest to find, through previous versions or iterations would also be readily available.
<li>Personalization. The library would recognize the user and reorient itself in real time to anticipate each user’s individual needs, fetching the information they need quickly and efficiently.
</ul>
*Ideally, we would apply machine learning to automate and optimize many of these functions over time. Until then, we can start with a human librarian to truly understand the everyday demands of our people.*

**Celebrating our inner Librarian**
When I started my volunteer library back in my home village, I soon realized books had to be organized — by topic, by title, by author. I had to be able to curate the collection, make recommendations and help readers find books that might interest them.

I moved away after a couple of years for higher studies, ending my foray into library science. But all these decades later, I can’t help thinking how people inside our new company amass enough knowledge to fill a library — but we never seem to have a librarian around when we need one.

We would like to do something about that.

![image](https://cdn.sanity.io/images/umrbtih2/production/d0f00f86989046f261b4870beeaddbd4468f7323-1400x932.png?w=1400)

As we build our startup, we’ll be thinking a lot about how to organize information and make it easy to build upon existing knowledge. Can we use machine learning to bring additional serendipity to users? Sure, over time. But we must solve for easy discoverability of information first. We’ll build on a foundation of empathy, applying human skills to solve real people’s problems.

Part of me will always be that 12-year-old boy hungry for knowledge in a village hundreds of miles from the nearest metropolis.

*What I learned back then remains true to this day: knowledge has to be organized and optimized to serve people’s needs.*

And here I am — looking for a modern librarian who will have deep empathy and curiosity to curate documents, organize information, make knowledge discoverable, and bring joy to all stakeholders with elegant design, near real-time updates, and serendipity on a daily basis! [Notion](http://www.notion.so/) has made it very easy to create and update information, but making it discoverable and serendipitous is a whole new world.

Do you know of someone, perhaps a technical program manager, who will bring their childhood librarian out?

First discoverability, then serendipity

Block & Files

DevRev: Former Nutanix execs look to lure in dev startups with new business Infrastructure-as-a-Service firm

>This new take on CRM allows modern software companies to bring departments together and support their customers “as one”.

PALO ALTO, Calif., Oct. 18, 2022: DevRev, a company bringing developers and engineers closer to customers, today announced the public launch of DevCRM: the only API-driven, developer-first customer relationship management (CRM) platform for product-led SaaS companies.

In an era of all things product-led, DevRev’s converged “DevCRM” platform brings together customer support conversations and tickets with developer issues and product enhancements. Today’s companies spend hundreds of thousands of dollars to stitch together Slack channels, emails, and in-app widgets with support portals, product boards, and issue tracking software. Yet, these hand-crafted solutions often lead to subscription churn and low customer satisfaction. Tomorrow’s design focused, customer obsessed companies will use product and user centric CRMs to ensure every employee delivers customer success.
 
To realize this vision, DevRev today also announced the general availability of its Support app, an in-app widget, and APIs and webhooks for modern software companies that believe in the power of one: one support engineer, one team between support engineers and developers, and one customer success culture across all. The newly unveiled Support app unifies departments to collaborate as one social team in real-time. This is **Product-Led Support**!

“Over the last six months of using DevCRM, we’ve been able to experience the product, customer, and developer trifecta that can take a product-led company from good to great. It’s no secret that DevRev is at the forefront of product-led customer communications. We’re thankful they’ve helped us lower costs, net better economics, and most importantly, increase customer satisfaction,” said Alok Mishra, CTO, and co-founder of, GoodMeetings. “As a deep tech company, our customers are developers who prefer to communicate via Slack. Our customers love this kind of communication because it feels like 100ms is their video backend team. But managing thousands of Slack channels was becoming challenging. With DevRev, we can scale our customer communications and move beyond archaic customer support systems.”
-Kshitij Gupta, CEO, and co-founder, 100ms.

“Like Nutanix, we are looking at DevRev as another marathon in a large market with established competitors,” said [Dheeraj Pandey](https://www.linkedin.com/in/dpandey/), CEO, and co-founder of DevRev. “But this decade, with our [APIs](https://devrev.ai/docs/apis/getting-started) and webhooks, we will be leaning heavily on the developer community to help us build a modern company with powerful network effects.”

“We’ve been monomaniacally focused on design to converge the workflows of customer support, product management, and developers,“ added [Manoj Agarwal](https://www.linkedin.com/in/devreveler/), President, and co-founder of DevRev. “Convergence was a big mantra for us at Nutanix, and we won the hearts and minds of our users because we integrated people and their use cases.”

The DevCRM platform syncs GitHub, Jira, legacy CRMs, and Slack events in real time with DevRev’s modern issues, tickets, and conversations, elevating managers — technical account managers, project managers, product managers, and customer success managers – to drive user adoption and retention. This is the new **convergence**!

DevRev also announced that it has now raised $70M in seed capital since its inception in 2020. “While this could be the largest seed in the history of Silicon Valley, our employees in five locations around the world are stretching the dollar as far as they can – with automation, cloud observability, and using a minimal set of business software tools,” said Pandey. “DevRev-on-DevRev has kept us disciplined and tightly knit as a company.”

For more information on DevRev funding, or for investor relations, visit [here](http://revd.devrev.ai).

DevRev announces the general availability of Product-Led support, the first app built on its DevCRM platform

Devrev, Intuitive team to advance customer-centricity

**The three-legged PLG architecture**

I have written about the “Why” of Product-led Growth (PLG) and some fundamental principles in action in my previous blogs. In this article, let’s look at the “What” and the “How.” In other words, how do we go about building an operating system that powers PLG?

Before we get into the architecture details, though, I like to start with defining what problems we are trying to solve and, consequently, the requirements to solve those problems. In the end, [as PLG practitioners](https://devrev.ai/articles/all/product-led-growth), we are looking to drive more users to discover our product, become users of the free tier or trial, and eventually, become long-term customers.

In my mind, to build an operating system that helps us achieve this, there are three main requirements:

1) A **website** that is easy to update and manage that you can use effectively to engage with your users and customers.
2) A single and real-time view of  **visitors and customers** and their activities.
3) A way to **orchestrate** actions based on users’ activities and attributes.

![image](https://cdn.sanity.io/images/umrbtih2/production/7ac13d18082c8233213ffede66a0aa9c090b7438-1400x768.png?w=1400)
## Three legs of a PLG architecture

## **Website**

If we further decompose the requirements for a website, I feel the following ones are a must:

1) A  **fast** website where changes can be made as many times as possible in a day without downtime, whether these changes are code fixes and improvements by the developers or content changes made by the marketing team.
2) An automated **workflow** to review, test and publish the changes with the ability to roll back on an on-demand basis.
3) Finally, a way for website visitors and customers to talk to humans when they need help on an on-demand basis.

In my past experiences, I struggled with Content Management Systems (CMS) that most marketing organizations use because it becomes increasingly difficult to make quick changes over time. I remember having discussions with web marketing teams that required three-four weeks of lead time even for creating and rolling out a simple landing page. This is primarily because there is little separation between code and content, both managed by two different sets of teams with different skill sets that leads to complexity around deployment. In addition, as the tech stack gets bulkier over time, the performance of the web pages starts to suffer.

To solve for separation between code and content, you can use a headless CMS to store all your content with a visual UI allowing content writers to make agile changes without requiring any development skills. There are quite a few headless CMSes out there, but the one we at [DevRev](https://devrev.ai/) love is an open-source project called [Strapi](https://strapi.io/). It is a NodeJS based app that you can use out of the box with easy-to-use UI and support for Markdown and effectively create content types within minutes.

When it comes to the rest of the web stack that consumes the content from the headless CMS, I am a big fan of the JAM (Javascript, API, and Markup) stack. There are several good frameworks for this architecture, like [Hugo](https://gohugo.io/), [Jekyll](https://jekyllrb.com/), [NextJs](https://nextjs.org/), and my personal favorite, [Gatsby](https://www.gatsbyjs.com/).

![image](https://cdn.sanity.io/images/umrbtih2/production/da217b88673c9892033ce61242b7460bc81ed83d-1400x704.png?w=1400)

Some of the JAM Stack choices

At DevRev we settled on using Gatsby because it is a NodeJS based framework that allows you to write your entire site in React, and at build time, Gatsby creates static HTML, CSS, JS files. There are some significant advantages with this architecture-

1) **Hosting** these files is dead simple — you can take the output files and dump them in an S3 bucket or host it on an extremely fast web server or use a CDN deployment like Fastly.
2) Since the website is a bunch of static files, the performance is **crazy fast**, which is also great for SEO. In addition, with JS includes you can easily integrate with systems like Intercom that enable conversational functionalities on your website.
3) If your code is on Github, you can create a build time pipeline that does an **automatic build and deployment** of your entire site. We have set this up so that when a Pull Request (PR) is approved, it kicks off a build and deploys the site only when the build is successful. This also enables a zero-downtime deployment,
4) **Separation of code and content** — You can make REST calls to your headless CMS to grab all content at build time. This means your developers can just focus on code (Gatsby) while your content writers can work on content through UI or Markdown. When a change is made either in code or content, you can trigger a workflow to kick off a deployment so your website can up be updated as many times as you want in a day with zero downtime.
5) Finally, since the site is built of React components, you can still create dynamic functionalities by making API calls to your internal systems or using Server-Side Rendering (SSR) functionalities.

![image](https://cdn.sanity.io/images/umrbtih2/production/94ab458da6cffae513d554b0a18915cdb11f01bc-1400x733.png?w=1400)

Website architecture with separation of code and content and zero downtime deployments

## **Data**

Now that we have looked at the tech stack’s website portion let’s try and address the second requirement — a single and real-time view of your visitors and customers.

**In my opinion, in an ideal PLG OS, you should be able to not only look at real-time user data (all visitors + customers) but also orchestrate in-app and off-app actions based on segments of your users’ activities and attributes.**

This category is unfortunately heavily crowded with too many confusing choices. On the one hand, you have tools like [FullStory](https://www.fullstory.com/), [Google Analytics](https://marketingplatform.google.com/about/analytics/), and [Hotjar](https://www.hotjar.com/) that give you heatmaps and funnel metrics around your web visits and visitors. On the other, you have tools like [Drift](https://www.drift.com/) and [Intercom](https://www.intercom.com/) that enable you to add chatbots and get details around user behavior. My issue with all these tools is that typically they want you to use their app as the customer master. Eventually, however, you now have more place for a growth user, including valuable user data disconnected from your multiple customer databases like your CRM, support system, and or your app’s identity database.

**It has taken me years to appreciate the fact that you don’t necessarily need one place where all your customer data resides, rather a way to bring in different portions and views of your users’ data in real-time to perform different actions across multiple end points.** These actions may include re-targeting, personalization within the app, notifications, and finally, data analysis over time. You can, of course, potentially build something like this with Redis Streams or Kafka, but nowadays, there are solutions like [Segment](https://segment.com/) or [Rudderstack](https://rudderstack.com/) with features built on top of similar data architecture like Kafka.

With Segment, for example, you can potentially start collecting data from any data source that can do a POST, and you can send that data, with or without any additional processing, to any other data source. More importantly, you can create cohorts or segments of users based on their attributes (for example, location) or their actions (all users who signed up in the last 1 hour and did not start the onboarding tasks) and send them to different destinations to execute actions.

Here is an example of what your data flow architecture may look like -

![image](https://cdn.sanity.io/images/umrbtih2/production/89388de0f526ef791d440e6f24a9ebb6f57b8700-1400x824.png?w=1400)

Data flow architecture with a Time series data assimilator

## **Orchestration**

Finally, the last piece of the puzzle is to be able to perform automated, scalable actions based on some rules you can create on your own. Typically, you have a rules-based task engine in email and marketing automation tools like Marketo. However, those rules are specific to the data available only on those platforms. Ideally, you want one rules engine to act on data collected across multiple systems like your website, app, ad platforms, etc.

![image](https://cdn.sanity.io/images/umrbtih2/production/dcde1e3a59e21a52f3870440710d8f5080536f7a-1400x522.png?w=1400)

The three pillars of an orchestration engine

There are a few choices here that allow you to listen to events, have triggers that kick off the action, and the action itself, which is a simple lambda function-like entity.

For us, we have been using a NodeJS based system called Pipedream. It allows us to listen to webhook events and run a function that uses data changes or schedules as triggers. With the web, data, and orchestration now in place, the architecture looks like this.

![image](https://cdn.sanity.io/images/umrbtih2/production/85bc4ed34c527e74b4c6d1cd78718fb38603f727-1400x970.png?w=1400)

The complete picture

## **Summary**

In summary, a tech stack or OS for PLG architecture requires an extremely agile website, a good data strategy, and a flexible orchestration engine. Once you have these in place, you can view, nudge, and deliver personalizations in real-time to drive growth for your product. One of the things we did not cover in this blog is 
**where does your traditional CRM fit in this picture** or even how to create real time dashboards and reporting based on this architecture. Stay tuned as we cover those in future blogs.

How to build a Product-Led Growth (PLG) operating system?

In my junior year of college, a group of us computer science majors decided to take a road trip to Las Vegas from the Bay Area. This was an 8-hour journey but that would not deter a few 20-something year-olds. There was a problem though, we would have to miss a day of lessons and we had an assignment due. Turning in the assignment was not a big deal, it was submitted online after all but this was in the early 2000s, before the proliferation of fast, reliable, mobile internet. The plan was to take our laptops, work on the assignment, then get on the WiFi at the hotel and submit our work.
That was a great plan, except that we read the assignment wrong and as we were getting ready to head out we realized it was due that day, not the next. This meant we either had to delay the trip and turn it in or miss it. That is when we realized that through a combination of someone's laptop (I did not own one at the time), my Blackberry, and a USB cable, we could make it happen. While on the road and just 40 minutes before the deadline, we managed to submit our assignment and make it to Vegas as planned.

## Untethered Engineers
So what does this story have to do with Slack and engineers? Just like a few college students turned to the convergence of new technologies and trends to solve a problem better, so too did Slack and the army of engineers that adopted it. Slack was able to pick up on a growing engineering pain point, the rise of new technological trends, and a newer generation of users looking for better tools. How did Slack untether engineers where previous tools failed and how can it be even better?

## Engineering Pain
I should make it clear that when I talk about engineers here, I am including software architects, developers, solutions engineers, QA, support engineers, and all those titles that fall under the umbrella of engineers in charge of creating, supporting, and running software. The fact that if we were to write out every title, we would add dozens of lines to this article, is exactly a manifestation of the primary pain point Slack addresses; who do I talk to about this? As software development was becoming more complex with many more languages, specialized roles, distributed architectures, and remote teams, the reliance on communication had grown without good tooling to support it.
While developing a game, Stewart Butterfield and his team picked up on this pain point and abandoned the game to develop what would become Slack. Let’s look at how Slack solved this problem while existing tools and competitors failed.

## Slack is easy

![image](https://cdn.sanity.io/images/umrbtih2/production/34394b8495aa7045c96aed3b4c3146c89f1010cd-1999x1475.png?w=1999)
First and foremost, Slack is easy. Slack is not just easy to use, it is easy on various fronts. The onboarding process is simple, they offer a free tier (who does not love free?) and day-to-day, as well as purpose-oriented activities, are frictionless and intuitive.
The beauty of easy is not that it allows you to do something new, it is that it allows you to do it better or not do it at all. Just like VCS replaced the tedious process of developers emailing tarballs of source code to each other, so too has Slack replaced old mediums. In doing so, Slack has almost completely replaced engineer-to-engineer conversations that previously lived in emails, internal chatting tools, ticketing systems, and water-cooler conversations.
The Slack channel provides enough context for conversations, be they a team or a function, that the search feature makes finding “who do I talk to about this?” much easier than navigating email groups or internal wikis. Even the administrative process of creating a channel and adding people is easy and not bottlenecked by an overworked administrator.
Slack is available everywhere and to everyone
Just like college students, engineers often lead the pack when it comes to working on and in new mediums. Slack makes this possible by running as a desktop app, in the browser, and on mobile. The different mediums are not just checkboxes either, they are equally easy to use and quite powerful. What is more important, however, is that it allows non-engineers to use the same tools. After all, the answer to “who do I talk to about this?” is often someone outside the technical arena. This, combined with the ease of use, ensures that Slack is not a siloed tool. After all, there are already good tools for certain types of communication, think of GitHub or JIRA but those tools are siloed from the rest of the organization and even between different engineering roles.

## Slack integrates with everything
The ease of use and wide availability of Slack helped it gain popularity and a legion of users but it is the integrations that have made it sticky. Engineers use tons of tools and various processes to build, run and support software. The introduction of the Slack Marketplace and its cornucopia of apps lets engineers embed Slack in their day-to-day processes.
This means that it does not matter if you want to use Slack to support customers, integrate it into your CI/CD pipeline, or use it as part of your incident management process, there is very likely already an integration with the tools you are using.

## Beating out the competition
When you combine the ease of use, its wide availability, and interoperability, it’s not hard to see how Slack trumped the competition. Email was available everywhere and easy to use but without channels, it is easy to lose context and it is completely disconnected from the rest of your tooling. Tools like HipChat existed before Slack but failed to capture a large following, in part due to a late introduction of a free tier, clunky UX, and limited integrations.

## DevRev and Slack
Just like Slack, DevRev sees an unsolved engineering pain point. The DevSecOps movement has streamlined and connected the software development cycle from coding to deployment but that connection has not been made from the developer (Dev) to the customer (Rev). The developer today works in the dark, relying on sales, customer support, and PMs to interact with customers and relay back information. The disparate tools these parties use means the information is often lost, siloed in tools unavailable to developers, or unrelated to the developers' day-to-day activity. At DevRev, we want to empower developers with this information, in the tools they use every day to enable better decision making. A developer that understands the impact of their work and how it truly affects the customer will be a better developer, focusing on what matters and delivering software that delights. 
## Product not channel focused

![image](https://cdn.sanity.io/images/umrbtih2/production/0ce5fce08dbcab3b0a26eaaf89110150a0598b52-1999x1041.png?w=1999)

While Slack makes it incredibly simple to find the right people to talk to and of integrating with various tools to provide many communication funnels, it fails to answer the question “what should I be working on now?”  At DevRev, we help answer this by making the product the center of the universe. We build a connection from the code devs produce, to the services the code powers, to the features and capabilities provided by those services, and to the products that contain them. All (rev) interactions, whether it is a support ticket opened by a customer via Slack, usage metrics, a feature request filed by an internal team, or an RCA of a system down, are then tied back to the product and ultimately code. This allows developers to easily look at a work item and see the whole picture, how it affects revs and what work matters the most. 

Luckily, you don’t need to choose one or the other. Empower your engineers, integrate Slack, DevRev, and the rest of your tooling and let the engineering love continue.

How Slack redefined collaboration in software development

Even in the Product-led era, as a business owner, your job doesn't end with building a solid product and releasing it to the public. Taking that extra step to build brand loyalty makes customers return to your product. This is a fundamental principle of Product-led Growth (PLG).

Customers desire faster responses, minimal back and forth, and more self-explanatory products. Several terms such as customer support, customer service, customer success, and customer relationship management are used interchangeably but ultimately aim at ensuring customers are well taken care of.
But do you know what the best approach for your product is? Let's first decode what Customer Support actually means.

## Understanding Customer Support

Customer support is when a team of people uses a set of tools to help customers navigate your product to achieve their intended goal with ease. 

There are various mediums to support a customer in need. You can provide in-app and outside-the-app aids like phone support, live chats, email support, help desk ticketing systems, CRM tools, feedback surveys, onboarding, guided tutorials, tips, breadcrumbs, etc.

Essentially, these are customer services your company can provide to help facilitate the KPIs lifecycle like customer acquisition, conversion, retention, and expansion.

You can access the mediums mentioned above and fix the bugs that come your way through tradtional support systems or tools such as Zendesk, Salesforce, Olark, Qualtrics, etc.

If you are a Product-led startup, your company might see some growth traction from the get-go, and you might wonder if there is a need to invest money and time in support tools at all. Well, you need systems and tools in place to see continued growth and profits. Here's why:

## Why do we need Customer Support tools?
When customer interactions with a brand heavily rely on digital platforms, providing quick and personalized customer support is more crucial than ever.

Relying on a single used and tested method like the phone or email support alone is insufficient to satisfy the customers of today who are constantly on many different channels, often at the same time. The many benefits of using customer support tools are:

**Customer loyalty** — You build loyalty when you work to improve customer satisfaction. Happy customers are less likely to switch to another platform. Your team can provide premium quality service only when they have the correct data and tools to execute faster.

**Growth** — Human nature is to recommend products they are happy with. So in many ways, our customers are our primary marketers. When you enable ease of use, quick fixes, and personalized communication by analyzing their behavior on your platform, you produce happy customers who introduce your product into their workspaces and personal teams.

**Competitive edge** — When your support agents can manage, react and resolve customer issues quicker with less hassle, they tend to create stronger connections with your customers. You work better when work is delightful and practical, and you can see the impact you can make. Customers can achieve their intended goal in time, ranking your product higher than your competitors with less to no frustrations.

## What makes a promising Customer Support tool in 2022?

Now that we know the importance of using tools, how do we identify the good ones among a sea of tools? Your tools must abide by the fundamental principles of a great support tool:

**Speed driven by fewer intermediaries** — According to Warwick University, the initial turnaround and resolution response time has the highest impact on customer retention. Its defining factors are primarily based on the number and rate of contact channels and employee skills — the lesser the intermediary platforms and the higher the employee skills, the faster the fix. Here, tools that reduce the intermediaries between the maker and the customers, and therefore, the latency of response and resolution are of the highest value to the customers.

**Accuracy driven by AI**— Quick responses work on the surface level. But inaccuracy leads to undesired output resulting in dissatisfied customers who opt out of the platform. Accuracy in response to reported issues increases with reliable tools for documentation and tools with search powered by AI that can add meaningful context to all customer interactions.

**Efficiency with case deflection** — Customer feedback directly reflects the quality of your customer support. Some issues might not need individual attention and can be resolved in bulk. In addition, there may be tickets and issues that may be related to each other. The right tools will not only proactively identify the issue for existing ones but will also help with auto-clustering and help with prioritizing those issues.

**Clarity with natural UX** — The tools must be easy to use, and the information must be easy to grasp so that there is a very low learning curve across users in your organization. Only then can you execute with a significant impact on your customer experience. This includes factors like simplicity in interaction design, language, self-help tools, and easy flowing and familiar user experience.

**Universal org accessibility** — Are your contact channels easily accessible by your front office agents, back office engineers, and customers alike? Newer customer support tools bridge the gap between customer agents and engineers who need to work on escalated issues in a single platform that also has a single identity of your customer. 

Apart from this, you must ask yourself if the tools you pick have a good ROI in three categories:

**Learnability** — High learning curves leave you with no time to execute. Use tools that are easy for everyone in your organization to understand on their own using self-help tools and in-app support.

**Trial** —  Modern tools let you try out their solutions without any cost to you through trials and credit. Once you are satisfied that the tool will fulfill your needs, you can switch to a paid plan that is ideally based on consumption i.e., you pay for what you use.

**Niche or swiss-army knife** — It doesn't make sense if the customer support tool needs another support tool to manage, for example, one for customer conversations and another for ticket management. With multiple tools, you end up wasting time and effort on integration, and the data about your customers become less and less reliable over a period of time. Instead, look for something that can solve most, if not all, of your customer support requirements.

## Key Trends in 2022

The approach to customer support has drastically changed to a digital-first policy. Let's look at some practices and trends that your business must have in 2022:

**Trend 1 — Proactive customer support**
Modern digital-first companies today have enough telemetry information about their products and services so that they are not only aware of when their customers are facing issues, but sometimes, with the help of AI, they can even predict before a customer faces an issue. In either case, more and more companies are looking at either proactively reaching out to customers when an issue occurs or resolving the problem even before the customers become aware of them. 

**Trend 2 —A sink for all customer interactions**
In today's day and age, consumers have the privilege of choosing their preferred communication channel, physical, digital, or traditional, and they are often present in multiple channels simultaneously.
If there are multiple channels that the user switches between, the business should be able to integrate and switch between them seamlessly without loss of data while having a single place in the backend where all customer conversations and interactions are collected and shared with the relevant customer success employees at the same time.

**Trend 3 — Mobile-first conversations**
Although not a new trend, mobile-first conversations continue to be a big trend in customer service even in 2022 and beyond. 
Messaging apps like Whatsapp, Line chat, and Apple Business Chat are extremely easy for consumers of any target audience to use. They are easy to install, adaptable to all iOS and Android devices, and have a minimal learning curve with minimal features.
Some businesses reported a 20% reduction in service calls when the brand shifted to messaging mobile-first apps to connect with and resolve user pain points.

**Trend 4 — Agent empowerment through machines**
A core aspect of good customer support is a potent agent team. They have the responsibility of being the face and voice of the brand. It can get overwhelming at times.
Skyrocketing magnitudes of queries, rising customer anxiety, and adjusting to a remote work environment have increased the chances of agent burnout. It ultimately results in poor or frustrated customer management.
New age tools help companies empower the support agents by providing real-time information about the progress of work relevant to their customers through piping contextual information directly from production and modern developer-friendly work management tools like DevRev.

**Trend 5 — Automation to prediction**
Machines are here to complement humans and take over the laborious work of extensive research, data analysis, behavior prediction, and so on. We need to make use of the tools and reap their benefits.
Artificial intelligence (AI) and automation are transforming businesses by increasing economic growth through augmenting agent productivity capabilities.
Things like AI-powered bots help handle the frequently asked queries while agents can focus on live assistance for complex pain points. 
Businesses can stay ahead of the curve by harnessing the potential of AI to predict customer requirements from the data they input and their behavior on their platform, in addition to providing search capabilities that help in automatically discovering and clustering existing issues. 

## Top 10 tools
Here are our top picks of tools under the various categories:

**Knowledge Base Self Service**
Nobody likes asking for help a million times, and there is room for misinterpretation in communication. A knowledge base is a centralized, organized collection of information about a product, service, department, or topic.

**[Document 360](https://document360.com)** is a cloud-based help desk SaaS that lets you create a documentation website with how-to guides, FAQs, tutorials, SOPs for external customers, and a separate internal knowledge base for your agents. Markdown and WYSIWYG editors are versatile and clean, supporting extensions and integrations of external systems.
Freemium: 5 team accounts + 1 version
Premium: $19 per addition team + $39/$99/$199 per additional version

![image](https://cdn.sanity.io/images/umrbtih2/production/8f6fb597e8cafa66c2035c04aa6bc5a84b1743e0-3106x2132.png?w=3106)


**[HelpJuice](https://helpjuice.com)** offers advanced analytics and extensive customization with complete authoring and formatting. You get insights into what categories hold the user's attention, measure article impact, and optimize your platform for your customers. Their google-like search makes it easy to navigate the forum and find what you are looking for.
Freemium: 14 days trial
Premium: $120–4 users|$200–16 users|$289–60 users|$499-unlimited users per month



**Dev CRM aka Developer Customer Relationship Management**
As technology and customer expectations rapidly change, Dev CRM focuses on connecting the customers and front office customer agents directly to the developers with Slack-like features with AI features for conversations. 

**[DevRev](https://devrev.ai/blog/you-have-jira-you-like-slack-you-ll-love-dev-rev)** — The platform has a product called PLuG that customers install directly on their apps and enables conversation between customers and customer support agents about the tickets and issues that engineers are working on at any time. The tool has AI capabilities for search and case deflection, but what sets this platform apart from traditional old-school CRM and support tools is the fact that the product catalog is connected to the issues engineers are working on to the tickets opened by customers, and finally, to the conversations happening in the conversation widget. This is the desired solution for companies that define themselves as Product-led Growth (PLG) companies.
Pricing: Users can sign up for the [beta](https://devrev.ai/landing/beta/?utm_source=artclead&utm_medium=fb&utm_campaign=supportarticle) on the website.


![image](https://cdn.sanity.io/images/umrbtih2/production/b7825a6e37040e22156344618bc05e6a3e90b2a8-2660x1516.png?w=2660)


**Customer Feedback Survey**
One of the important tools for customer support is gettting feedback and researching from customers. There are several tools to conduct surveys and specifically to capture NPS but we love Typeform for its simplicity and flexibility. Within a few minutes, users can create a pleasing feedback form or survey and gather insights from their customers.

**[Typeform](https://www.typeform.com)** — You can use this online survey-building platform to build a set of questions with relevant images and videos for more insight and improve response accuracy. It generates sharable survey reports, which you can share with data analysis tools and better satisfy your customer needs. The bonus feature lets you customize the layout and themes to establish brand identity.
Freemium: 10 questions per form |10 responses per month+ Advanced logic|Multiple endings
Premium: $25–100 responses|$50–1,000 responses|$83–10,000 responses per month

![image](https://cdn.sanity.io/images/umrbtih2/production/04b17eeec29f43aae3ff0c52013dea9d5ba54384-3106x2132.png?w=3106)

**Customer Service Training Software** 
Customer service agents have the power to make an impact on the entire business. Skilled agents can acquire, retain and convert users, and experimentation can cost the business a lot. To ensure all support agents are on the same page as the rest of the company, we need continual training programs which are effective and friendly.

**[TalentLMS](https://www.talentlms.com)** — You can simplify the development, deployment, and management of training programs for your agents and partners by creating courses, hosting live sessions, and conducting tests. Your agents can always go back and browse videos from specific categories to stay on track. It reinforces the importance of training for smooth onboarding and compliance of agents for marketing, sales, remote workflows, and training partners.
Freemium: 5 users + 10 courses + unlimited email support
Premium: $69–40 users|$14–100 users|$279–500 users|$45–1,000 users per month

![image](https://cdn.sanity.io/images/umrbtih2/production/9be92c37e1ca34aa927061d2fdec6bde8eab2fcf-3106x2132.png?w=3106)

**Project Management**
Businesses should equip their customer service team to handle multiple projects at once. Managing one project and sticking to timelines is a huge mental load. Imagine if you miss a deadline or implement a solution in the wrong ticket or project. The business is at stake, leaving the customers angry and confused. A project management tool helps organize, prioritize and track progress across different channels.

**[Asana](https://asana.com)** — Use Asana to collaborate with multiple teams to set milestones, assign tasks, and subtasks, define deadlines and get a complete project overview to onboard any stakeholders with transparency. It enforces collaboration and organized teamwork. You can clearly see the issues by switching between views and supporting documents attached to the tickets. You can also save time by copying regular workflows into different projects instead of recreating them from scratch.
Freemium: Unlimited projects + Unlimited files|100MB per file storage + 15 teammates
Premium: $10.99-admin console + unlimited dashboards | $24.99 for Businesses of every scale

![image](https://cdn.sanity.io/images/umrbtih2/production/680cc6186ca897380dd4c8c0365a0979373035af-3106x2132.png?w=3106)


## Final thoughts
Customer support has evolved rapidly over the last couple of years as more and more companies have gone remote and, in the process, become entirely digital. With AI and machine learning, modern companies are now emerging that are specifically built to help Product-led Growth (PLG) companies that have a different set of requirements. These companies are looking to get to Product Market Fit (PMF) sooner through their products by becoming more customer-centric and are looking for tools that help them reduce the latency in helping their customers and also provide personalized experiences with the help of AI and machine learning. We expect to see a big shift in the emergence of more PLG companies challenging and morphing the traditional tools of customer support. 


All articles(55)