👓 Packaging, pricing pages, and motivations for motion

There’s a lot of great content out there about pricing page design.

This post is presented by Sprig - build a product people love.

Sprig is an AI-powered platform that enables you to collect relevant product experience insights from the right users, so you can make product decisions quickly and confidently. Next-gen product teams like Figma and Notion rely on Sprig to build the user-centric products people love.

At Snyk, Sprig was an indispensable part of our product stack, and now, readers of The Product-Led Geek can get 10% off!

In those posts, you’ll find advice such as …

• Show features as a waterfall increasing in length with plan tiers

• Establish trust through social proof

• Place CTAs are above the fold

While nothing in these lists holds universally true in every scenario, they’re useful pointers as you experiment with and evolve your pricing page.

In my experience though, one principle really is universal.

You need to convey who each plan is best for.

When a pricing page doesn’t immediately make it crystal clear which plan is right for me, it’s a problem.

And I’m not talking about plan recommendations (often done poorly btw), but something much more basic - enabling self identification of which plan I should choose.

Most often, if that’s difficult to do, it’s because of poor upstream packaging decisions.

In this post, I want to share some first principles thinking that I apply every time I’m involved in packaging decisions and pricing page design.

Three core questions in plan design

Your pricing page should be the perfect translation of your packaging decisions.

When designing your packaging, and thinking about how to best communicate that packaging on your pricing page, there are three important questions you need to ask and answer:

1. What problem or use case does each plan solve?

2. For whom?

3. What is the motivation for motion between each plan?

Let’s break each of these down…

1. What problem or use case does each plan solve?

Every plan must solve a different primary problem / address a different primary use case.

Most often, each incremental packaging tier is additive in the problems it solves.

Each plan will often solve multiple problems and address multiple use cases, but it’s critically important to identify a distinct primary use case that forms the core of the plan, as this is what you’ll typically highlight in the plan messaging.

2. For whom?

Who are the user and buyer personas that each plan is targeting?

At what type of companies?

For example:

• User: Product Managers

• Buyer: Head of Product / VP Product / CPO

• Companies: Mid-size (50-250 employees)

If you can’t unambiguously answer this question for each plan, you still have work to do.

This should be in strong alignment with your ICP definition.

It’s common that plans target different buyer personas.

Your pricing page will need to reflect that.

To give an example, consider Snyk. When companies reach a certain size, the ultimate responsibility for application security typically shifts from engineering (e.g. under a CTO) to a dedicated security function (e.g. under a CISO).

Snyk’s Team plan is designed to cater to smaller companies where the buyer wits within the engineering organisation and where ACVs are typically below the sales floor. Snyk encourages a self-serve monetisation approach for this plan. The Snyk Enterprise plan focuses on larger companies where the buyer belongs to a separate security function. Given the typical organisational dynamics at these companies, Snyk know that a human facilitated sales process is typically necessary.

Remember, different buyer personas will place different value on any given set of features.

When you understand the buyer persona, you’re able to create messaging and pricing page copy that deeply resonates with your target audience.

Additionally, you get crucial input to determine the best feature inclusion and usage thresholds for each of your plans.

3. What is the motivation for motion between each plan?

As part of their excellent Monetisation & Pricing course (shout out to the creators Elena Verna, Dan Hockenmaier and Patrick Campbell), Reforge has a great worksheet for thinking about packaging:

But an extra level of fidelity that I think is important to explore is the motivation for motion between each plan.

Why would a customer want to move up your monetisation tiering from Plan A to Plan B, or from Plan B to Plan C? And similarly, why might they move down the tiering?

What triggers might create the impetus for that movement?

Could you create or influence any of those triggers?

The features in a plan aren’t why a company upgrades. It’s the use cases that combinations of features unlock.

And different triggers will make those use cases relevant for your customers.

Each plan will often solve for more than one significant use case. Even if your pricing page focuses on the primary use case, try to identify each use case enabled by a distinct combination of features.

The use cases are the first level of motivation.

e.g. ‘ACME Corp now has this use case’.

It is important to understand why this use case is now relevant to your customers when it wasn’t before.

Often, an underlying reason is scale.

Your customers have grown (or the adoption of your product has spread wider within your customers), and as they’ve grown, they’ve encountered a new problem they need to solve.

In the Snyk example I shared earlier, the primary use case for the Enterprise plan is org-wide security with centralised governance.

But scale is too blunt a description of the trigger for that use case.

When a separate security function is established, it implies a shift in security ownership (and buying authority) away from engineering. That’s the real trigger.

However, other reasons exist beyond scale.

Take Amplitude as an example. Their primary use cases are around analytics. But they have various other use cases, including those around dynamic management of code through feature flagging.

Their Starter plan provides basic feature flagging support, supporting use cases such as:

• Progressive delivery with canary releases

• Shipping faster by decoupling deployment from release

• Testing in production

• Kill switches

• Providing limited user/team access to functionality (e.g. early access)

• Refactoring code using branch by abstraction

Their Plus plan allows programmatic management of feature flags, providing much more flexibility in runtime automation.

The experimentation use case requires teams to upgrade to the Growth plan.

The same foundational feature flagging technology serves as the basis for all these use cases, but different combinations of features unlock different use cases.

Here, the motivation for motion is around increasing DevOps maturity.

How many plans?

A quick note on this - more plans mean less plan-to-plan differentiation, and the motivation for motion between each plan is diminished.

There must be compelling motivation to move customers upwards through your tiers.

3-4 plans (including any free plan) is typically the sweet spot to support upward movement while minimising pricing confusion and cognitive overload.

You want to enable prospective buyers to rapidly self-identify with a plan.

Having more plans can often make it more difficult for a buyer to quickly identify a plan that suits their needs. 

There’s more that goes into defining effective pricing and packaging and designing an effective and high-performing pricing page, but focusing on these fundamentals and having solid answers for the three questions I outlined above will help get you started on the right foot.

This post was presented by Sprig.

Until next time!