I have worked in enough marketing organizations to see that most of the time, the marketing tech stack is usually a smorgasbord of technology and solutions that are usually purchased by random acts of reactive and opportunistic buying over a period of time. Due to this, the longer a company has been around, the worse the quality of data that the teams have to work with. This leads to countless problems like marketing to the wrong target audience (for example, someone who just purchased your product) and, worse, not reacting quickly to the intent signals from all the inbound inquiries.
More recently, I built an entire Product-led Growth (PLG) marketing tech stack from scratch, which opened my eyes to some best practices. I intend to cover the steps of building the tech stack and best practices here so that other startup growth marketers can replicate this for their needs.
Any effective Product-led growth tech stack can be broken into three broad categories that work in tandem to ensure data is flowing correctly and is available in real-time for your team to act on quickly. These categories include:
There is a fourth category, the glue between the website and the app, the authentication layer. However, this category has been commoditized to the extent that it has become reasonably trivial to add to the presentation layer, so I am choosing to cover that in the presentation layer instead of calling it out separately.
When it comes to the presentation layer, it is essential to understand that you will always need two kinds of people to work on your website —
The trick is to have a tech stack that separates the code from the content so that both the content editing and the code editing work streams can run in parallel. In addition, you want the tech stack to be set up in a way so that you can make changes and deployments to your website as and when you want or deploy on commit.
For several years, the most common technology in this area for startups had always been Wordpress due to the ease of installing and quickly publishing blogs and pages in a fairly low code way. However, after using this tech stack in a couple of companies, the cons with Wordpress far outweigh the pros as the website and presentation layer for PLG as the team grows over a period of time. So, instead of going into the details of why not to use Wordpress, let me talk about two React frameworks that are far more powerful and flexible and provide all the tools marketing and development teams need to be truly agile.
These two frameworks are — Gatsby (recently acquired by Netlify) and NextJS(backed by Vercel).
I have used both Gatsby and NextJS, and here is how you choose one vs. the other. If you have a lot of static content and want a lightning-fast website with very little content behind a login, go with Gatsby. On the other hand, if you want a stack that does both static site generation and has features like content, videos, etc., that sit behind user authentication to provide personalized screens (for example, your own community app), then go with NextJS.
Here is a simplistic architecture diagram that separates code from content and enables deploy-on-commit (with review).
Now let’s look at the data layer, which can be subcategorized into measurement and reporting.
Let’s look at some examples of tags you may want to add to track the right metrics for PLG and add additional functionalities.
The architecture now looks something like this:
II) Measurement — Before we get into how to measure and report, let’s look at some high-level metrics that are extremely helpful to understand if your campaigns are working, the cost of the campaigns, and if your users are converting to a paid plan or not. These metrics can be classified into two sub-categories — Acquisition and Adoption.
Under Acquisition, you want to track the traffic coming to your website and sign-up pages at the highest level. Typically they fall under organic and paid channels. For paid channels, you want to track (attributed through UTMs) how much money you have spent on each campaign, cost per click, cost per Acquisition, and the number of free trials by the day (or week).
Under adoption, you want to track some key events after the user has signed up, for example, did they finish the onboarding, did they invite other users, and finally, did they convert to being a paid user?
To measure both acquisition and adoption metrics, I recommend sending all data into a real-time database like SingleStore that can handle both structured and unstructured data and can be used for orchestrating real-time actions (more of this in the next section).
A typical Segment based architecture looks like below:
In full disclosure, I work for SingleStore, so my opinion of using SingleStore as a PLG source of truth may be biased, but you can choose Snowflake or Google BigQuery as an alternative. My only issue with both those tools is that they are not real-time, so when it comes to orchestration, you will find you are limited in how quickly you can react to your user’s actions. Also, Snowflake could get very expensive as you grow, so you may want to do your evaluations before you pick a data warehouse for your reporting needs.
I should add that this is an opinionated version of the architecture based on my experience. You can also use a tool like Heap, Pendo, Mixpanel, or Amplitude either directly or by putting that data into Segment through GTM and then using one of the product analytics tools as a Segment destination. When you do this, remember that you are adding one more tool and yet another data source that can lead to complexities.
Finally, once you have your data flowing the way you desire, you want to be now able to orchestrate actions against events being captured within your website and your app. These actions could range from either personalizing the content of a page when the user is anonymous or sending a nudge via email and in-app notification to the identified user if the user is signed in. There are a couple of tools for this, which again fall under two sub-categories — Low and no-code and code-driven orchestration tools.
Regarding low to no-code, you can choose between Zapier, make (formerly Integromat), and Workato. In the code-driven category, my personal favorite is Pipedream because it is Node based, so it helps with re-usability and has a free version you can get started with.
In addition, you can also use Segment functions to perform some actions of data (for example, transform, de-dupe, etc.) and then forward them to destinations like Sendgrid, Mailchip, Eloqua, etc. to send an email or even send out text messages through Twilio. I should also add that Segment recently also launched a new product called Twilio Engage that allows you to create workflows and run all kinds of orchestration from within Segment itself.
I did not call this category out initially because this is one of those things that fall in the presentation layer, but it can help you both with the collection of data and acting on them. I recommend looking at two options in this area 1) Intercom and 2) DevRev (full disclosure I used to work at DevRev before).
With Intercom, you can not only initiate a chat with a human when a user is on your website or your app, but you can also view some valuable analytics around the user journey and orchestrate actions based on several user attributes as well as a user action. Remember that you can also do this with Segment, so use it based on your requirement.
As a quick aside, if you are in B2B, consider adding Calendly to Intercom to facilitate meetings directly from within Intercom.
When it comes to DevRev, it is more than a chatbot in the sense it can be embedded in your website and application with a JS tag, and it enables you to also add support to your product with humans through DevRev PLuG. Your users are also able to create support tickets and view the progress of these tickets from within PLuG. In the backend, you can connect these tickets and issues directly to the GitHub product code so that you can view insightful data about your product in general.
In summary, you can create an entire PLG tech stack under three main categories — the presentation, data, and orchestration layers. The main goal is to identify what you want to track and what actions you want to perform and experiment with to drive more product acquisition and adoption. Once you figure this out, you can think of the data pipeline that works for you and create an architecture similar to the one described in this chapter using the tools mentioned. Feel free to comment here or subscribe to my substack to gain access to additional resources for each chapter.