Growth Platform is a bunch of tools that can accelerate the iteration speed to scale the Product. This is not meant to be some abstract framework or complex jargon but actually a set of tangible software tools to build Products so expect this section to get a little technical.

💡 The mission of a Growth Platform is to fuel the engine responsible for scaling the product to run in cruise control.

To help with better understanding where they fit in the lifecycle I will classify them in three buckets -

  • Know your Users
  • Reach your Users
  • Learning and Improving

Know your Users - Data Platform

💡 The mission of a Data Platform is to give 360 insight into how users are using the product and democratizing that data in a secure and reliable way.

Read more on how to build one in How to Build a Data Platform and it’s different layers. Here are the list of tangible tools your platform needs to have -

Event Tracking: A system that can provide typed schemas - Thrift, Protobuf, json, yaml to define events to track on your product and compiled natively on all clients - Android, iOS, Web

💡 Data modeling in your data warehouse starts from event definitions.

Event Ingestion: A Message queue system that can scale to accept the firehose of events. Kafka, Amazon Kinesis are good examples of event ingestion engines.

Data Warehouse: This is where your data lives for consumption as physical tables that are modeled to map to the various user journeys in the form of facts - searches, purchases, clicks and dimensions - users, pages.

💡 Moving data reliably from event ingestion to data warehouse is complex and requires an Infrastructure team to scale the systems.

Metrics Layer: A semantic layer (API and query templates) on top of the data warehouse that can translate data access patterns into combinatorial pairs of subjects, metrics and dimensions. For end users and applications the interface to query the data warehouse goes from a complicated SQL query to a more semantic based query such as:

  • GET metric:Daily Active subject:Users in dimension:Asia
  • GET metric:App Installs subject:Devices on dimension:android
  • GET metric:Impressions subject:Page

By treating metrics as a first class citizen, data can be democratized to every one in the organization, both technical and non-technical audience and ensure strong data governance practices.

💡 The challenge in building a metrics layer is not technical expertise but instead rallying the company to think of data in this way from the outset. It takes a highly collaborative cross functional team (Engineering, Data Science, Product, Research and other stakeholders) to successfully design and build metrics this way.

Visualization Layer: Visualizing data is a lot more powerful in uncovering usage patterns when built right. The key is to not inundate the end user with a heavy tool with fancy operations but instead focus on automating the access patterns that are being reused. Some examples are:

  • user journey charts
  • user cohort charts
  • growth rate charts that show absolute and relative changes

💡 Less is more here and don’t get caught up on the tool.

Reach your Users - Notification Platform

Using the data platform you were able to know more about your users and identify some key user cohorts that you want to communicate with to grow your Product, an omni channel Notification Platform would help you do that.

💡 The mission of the Notification Platform is to deliver the right message to the right user at the right time.

A Notification Platform should contain the following -

Segmentation: Segmentation is a way to generate user lists based on a set of conditions for a targeted purpose such as email campaigns, personalization, experiments, etc.

Conditions can either be static lists that are loaded once from a data source - csv, database, manual upload or configured as dynamic rules that are evaluated on the product.

Dynamic Rules:

Let’s say you want to show an upsell banner on the product landing page for US users that are in a free trial only when they are using the mobile app, you can define your audience as a dynamic rule

---
name: free_trial_mobile_audience_us
description: Rule to configure US mobile users in the free trial.
rule:
	criteria: all_of
  conditions:
  - source: impression
    key: page
    values:
    - landing_page
  - source: impression
    key: free_trial_status
    values:
    - on
  - source: impression
    key: platform
    values:
    - mobile
  - source: impression
    key: location
    values:
    - US

These are meant to be lightweight rules that can fit in memory, highly available with some eventual consistency and made available on browser, native apps.

Notifications: A notification is the actual message that reaches the user. It can be an extremely valuable growth lever to form a positive habit if used right but it can also be detrimental to the point where users leave your product because of them if not used right.

Notifications are associated with a channel, aka the medium for delivery. Popular channels are:

  • Off-product channels
    • Email
    • Mobile app push
    • Desktop or Browser
  • In-product channels
    • Notification feed
    • Banners and pop-ups

Each channel has it’s own nuances and can be large infrastructural systems of their own but also share some centralized infrastructure such as -

Badging: A simple yet often misused tool to indicate a new notification which is most commonly represented either as a red dot or red dot with a number. Being able to auto increment the badge when something new arrives and being able to clear the badge across multiple devices is where things get messy and a shared infrastructure to do this is very handy to have.

Throttling and Rate limiting: One of the side effect of having a robust notification platform is it gets very easy to send a notification to the user which can start feeling spammy if they lack a coherent experience for the user.

Imagine getting the same notification that a new episode of your favorite show is available via push and email at the same time or your phone going off in 3 AM with a bunch of push notifications of every comment on a post that you’re following.

A centralized infrastructure to throttle and limit the notifications would allow the platform to intervene and provide a better overall user experience. Some common techniques used here -

  • Gradual grouping
  • Cool-off periods
  • Send time optimizations.
  • Daily or Hourly digest of non time sensitive notifications

Preference Center: No one likes getting spammed with unwanted notifications, it not only creates a bad user experience but also dilutes the importance of necessary notifications. A centralized preference center for users to adjust their notification settings puts the controls back in the users hands which is extremely important for a healthy notification platform.

Required characteristics of a preference center -

  • Clean and intuitive taxonomy of notifications that are granular enough for users to understand what they are toggling on or off and consistent across device platforms.
  • All notifications are mapped to the taxonomy and available in the preference center.
  • Settings are always respected when sending notifications.

Learning and Improving - Experimentation Platform

With a Data Platform and Notification Platform you can get pretty tactical at execution in no time but chances are you’re not going to get it right the first time and you need to foster a culture of learning and improving - this can be achieved with an Experimentation Platform.

An Experimentation Platform let’s you test out a hypothesis by running a A/B/n test to prove or disprove a causal relationship between the change and impact. This allows Product teams to rapidly test new ideas and let data win over opinions.

Experiments are an industry standard to measure causal impact but before delving into the platform goals itself a few things to keep in mind when designing experiments:

  • Experiments should go through a rigorous design approval process to verify the hypothesis is backed by some meaningful data or research and the metrics used to quantify the impact are sourced from the Data Platform - the cost of running a malformed experiment is high both from a maintenance overhead and wasted time and resources.
  • Try to break down a large hypothesis into smaller ones to iteratively experiment that are easier to measure.
  • Don’t blindly chase experiment wins and overlook results that are negative. Experiments are a powerful learning tool and a failed experiment can also reveal interesting findings.
  • Experimentation culture is not built overnight and takes a highly cross functional team of Engineers, Product, Data, Design, UX to make it successful.

A basic Experimentation Platform should contain the following -

Registration Service: Register your experiment by defining the population, traffic allocation and number of variants.

Assignment Service: The core service that randomizes experiment subjects into deterministic experiment groups.

Client SDK(s): Access layer for the assignment service that can cache the experiment assignment value for the session duration and log the assignment event.

Compute engine: Data pipeline that can join the assignment events with metrics from the data platform and pre-compute the raw experiment results.

Analysis engine: Collection of statistical methods and analysis to compute the p-value, confidence intervals, sample ratio mismatch (SRM) and present the results in an intuitive dashboard.

With this Growth platform, in the next part: If you build it, you should grow it. we’ll cover how Product teams can get their hands on a powerful growth engine to build and scale iteratively.