What I learned while building a Product-led Growth (PLG) engine
I am a visual learner, and over the years, I have found that the best way to learn a new software/technology is by experiencing it like an end-user. When I joined Nutanix, I was trying to figure out the software stack, so I got my hands on an Intel NUC, a copy of the Nutanix community edition, and went to work. I clearly underestimated the effort, and being a slow learner, it took me a couple of days to finally get everything up and running before I could try things out.
A few days later, I was sharing this experience with a colleague when I found out that someone in my team had already figured out how to run the entire Nutanix stack on a virtual machine on Google Cloud. It was called Test Drive.
Anybody could go to a browser, fill out a form and get their hands on a Nutanix cluster through this mechanism. This was amazing, I thought. What if we could take it further? We assembled a team of Technical Marketing Engineers and started thinking about how to use Test Drive to enable our customers to experience the entire Nutanix stack in an entirely zero-touch fashion but in a meaningful way.
Fast forward a year later, and thousands of people have experienced Nutanix through Test Drive, and the impact it has had on our go-to-market strategy has been profound, to say the least. In this period, the number of Test Drives per day has gone up by orders of magnitude, and unbeknownst to us, we had embarked on a journey to build a product-led growth engine.
What is product-led growth?
In a traditional B2B marketing strategy, you typically build a set of high-quality content like blogs, white papers, webinars, etc., and place them behind gated landing pages, aka web pages with forms. In this methodology, you drive traffic to these landing pages and the content, either organically or through paid programs, and improve the conversion rate of people coming to the landing pages and filling out forms to access the content.
This is the classic marketing-led growth strategy.
On the other hand, product-led growth is built on the premise that you want to put your product in the hands of your customer as quickly as possible. If a product-market fit exists and your customers love the product, you stand a better chance of building lasting relationships with your customers than trying to engage with people who may be only interested in the content and not the actual product/solution.
This methodology doesn’t necessarily replace the strategy of building high-quality content. Still, more recently, it has proven that companies like Slack, which relied heavily on a product-led approach, had a far-reaching impact on overall customer experience and satisfaction and consequently on overall growth.
Within a product-led growth methodology, there are a few different ways to get the product out, for example, trials and fremium, and there are pros and cons to all of the approaches. In this article, however, we will look at an option called Test Drive, which is distinct and separate compared to both.
What is Test Drive, and how is it different from Trials?
When it comes to digital products or products that also have a digital experience, I firmly believe that customers should always be in control of their experiences.
The customer should decide when and how they want to try out a product and make their own assessment of how the product/solution could help them solve a problem. If you believe this then from a customer perspective, product-led experiences should be a continuum.
The customer journey should start from a point that has zero barriers to get started, for example, a Test Drive that serves a broad segment of users, to a more personalized experience where customers can try out the product to solve their specific use cases, example a trial.
In general, I believe a Test Drive experience should have two specific attributes — 1) It should have demo data and use cases that address the maximum number of users, and 2) the experience should be limited in time, typically a few hours.
Why?
Because you want to separate users who may be just curious from those who may be genuinely interested in buying the product. Those who are only interested in the product will be OK with the limited time and the demo data they get to play within Test Drive, but those who are really interested would likely raise their hand to request extending the Test Drive experience. This is where a trial experience comes in.
Needless to say, there should be a seamless bridge from a Test Drive experience to trials for users deciding to make this jump.
In the last 14 months or so since its launch, we were lucky enough to witness a growth that far exceeded our expectations, and what follows below are some learning lessons that I hope others on a similar journey can take advantage of.
#1 Experiment with everything:
Every single feature and design change that we added to the Test Drive experience started as an experiment. Early on, we decided to experiment as often as possible, but only if we had a hypothesis and only if there was a way to measure if our hypothesis was correct.
If it turned out that the hypothesis was correct, we would flip the switch on our experiment and double down. If it failed, we would kill it and move on to the next one. Turns out trial and error is not just a strategy but also a team muscle memory that keeps opening new avenues.
#2 Shortest time to delight:
I have seen some experiences that require users to fill out lengthy forms, and once you are done, you receive an email saying someone will get in touch with you to assess your needs and/or approve your request for a Test Drive or a trial.
Imagine if you walked into a car dealership and expressed your desire to Test Drive a car, and after you go through the process of filling out a long and often invasive form, you are told — “Someone will get back to you soon.” Worse, that someone who does call you a few days later turns out to be someone from sales who asks more questions and tries to sell you the car throughout the process.
One of the early hypotheses we experimented with was that people who were signing up for Test Drives had little tolerance for filling out lengthy forms on the web page, so we decided to test the idea of removing the form from the page.
We ran an A/B test between the page with the form and another one that replaced the form with an email address field. We split the traffic on the two variations of the page and ran the experiment for four weeks.
The variation of the page with just an email address field won the experiment by an overwhelming percentage. We no longer have a form on the Test Drive page, and the conversion rate on the page has been exponentially higher than the industry standard of 2.5% on a typical landing page.
#3 Know your customers:
After a couple of weeks of launching the Test Drive experience, we realized that a good portion of the users spent a significant amount of time within the app.
On a closer look, we discovered a majority of the users were IT practitioners.
This made us look at the Test Drive experience slightly differently when coming up with new features. Our key constituents were technical and “hands-on-the-keyboard” users of the product, so we created a few different Test Drive experiences.
For example, if you want to learn about disaster recovery, there is a different Test Drive experience. If you want to learn more about database operations, there is another type of Test Drive experience. You want to learn more about automation and operations, well there is a Test Drive experience for that as well. Each of these experiences is listed on the same page and comes preloaded with different kinds of data and prompts so that practitioners can self-select an experience that fits their persona and use cases.
Besides, if you are interested in a deeper dive of a particular use case after going through the main experience, we enable that as well directly from within the app.
#4 The customer is always in control:
Product owners will often tell you that it is scary to expose your B2B application to net new users in a zero-touch fashion, as it typically requires a lot of context setting and explanation before you jump in to demonstrate the main UI to your audience.
We thought about this and decided we will still favor a zero-touch experience, but we would add guardrails so that when the users need help, it would be available in an on-demand fashion.
We did this by adding two core design features that have been a staple to the entire experience.
First, within Test Drive, we overlaid step-by-step tutorials that explain some key concepts and walk the user through some basic features in a guided experience. A key thing to note here is that you want the user to be able to altogether bypass this if they prefer and come back to it any time they feel they need help.
Second, we added a chatbot backed by humans during business hours so that when users have a question, we try to help the customers in real-time. With our choice of the technology stack, we were also able to connect our chatbot to our internal slack channels so that the subject matter experts could monitor and answer questions as they come in.
#5 Extend the experience continuum:
I am a firm believer in the fact that seeing is believing, so if there are people who genuinely want to experience your product, you should remove any friction for them to try and touch your product.
This should be a truly “form-less” experience that allows your customers to experience the base and probably the most essential parts of your application through nothing but a browser and internet connection. Once they are in the experience, though, and you have built some credibility, you should have links to other Test Drive experiences and trials where appropriate so that users can extend the experience if they choose to.
When the experience is extended, make sure there is a seamless hand-off, and you are not asking the users questions that you already may know the answer to; for example, what use case do you want to use the trial for?
#6 Organic vs. paid campaigns:
My experience and opinion have always been that when it comes to hands-on-the-keyboard customers and IT practitioners, the focus should always be on building content that tries to help, not sell.
In addition, the content should be easily searchable and ideally tie back to problems that the product solves, not about trying to sell the Test Drive or Trial experiences. Besides, once the users are in the app, stay away from trying to sell anything either within the app or through re-targeting.
Remember, product-led growth works on the premise that the product-market fit exists, and the more people who touch your product, the more people would love it and end up being your long-term customers.
#7 Go to the watering holes:
When it comes to generating traffic to the Test Drive experience, we looked at existing traffic on other sister web properties and figured out several users were coming to our customer and education portals. We decided to add single sign-on in these portals, so if you are already signed into one of the other Nutanix web properties, we let you into Test Drive without even requiring you to put in your email address.
In general, you don’t want users who have already filled out a form somewhere else on the website or signed into a customer portal to come to the Test Drive experience and have to fill out a form again. This goes back to the principle of removing barriers.
Don’t ask a question that your customer may have already answered somewhere else on the website.
In addition, we figured out that many users taking Test Drives were also coming in from our partner community, and we decided to work with some of them directly to see if they can embed Test Drive within their web properties. Just by going to the watering holes within the different web properties, we could hit a few inflection points along the way.
#8 Build a cultural phenomenon:
Every once in a while, we see a sudden surge in Test Drive usage. When the alerts start going off, and we hear chatter on some internal Slack channels; usually, we find out that someone within the organization is running some sort of an event or a bootcamp using Test Drive.
In my mind, the best kind of growth strategy is the one where the adoption and growth happen organically through word of mouth, both internally and externally in the organization.
The lesson learned here is if you pay attention to the user experience by making it easy, internal and external users would start using the experience for demos, education, etc., and the adoption will eventually spread through word of mouth.
When you do find out that people are using the experience in unintended ways, my suggestion would be to try and talk to the users and make things easier for them by removing friction and barriers even for the secondary uses of the experience as long as it does not conflict with the main use case.
#9 Simplify your technology stack:
When it comes to the technology stack, integration is the name of the game as the experience you create will not exist on an island and will be interacting with the core product on the one hand and your CRM and other marketing applications on the other.
The need for integration inherently drives complexity, and I found that if you don’t think through each feature request, the architecture ends up being so complex that it becomes slower and harder to experiment over time.
I also firmly believe that user experience should dictate the technology decision and not the other way around.
The lesson learned here is to maintain a balance between integration sprawl and feature requests on one hand and user experience and the ability to experiment fast on the other.
Two other essential factors to keep in mind when it comes to technology stack are scalability and cost. As marketers, we all want to hit a hockey stick curve when it comes to demand, and some of us who are lucky enough to experience this also have to consider that the architecture is scalable and can handle sudden bursts in demand while at the same time keeping the costs in control. This is especially true if your experience runs in the cloud, where you pay for what you use, and your use suddenly goes up.
We learned that cloud is excellent when you are experimenting with growth, but once you hit a few inflection points, start thinking about how you can take the predictable workload and run them in a hybrid architecture. This is critical to the overall P&L of the “business.”
#10 Close your business:
One of the most prominent champions for Test Drive within our company was our former CEO, Dheeraj Pandey. Early on, he asked us a simple question — “Tell me how do you plan to close your business every week, every month, and every quarter.”
This prompted us to think through the success metrics that we needed to track weekly, monthly, and quarterly. Since its inception, we have created dashboards and managed to track the metrics week after week and see if we are headed in the right direction. This includes usage and growth metrics on one hand and the impact of Test Drive on business on the other.
In addition, you also want to put alerts and notifications in place so that you are aware when sudden bursts in demand happen and can intervene as and when needed. Just by “closing” the business week after week, we have been able to come up with hypotheses that we continue to test consistently.
It has been truly a privilege and an immensely gratifying learning experience working with some outstanding team members who took the idea of Test Drive and turned it into a significant go-to-market strategy.
I understand that the best practices and the lessons listed here may not apply to everyone and every product out there, but hopefully, the main highlights can help you think through a new way of driving your product’s adoption in a zero-touch product-centric approach.
Feel free to comment here or reach out to me on Twitter/LinkedIn if you have any feedback or questions related to this article.
