Call it the consumerization of enterprise software or the gamification of UX in SaaS → they both reflect the reality that to win in SaaS you need a product experience that is as functional and useful as it is self-evident. It’s an irrefutable trend of the modern workplace that tool adoption is increasingly driven by the end user rather than a centralized team.
And Product-Led Growth (PLG) is the go-to-market (GTM) motion to capture this! One where we apply the same growth principles honed over a decade in consumer software and gaming to move users along in their journey with the product to discover and learn new features and use cases, invite their teammates, and solve their
At least, that’s what they say....
In practice, PLG is an excellent tool in your arsenal ー but depending on the business, it’s one that should compliment a balanced approach. Two pieces of advice (or perspective) for the operators of SaaS companies...
(1) Product-led growth might be necessary, but not sufficient as a GTM motion.
to see the
in your GTM motion. Once the poster child for product-led growth, Slack is now (in some perspectives) the
for relying on it too much (or too long).
Every company and industry will be a bit different — and the question for most of us is “what is the right mix and sequence” for PLG vs another model — like being sales driven.
as an example. The product itself is horizontal in nature ー meant to be used across a diverse set of functions (Sales, Marketing, Engineering, Product, ...), industries (tech, transportation, education, government, ...), and segments (consumer vs business). It is used by individuals to
, startups running their
, and teams rolling out a
What single GTM motion would scale up and down across that? The truth is none do. And that’s why it was necessary for us to develop and invest in both a strong PLG motion early on to service the long tail of use cases and to start investing in a well armed customer facing team who can help businesses adopting Coda navigate their more complicated processes or workflows.
(2) Implementations of PLG can happen at every level of your motion ー including monetization.
It’s easy to focus on product-led initiatives like your new user experience or spread vehicles when thinking of “product led growth”, but your monetization model is equally as important. How and where your users encounter paywalls is as impactful as which features or use cases they’re introduced to. Do it too early and they might balk or the product won’t spread. Do it too late and you might miss out on important signals of intent (let alone the revenue!).
, we are disproportionately focused on Makers. Makers create docs, build task trackers, and configure automations that keep their team on the path. They create and alter the fundamental structure of docs, often evolving docs from simple notes to a complete project tracker. In almost every team, there's usually one person or a small handful of people — Makers — who lead by creating these artifacts that get everyone pointed in the right direction. And it might start simply by taking notes.
To better understand this, internally we've come to rely on galaxy charts ー a visualization that shows the relationship between users and docs on a team (the rest of the data science community would call them
... but internally "galaxy chart" stuck... and that's culture ¯\_(ツ)_/¯).
"Galaxy charts" visualize the relationship between users and docs.
These visualizations gave us an easy way to see the week-in-the-life snapshot of a team and their docs. Here's how to read them:
The yellow squares represent Coda docs, while the teal dots represent users.
The more users collaborating on a doc, the bigger the square.
The thickness of the line connecting a user to a doc represents the total number of edits they made over the course of the week (edits include creating tables, adding rows, editing text in sections, etc.).
A few stark observations came out of viewing thousands of these (as well as the reason we started calling them galaxy charts ー they looked a bit like constellations):
All teams are different
. Some start with a single doc and use case, others very quickly expand and diversify. And the type of use case is really important. In talking with users, it’s clear that personal notes, 1:1 docs, and team planning docs each have exceedingly different patterns.
Makers do the heavy lifting
. Nonetheless, across all scenarios, the doc would not meaningfully exist without a dedicated Maker. They're often the driving force in an organization or team, no matter the size.
Roles change; teams evolve
. And while you might be a Maker on one team, you're an editor or viewer on another team. Or you might start as a viewer in someone else's doc, and over time make your own. Evolution happens, but we regularly see teams start with a single doc.
A sampling of how teams interact across docs, highlighting the importance of Makers.
Ultimately, this Maker-first perspective inspired our monetization model ー
ー where we recognize that Makers are at the heart of how work gets done in a team and "spread" across an organization needs to be as frictionless as possible (e.g. it's unwise to establish a bunch of paywalls when someone is sharing).
Said differently, at Coda, one of the most important tools at our disposal for growth was to make sure our monetization model didn’t get in the way.
Interested in working at Coda?