Why don't enterprise pricing pages have PLG content?
Not placing content on the /pricing page is a big miss for companies

Why don't enterprise pricing pages have PLG content?

One of the best things about a product-led growth motion is that you can jump in and try out the product. If you’re the kind of person who likes to use a product before you commit to paying, PLG works great for you.

There are a few things that need to be true for this process to work:

  • When you try something, your attention span is pretty low. You might give it only a few minutes to decide whether it’s worth your time to continue.
  • And if you arrive at a product thinking it will do one thing and then don’t determine how to do it using your initial try, you might easily become a lost or unactivated trial.
  • If you encounter a fun thing to do that is different than the job you hired the product to do, you might give it a try anyway.

When new users find a feature in the product they were looking for, and it works better than a substitute they already have, they are definitely interested in trying things out. If the price is attractive, for some prospect it’s an instant sale. After all, they might be buying for only a month at a time. For other prospects, it only takes a little convincing to click the Upgrade or Buy Now button.

This is the whole point of PLG: when you sell software as a service and the marginal cost of letting someone try your product is zero, let a person try it before you ask them to pay. The place you find that content, of course, is the pricing page. Whether you reveal pricing immediately or on your pricing page depends upon you, and that’s where the buyer goes to figuratively “kick the tires” on the experience.

Knowing the price point helps them to know whether to continue the conversation.

The enterprise software sales process doesn’t feel like that experience at all.

Welcome to the car dealership

Arriving at an enterprise software pricing page might be one of the most disappointing bait-and-switch exercises ever. You arrive at the home page, see an amazing video or a compelling use case, and click Pricing.

The content of the page looks something like this …

Name, company, and email look like standard options. But what’s a seat? Is it how many people will use the software every day, or only once? How am I supposed to imagine how I would use this software if I don’t even know how it works and I can’t know until I see a demo?

It feels a lot like the experience you get at a car dealer once you’ve told them you want to buy, and then they ask you to go with the finance team “to look at some details.”

Here’s what’s missing from the experience:

  1. Knowing what this will cost as my usage changes
  2. Validate that the product does what I need before I commit to a contract
  3. Try the product without help from a sales engineer or a fancy proof of concept

What if enterprise buyer engagement looked different?

Let’s presume for a moment that there are some very good reasons that enterprise software teams might not want a brand new prospect trying out their software.

They might look like some of these possibilities that both buyers and sellers would agree are true:

  • Brand new prospects don’t know how to use this complicated, powerful software
  • When misconfigured, the software appears not to work even though it has the capability to deliver what the buyer is requesting
  • We only have the time and capacity to deal with qualified buyers because building demos takes time and money

The form you fill out might look a bit different, giving you options like these..

Just looking…. means exactly that. I am looking at your website and I’m not ready to go through a sales process. I might change my mind but I’m not ready to engage yet. This is a buyer who is researching but not really in the buying cycle. Having a meeting at the moment is a waste.

One thing the company could do for me at this point: suggest the questions I should be thinking about to use their software better, and where I could learn more about them.

I want to learn … means there is a learning path you can set me down that might eventually qualify me for a demo. It might not be this week or this month, but learning more about the problem set, your company’s solution, and the overall things I should be considering will help me appreciate that this is a hard problem and that I need help.

I’m expecting … to be referred to useful content in the form of videos, support articles, or case studies that are relevant to my research area.

Can I see a demo? I’d like a demo … although you as the software sales team don’t know yet whether I am a great demo candidate. I might want to see what you’re doing. I might want to talk to you to see how you pitch the software. To qualify me as a solid candidate, there needs to be some discovery to see if the problem I’m trying to solve matches up well with what your product does.

I’d like to know … how long a demo might take and what hoops I have to jump through to see the product.

Can we talk? None of the options so far match why I arrived, and I’d like to talk to a real person. What is the typical conversation about at this point? You might even point me at some helpful content to demonstrate how you help other customers.

I’m looking to be treated fairly and in plain language.

How we price our software - let’s not waste anyone’s time. I know this is typically set up so that the sales team has a chance of converting an initially uncooperative buyer, but get real. If you’re selling something for $50,000 and my budget is $10,000, this is a waste of time. And if you’re not willing to give me an order of magnitude answer or some other way to calculate the price - I’ll use vendr or another service or go to your competitor.

What I’m looking for? A realistic statement of how you arrive at the pricing for your software. If you’re not willing to share an exact amount, I’d like an order-of-magnitude calculation, along with an explanation of the levers that cause more or less spending. Explain your business model, and how you’ll treat my company when it comes to renewal time.

A way forward for seller and buyer

There’s a lot of room for improvement in the buyer enablement (and seller readiness) process. If you break it down to a few key tenets, what we’re looking for here is simple:

No one wants to waste time buying and selling software

It’s really frustrating being on either ends of a selling process where you feel you’re not getting your questions answered or where you feel oversold.

It’s also disappointing to get buying signals from a customer who doesn’t really intend to buy and who is manipulating the process to do research.

Buyers want to try things out and to get help when needed

When you are looking at software to solve a problem, it is a lot more realistic (especially if you are a doer) to expect to try it out. And then ask for help when you need assistance.

There’s another profile of folks who want to read exactly what to do and then try it out.

Sellers want buyers to ask for what they need, not for everything

