Why can't enterprise sales learn from PLG?
It's easy to try out a product-led growth product. That's the point. Why do enterprise sales teams insist on closing to an immediate demo? "Everything Starts Out Looking Like a Toy" #147
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? is a post that grew into Data & Ops, a team to help you with product, data, and operations.
This week’s toy: Rooms.xyz, which I’m not really sure how to describe. It feels like a cross between Minecraft, Animal Crossing, and various other low-fi games, except you can build your own experiences. It could be an experience building platform, not just one where you interact in-world. Edition 147 of this newsletter is here - it’s May 30, 2023.
Brought to you by Pocus, a Revenue Data Platform built for go-to-market teams to analyze, visualize, and action data about their prospects and customers without needing engineers. Pocus helps companies like Miro, Webflow, Loom, and Superhuman save 10+ hours/week digging through data to surface millions in new revenue opportunities.
If you're reading and haven't subscribed (yet), give it a try! And if you have any comments or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ What if enterprise software was more like PLG?
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:
Knowing what this will cost as my usage changes
Validate that the product does what I need before I commit to a contract
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:
You can try things out immediately
It’s possible to see how you would use this in context
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.
Links for Reading and Sharing
These are links that caught my 👀
1/ Most people haven’t tried ChatGPT - Although it seems unlikely given the level of press coverage a lot of people have heard of ChatGPT but not many have actually tried to use it. This research from the Pew Research center is a few months old, so undoubtedly more people have tried this tech out since this survey, but it’s fascinating to see the gap. Another callout here → it’s going to be used to learn new things and for tasks at work.
2/ Watch this, then don’t do it - Who among us has signed up for a subscription service, and then wanted to cancel? It turns out that some product designers use UX dark patterns to keep us from doing that. Here are some patterns to watch out for, and to avoid using in your own apps.
3/ You don’t need a modal - This is a simple idea, explained well. Instead of creating modal windows in your apps, create bookmarkable detail pages. Most of the time, you don’t need modal windows.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon