Product-led growth wins for three reasons:

1. The best way to prove a product solves a problem is by using it to solve the problem

2. Pull distribution is better for the customer

3. It’s cheaper and more scalable, which is better for the vendor

What is product-led growth?

According to OpenView Partners, who I believe coined the term:

Product-led growth (PLG) is an end user-focused growth model that relies on the product itself as the primary driver of customer acquisition, conversion, and expansion.

Product-led growth is the cloud-native business/distribution model. It enables a consumer-style technology acquisition and activation method where an end user can self-service solving their own problem.

And it carries a lot of benefits to both vendors and customers that the legacy software distribution model does not. Let’s explore three key benefits that I believe to be propelling this model.

1. The best way to prove a product solves a problem is by using it to solve the problem

As I argue in Business model fit,

Your product has a risk profile that creates a barrier between prospect and happy, growing customer. Your business model’s job is to reduce these risks through trust building.

In a Sales-led model, this trust building happens through people talking to people: RFPs, requirements discussions, demos, roadmap reviews, contract negotiations, etc. This is the same way that we sold on-prem license & maintenance contracts… the software-native model.

In a Product-led model, the trust building happens in the product. The product is designed in such a way that it can be easily acquired, deployed, and adopted before any commitment is needed. The idea is to create value before capturing value. This is only feasible with a cloud delivery model.

And if the job of a business model is to reduce risks through building trust in the product… it’s a no brainer that the product itself is the best way to accomplish this.

2. Pull distribution > push distribution

The business model is better for the customer.

Not every organization wants to buy in a bottoms-up way. Some organizations prefer to have IT or functional leadership calling the shots. While PLG enables bottoms-up end user distribution, mature practitioners don’t require it.

Rather, companies with PLG distribution motions enable optionality for the customer. Instead of pushing the vendor’s business model onto the customer (either tops-down OR bottoms-up), they meet the customer where they are with a hybrid approach.

This better vendor <> customer business model match is pull distribution. You’re letting the customer pull the product into their organization exactly how they want to.

3. It’s cheaper and more scalable

The business model is better for the vendor.

Software is much cheaper and more scalable than people are. And software-led/assisted distribution is also cheaper and more scalable than purely people-led distribution. And still, some aspects of a distribution cycle are still better suited for people. And PLG recognizes this.

PLG models let software do what it does best, and people do what software can’t.

• Software can simultaneously build trust with hundreds/thousands of prospects and customers, in-product, at exactly the pace they want to go. Hyper-focused sales cycles at scale. This is a process that realistically (profitably) can only be run through software

• Software isn’t very good at navigating organizational complexity, addressing nuance, and building relationships. But people are. And when people are armed with real data points on how much value a customer is already getting out of the product… they become superhumans vs. their sales-led counterparts

The flexible PLG model allows companies to match the right resources (capability & cost) to the right type of activities performed during the sales cycle. And the result is better, faster, cheaper.

So why aren’t all companies using PLG business models?

I don’t think there’s a customer in the world who would rather sign a contract before getting value out of a product. So why doesn’t everyone use PLG?

Some product risk profiles are too high (read Business model fit).

Products with slow time to value, high initial commitments, and high business interruption risk don’t lend themselves to proving value before contracting. The risk associated with proving that value is too high, and needs to be addressed usually in an individualized way via a person-led sales cycle.

I expect that over time new technologies, e.g. AI/ML and robotic process automation, will bring the cost of new product consumption down so low such that proving value even for high risk/cost products will be doable before a contract is signed. We’ll see.

Persistent revenue growth is the key driver of equity value appreciation for cloud companies. Companies generate persistent revenue growth through consistently (1) growing TAM and (2) capturing TAM. These are some signals for each.

Why persistent revenue growth matters

But first, why this matters… the market values cloud companies as a multiple of revenue (see chart below h/t Jamin Ball).

Revenue x rev multiple drives equity value

If you’re growing faster, your multiple is higher. When your growth slows down, your multiple also comes down. This is called multiple compression and can lead to equity value stagnation.

The way to escape equity value stagnation is persistent revenue growth… continuing to grow at a similar rate year after year. If you can do this you can retain a high multiple that you apply to a growing revenue number, and voila… equity value!

But driving persistent revenue growth is hard.

The math is working against you. If in Y1 you grow at 100% from $1 → 2, your ability to grow at 100% in Y2 from $2 → 4 is much harder. In this example it’s a doubling of results for the same growth number.

This means that you can’t just do the same thing year after year and expect to drive persistent growth. Your execution needs to grow as well.