Sellers have a hard time closing business in the enterprise software world. Deals take a long time to form, and often even longer to close. That means they are working with multiple contacts at each account and need those contacts to ask for what they need, not for everything they want.

When those buyers inevitably ask for the things they want, sellers need help – both from the people on their teams and from the customer teams – to identify the real need and answer that question.

Buyers want you to demonstrate the benefits

Buyers want real value and information, not just sizzle.

That means:

  • Sharing video case studies where the customer tells you about their process

  • Making expert users available to them through video examples where they demonstrate a capability or a use case with the software
  • Creating a “cheat sheet” for the buyer with a list of items they need to gather or do before a demo would be successful or likely useful
  • Having a “hotline” where buyers can ask questions from real people. This one might be expensive, so you can definitely see the way to building an LLM (large learning model) trained on your documentation to have a Chatbot that could provide first-level buyer support

The current process of enterprise sales needs to be more like how PLG companies sell their product, where:

  1. You can try things out immediately
  2. It’s possible to see how you would use this in context
  3. There are well-known paths to trying out the functionality

What tools could you use to improve this?

But wait, you say. There are some situations with enterprise software where the marginal cost of adding a user is much different than zero. All of the strategies in the world described above won’t help you to spin up a giant database moving lots of data when that costs money that you expect the client to pay for.

There are many demo platforms today (Walnut , Navattic , Tourial , Demostack , and more …) that help you build a set of screens (basically a React-native app that’s a copy of your application) and tell a story for the customer. It’s the happy path you’ve been waiting for, where the customer can try out the world of your software without having an actual sandbox or trial instance.

If the process you’re sharing is relatively simple, congratulations! This is a great way to suggest how users might try your enterprise product without expending a lot of effort to create each demo. Almost all of the platforms are great tools for explaining a process where there are a small number of options, and when the software doesn’t change that often.

And if the process you’re trying to explain is complicated?

You’ve just created a parallel engineering effort to manage demo content, even if it’s no-code demo content. Your demos are unqualified. It’s hard to find the people in the org who really care about a demo. Good luck finding new AEs or SDRs who can demo effectively.

There are a couple of teams working on making this easier that are taking a slightly different tack on the problem, letting you create an integrated journey per prospect that incorporates a variety of resources for that prospect. Think of this as a “Content Management System for Demo Content”, or a “choose your own adventure”-style of interaction. Both Consensus and Demoboost advocate this approach, where you focus on the customer journey and away from a one-size-fits-all set of screens for your demo.

Enterprise software needs to get at least a little bit more like the experience we see when trying and buying PLG products. It makes sense that it’s not exactly the same, but it could be a lot better. If you’re just getting started and you need some data to help you decide where to optimize, Kyle Povar’s pricing theory is an excellent first read.

What’s the takeaway??When buyers want to learn more about enterprise software, they’d like the experience to be much more like the one they get when they are trying lower-cost, try-before-you-buy software. That means giving them at least the taste of how it feels to use the thing and much more information to make the process feel more interactive. Don’t be like that car dealership - let the buyer come to you.



Alan Berkson

Market Strategy & Messaging | "API For US GTM" | Focused on corporate narrative and aligning messaging across brand, GTM, and product

10 个月

Makes me think there should be a companion to the SDR that is a "Research Assistant". Takes away the pipeline generation pressure of the sales process. Essentially help potential prospects with the first two buttons (Just looking, I want to learn), building trust in your brand without feeling pressure to buy or sell. This could be part of the marketing team, or even better, the community team.

回复

要查看或添加评论,请登录

Greg Meyer的更多文章

  • Redefining the Customer Journey

    Redefining the Customer Journey

    Have you ever played RevOps detective? ??? The story goes something like this. There’s a closed-won (or a closed-loss)…

  • Going from 0-1 in Data Operations

    Going from 0-1 in Data Operations

    Imagine you are starting a new venture and need to describe all the data tasks that need to happen to get you from…

  • An ode to console.log()

    An ode to console.log()

    Some of the first programs I ever wrote on a computer used PRINT to echo a line to the screen. Using BASIC, I filled…

    1 条评论
  • Great performance demands mental preparation

    Great performance demands mental preparation

    The coach will see you now When I was younger I wanted to be a professional baseball player. Professional baseball…

    2 条评论
  • Data Operations, revisited

    Data Operations, revisited

    When I started writing about data operations In 2020 I suggested an example definition that focused on data shared…

  • From Atoms to Bits: Building Software from Cow Paths

    From Atoms to Bits: Building Software from Cow Paths

    It’s not easy to be a technologist these days. For almost any problem you can think of, there is a solution claiming to…

  • Am I typing to a person or a bot?

    Am I typing to a person or a bot?

    Dear Bot, may I speak to your manager? It seems like almost every company with a large volume of customer requests is…

    3 条评论
  • 10 common ways your revops data enrichment might be failing

    10 common ways your revops data enrichment might be failing

    Picture this: you have a million contact records to fix and need to find a title match based on email and determine the…

    4 条评论
  • Creating a "Minimum Viable Record"

    Creating a "Minimum Viable Record"

    What kind of data belongs in a “Minimum Viable Record”? There’s a lot of pressure on sellers today to hit activity…

  • What do you need to build a good no-code application

    What do you need to build a good no-code application

    There’s a lot of promise in a no-code environment. No-code development lets you abstract the building blocks of an…

    3 条评论

社区洞察

其他会员也浏览了