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

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

“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?

**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.

All articles⁽⁴⁾

The why and what of DevRev

How to build a Product-Led Growth (PLG) operating system?

10 Product-Led growth PLG principles in action

Why should a developer be your first marketing hire?

All articles(4)

The why and what of DevRev

How to build a Product-Led Growth (PLG) operating system?

10 Product-Led growth PLG principles in action

Why should a developer be your first marketing hire?

All articles⁽⁴⁾