Companies generate persistent revenue growth through consistently (1) growing total addressable market (“TAM”) and (2) capturing that TAM with velocity.

Here is how they do it, and some signals to look for:

Grow TAM

The TAM of your product is the size of the problem(s) that it addresses. Companies grow TAM in three ways (h/t Jared Sleeper):

1. Market tailwinds - Solve a core problem that is itself growing. E.g. AWS’s TAM is growing as fast as the transition of + creation of new cloud software

2. Product extensibility - The product is flexible enough such that you can extend its solution to solve new problems. E.g. Airtable’s product is so flexible that you can use it to solve many existing and future collaboration/workflow-based problems

3. Product is a center of gravity - The product’s underlying asset can be leveraged to solve new problems. E.g. Salesforce turning its data model into a platform to enable 3rd parties to build on top of

The more of these TAM growth vectors a company can pursue, the better. Not only do you have more lines in the water, but they reinforce each other.

Capture TAM

Growing TAM isn’t enough to maintain persistent revenue growth. You need to make sure that you’re also converting that new TAM into revenue, i.e. capturing TAM.

And because revenue persistence is measured on a year vs. year basis, you need to do this quickly by reducing the cycle time between TAM growth + TAM capture.

Here are some signals that I’ve seen result in companies capturing incremental TAM with velocity.

Product

1. Customer’s COGS - Your product gets classified as COGS by your customers. As a company’s revenue grows, they expect their cost of revenue to grow ~in line with revenue, and operating expense to grow slower than revenue. So if you’re selling a product that is classified as COGS, you will have an easier time capturing the value of your product’s TAM growth. This goes hand in hand with volume pricing below.

2. Product flexibility - This TAM growth method has a built-in TAM capture advantage. Your product will only be used for new purposes if it’s already proving value. In which case the risk associated with directing that product towards a new problem is low, which will lead to low friction distribution

3. Fast time to value - adding more product modules that leverage your core asset to solve new problems is great. And it’s even better if there aren’t very long deployment cycles resulting in slow time to value. Slow time to value acts as a governor on your customer’s ability to consume more products, and thus your ability to capture that TAM at speed

Business model

1. Volume pricing - Volume pricing is an auto capture mechanism for incremental TAM from existing products. If the value of your product is tied to its usage, this is a no brainer

2. Product-led growth - As you might expect, coordination gets very complicated when you’re growing & capturing your TAM across multiple vectors. One way of simplifying this coordination is to let each of your customers decide how they want to continue growing with you - a hyper-focused business model - which is enabled via software and PLG motions

What would you add to this list? Let me know.

B2B SaaS products enable collaboration across business activities. These activities exist on the spectrum of workflow vs. workspace. Understanding the attributes of this spectrum helps one to make sense of both existing and new product categories.

The collaboration spectrum

As I wrote in Framework: B2B SaaS value props,

SaaS helps businesses to create value by enabling them to do two things:

1. Do existing activities more productively by enabling more outputs (or the same) with the same (or fewer) inputs

2. Do new activities that would be impossible or cost prohibitive if done by humans

Every business activity has a what and a why.

What. What activity are you doing? What activities tend to fall into a subcategory of analyze, plan, or execute.

Why. Why are you doing it? The why is how the activity supports the mission of the business — directional alignment. Alignment happens at the individual, team, and collaboratively across functions.

In this article I go deeper into collaboration. Business collaboration activities exist on a spectrum of workflows to workspaces.

Workflows defining principles

Workflows are defined and sequential. A set of homogeneous, objective activities that can be performed repeatedly to achieve outcomes.

Think of workflows as shipping lanes. You need to configure it to achieve the right outcome, and then it’s all about throughput.

An IT provisioning system is a great example of this. Configure your workflows to enable selection, approvals, and fulfillment. And then let the process run… over and over again.

Workspaces defining principles

Workspaces are undefined and free-form. The activities that take place in workspaces are heterogeneous and subjective.

This is where your creative collaboration happens. A work canvas is a great example of this. A place where tasks, documents, and communication can happen in an unstructured, collaborative way.

Implications

Defining collaboration tools on a spectrum helps one to understand some value prop trends in the B2B SaaS world:

• Robotic process automation (RPA) - workflows to the extreme performed by computers. The ultimate throughput deliverer for objective, homogeneous activities

• No-code - this is a newer category of B2B SaaS that lets you combine both workflows and workspaces. It gives “citizen developers” the ability to take a free-form collaboration approach to building their own workflow tools to solve niche business problems

• Data - There are multiple billion-dollar application businesses across the collaboration spectrum. What do they all have in common? They require data to deliver value. This illustrates how important and big the market for the data layer is

• Cost of collaboration - different collaboration activities cost different amounts. Pure workflow collaboration are more efficient and less expensive. Pure workspace collaboration is less efficient and more expensive

• UX - while consumer grade UX is now a table stake for any enterprise SaaS app, I’d argue it’s more critical if you’re building a workspace. You need a UX that is conducive to creative work. That is a much higher bar than UX that is conducive to process work, and getting it wrong makes that work even more expensive

Understanding collaboration tools

There is a spectrum for business software:

• On one end you have more structured workflows supporting enterprise management activities

• And on the other end you have tools supporting more unstructured, creative collaboration

This creative collaboration end is what I want to talk about today. Creative collaboration boils down to these activities:

• Defining - Defining and coordinating units of work. The core activity is typically a table or list entry e.g. task

• Create content - Execution of those units of work. For each task, create content document in appropriate form tool e.g. spreadsheet, text doc, slide, design tool

• Communicate - Communicate throughout before, during, and after definition and creation activities via email, instant message, memo, etc.

And all of these activities happen fluidly. In many different orders with starts, stops, and changes of direction.

Collaboration tool silos

Yet the tools we’ve grown up on at work don’t support this fluidity. The typical organization I’ve been a part of has operated as such:

• Defining units of work - pick your favorite task tool - Asana, Trello, Smartsheet

• Content creation - spreadsheets, text documents, slide presentations, design files

• Email for important communications

• Slack for synchronous and less important comms

What’s the problem here?

• Separate tools, each organized around its core activity i.e. activity-first

• Resulting in silod collaboration activities

Let’s take Slack for example. Great messaging tool. And while it’s trying to be “Where work happens”, it’s still where messaging happens. Or message-enabled tasks & content happen. But it’s message-first. Messages are the organizing activity of the tool.

They’ve made efforts to integrate the collaboration stack by embedding 3rd party tasks and content tools. But these collaboration activities are downstream of messages, treated as second class citizens. And if you want to context switch from message → content or tasks, you end up leaving the app.

Productive collaboration requires full context of all define, create, and communicate activities. But when a tool is organized as activity-first, the end user has only that activity’s full context. Which means partial collaboration context.

Work canvases

Enter the work canvas. Rather than an activity-first organizing principle, there is a new breed of tool that is activity-agnostic. These tools are canvas-first. A blank space upon which you can add units of work (tables, lists, tasks), create (tool native) and embed (3rd party tool) content, and communicate seamlessly in one place.

In canvas-first tools, define, create, and communicate activities are all treated as interoperable first class citizens. These canvases support the fluid nature of projects by enabling full context & activity switching regardless of which activity step you’re working on.

This is the future of creative collaboration at work.

Players and adoption

Who are building these tools?

Pioneers like Notion, Coda, and ClickUp have been building canvas-first for years. And as of writing this each of these companies are worth in excess of $1B.

Incumbents like Google (announcing in May 2021) and Microsoft (announcing just this week Nov 2021) are also heading in this direction.

How is adoption going?

Pioneering canvas-first tools have been taking market share in both younger companies and within teams of larger organizations. But I have yet to see a large organization go wall-to-wall with a canvas-first tool.

But now that enterprise-trusted vendors such as Google and Microsoft are bringing their versions to market, I expect we’re not far off. Their offerings will also be very compelling as they can embed their own native (vs. 3rd party) task, content, and communication tools right on top of their canvases. These tools are already widely used throughout enterprises which give them a big head start for winning the next era of collaboration software.

I for one am excited for this new way to work.

A business exists to create value for its shareholders. This value can be anything - profits, social benefit, etc. Businesses memorialize the benefit they aim to create in their mission statements.

So if a business exists to create value, then by extension the activities and technology tools it uses are all in pursuit of this same end.

One of the tools that businesses use to create value is SaaS — software delivered over the internet.

SaaS helps businesses to create value by enabling them to do two things:

1. Do existing activities more productively by enabling more outputs (or the same) with the same (or fewer) inputs

2. Do new activities that would be impossible or cost prohibitive if done by humans

Organizing business activities

Okay - so SaaS enables better activities. Which activities? Every business activity has a what and a why.

What. What activity are you doing? What activities tend to fall into a subcategory of analyze, plan, or execute.

Why. Why are you doing it? The why is how the activity supports the mission of the business — directional alignment. Alignment happens at the individual, team, and collaboratively across functions.

Bringing it all together

In summary, businesses use software because it:

• Enables more productive or novel activities,

• Which support analyze, plan, and/or execute actions,

• That directionally support your business’ mission,

• Either individually or through cross-functional collaboration

So what?

With a framework in place to understand why businesses use software, you can start drawing implications about the B2B SaaS ecosystem. Including how products address the business activity spectrum. Here are some examples that have been running through my head, which this framework helped me clarify:

What business activities does a given business address?

For example, Slack. Slack started out as a communication platform and has evolved into an end-user facing interface connected to other applications. It’s tagline “Where work happens” tells you everything.

They aim to be a communication interface that sits on top of other applications that collectively span the entire business activity spectrum. Enabling directional alignment and cross-functional collaboration across plan, execute, and analyze activities.

That is a very aspirational place to sit.

Why do businesses adopt certain business models?

As I wrote about last week, product-led-growth (PLG) is the distribution model that supports less risky products. Or products that carry out less risky business activities.

Businesses with PLG distribution models assert power to the employee. The employees, not executives, are best positioned and empowered to pick the tools they want to most effectively perform their business activities.

How might disruption in SaaS occur?

Historically the cost to build software was high. So businesses who could bear the costs specialized and built software for others to use.

These costs are no longer high. And are coming down more every day. The no-code movement is an example of this… enabling citizen developers without engineering backgrounds to build complex applications.

B2B focused no and low-code platforms assert that business users (or developer business partners - new job?) will create higher match quality software, thus unlocking more productivity, than a 3rd party will.

Your product has a risk profile that creates a barrier between prospect and happy, growing customer. Your business model’s job is to reduce these risks through trust building. But reducing the risks at all costs isn’t good enough, you need to find the right balance of reducing risks at velocity.

Business model fit

I like to organize a SaaS business into three key areas: market, product, and business model.

• Market is the universe of people who have a problem, or a job to be done

• Product is a solution to the problem that you build with technology

• Business model is the engine that connects the product to the market

Without a product, you don’t have a business. And without a business model, you can’t grow.

The order here matters

Market <- Product <- Business model

The product solves the market’s problem. The business model pushes that product into the market.

So then the key to building an effective business model is to look at your product. Specifically… you need to assess how risky your product is.

Product risk profile

Your product has a risk profile, made up of:

• Product-market-fit (PMF)

• Time to value

• Initial commitment requirement

• Business interruption risk

And these risks create a barrier between prospect and happy, growing customer. Aside from PMF, what do these risks have in common? They describe costs.

As a prospective customer, I need to consider how much it will cost before I get to the promised value on your product. These costs are more than just money. They include things like time, capability (will I even be successful?), change management, etc.

Your business model’s job is to reduce these risks such that the prospect can get to “Yes”

Your business model reduces these risks by addressing the costs through a process of trust building. The prospect needs to feel confident that they understand the costs and that they’re acceptable in exchange for the value your product provides.

Balancing risk reduction

But you can’t just address the costs, you need to address the costs in a way that doesn’t slow you down or cost you too much.

You need to find balance. Just the right amount of hand holding to overcome the risk profile in a way that keeps your business moving quickly and profitably.

All things equal you want a low touch, high velocity business model. It’s both faster and cheaper - for you and for your customer. This is why product led growth is winning.

But some products have such high risk profiles that they need high touch, low velocity cycles. Think replacing a general ledger, or a payroll system.

Business model design

So what can you do? 

• Map out your product’s risk profile

• Stack rank your biggest velocity inhibitors

• And figure out how to reduce the risks, one by one. Either in the product or in your business model

Like PMF, business-model-fit is not one and done. Your business model lives and breathes. And you need to be constantly innovating to fit an evolving market.

Of course, none of this matters if you don’t have product-market-fit. So focus there first.

A successful SaaS business requires getting three things right

• Market

• Product

• Distribution‍

Market‍

• Market is the number of “people” who have a problem that you want to solve

• Your market influences everything your SaaS business does

• Including how big your business can be

Product

• Product is a software asset that you build to solve the problem

• Solving a meaningful problem well makes you indispensable

• If your product is indespensible, you have product-market-fit

Distribution

• Distribution is an engine that connects market + product

• It cycles over and over (1) finding prospects in your market, and (2) convincing them to use your product

• Cycling predictably and profitably is called product-distribution-fit (my name for it)

Valuation

• If you get market + product + distribution aligned, you’ll gain market share

• The value of your SaaS business is a function of

• → size of market

• → speed of market share gains

Iterating

• ‍‍Creating this alignment once is hard, and usually not good enough

• Each is a moving target

• Market needs change

• Product competition intensifies

• Distribution channels get saturated

• Enduring success means constantly innovating + reinventing