Product Adoption Platforms: What You Need to Know About the Buying Process

Product Adoption Platforms: What You Need to Know About the Buying Process

Continuing the PAP Buyer's Guide series, this article gives you all the ins and outs of buying SaaS, from initial inquiries to concluding a successful trial.

Camila Cury
16 min read
Product Adoption Platforms: What You Need to Know About the Buying Process

Welcome to Part 3 of Chameleon’s Product Adoption Platforms (PAP) Buyer’s Guide. This is an ongoing series intended at helping SaaS buyers navigate through the whats, whys, and hows of Product Adoption Platforms. 

Make sure you’re all caught up 🤓

👉 Part 1: What Are Product Adoption Platforms and Why Should You Care 

👉 Part 2: Your Business Case for Building or Buying + 9 Key Use Cases

So far in this series, we’ve covered the role of Product Adoption Platforms in detail, describing the variety of use cases they can serve and what you should be looking for when investing in this kind of tool. 

We’ve also helped you weigh out whether you should build a product adoption software in-house or buy one, and we’ve walked you through how to outline your goals for this investment. 

In this part, we’ll prepare you to begin the buying process, guiding you through your initial discovery and demo calls with sales teams, and giving you a framework for running an effective trial.

TL;DR
  • The buying process starts with the discovery call – a coffee date-like meeting where you establish whether the product is a good fit

  • There are a number of guidelines you can follow to make the best of your time in the discovery call. The #1 of them: be clear about your needs and wants.

  • Establishing what is the issue you’re trying to solve, why it matters, and what success will look like are some of the steps you can take to prepare for a discovery or demo call - you can jump right here for the full prep sheet 😉

  • The discovery and demo phase is followed by the free trial, a time to test out the mechanics of the tool and determine whether it fits your criteria for the ideal product adoption software.

  • Setting priorities and key requirements upfront will yield the best out of the trial period and help you create a thorough assessment of all products you're testing - check out some ideas for testing frameworks and evaluation criteria.

How to prepare for the discovery call #

The discovery call is the first conversation you have within the buying process. Think of it as a coffee date. This is where you have a conversation about whether you and the product seem to be a good fit. It’s where you ask all the questions you might have, and catch any red flags.

You may be thinking, why is this even needed? All of the information that you need to know is displayed on the product's website. This is the age of self-serve after all. Right? 

Wrong. A study done by Mark Wayshak, a sales strategist, found that around 50% of prospects turn out to be not good fits in the end for the product being discussed. A mismatch like this costs everyone’s resources because wasting time is never a good thing. 

Which is why it’s important to engage with a sales team in the first place. By getting on a call with a product expert from the vendor, you can get answers to all the key questions, and get help with finding out whether there is a potential fit or not through things like customized demos or guided trials. 

🧐 How can I prep for a discovery call?

Use our discovery call prep sheet and get your bases covered with core questions you should be asking when you have a discovery call coming up with a product expert.

Be clear about your needs and wants #

Let’s go back to the coffee date. When you’re about to meet someone new, you have some wants and needs. For instance, if you have a dog, then you want your prospective partner to also be a dog person. 

That is exactly what a discovery call is like. You are essentially interviewing the product as a prospective solution to your problem. 

Thus, before any discovery call, you have to figure out what your goal is with the product. So let’s look at some core questions you can ask around figuring out your wants and needs from the Product Adoption Platform. 

What is the issue you’re trying to solve? #

First of all, what challenges or problems do you face that made you decide you need a Product Adoption Platform? Are you bleeding users? Are not enough people signing up after their free trial? 

Be as specific as possible. Every detail is another piece of information that the product expert can use in order to assess whether there is a good fit between your issue and the product. 

Why is this issue important? #

Not all problems are equal. Some are mere nuisances that you can deal with for the time being. Others are massive headaches that you wanted a solution for yesterday.

Whatever it is, justify the reason why this issue needs to have resources committed to it. Getting a Product Adoption Platform needs conviction, which starts with you being fully convinced that the challenge you face requires investment. 

What use cases does this involve? #

Now that you know the issue, then it’s time to find out what use cases will be the solution. For instance, if you’re experiencing a high rate of churn, perhaps you want to build a cancellation flow to improve churn. 

Product Adoption Platforms offer a variety of UI patterns that could have a wide range of use cases. However, it has to match the use case that you want to actually build for. 

Here are some of the core use cases that Product Adoption Platforms can fulfill:

  • Creating personalized user onboarding flows

  • Running contextual in-app surveys 

  • Offering relevant resources in self-serve help menus 

  • Triggering effective free trial conversion prompts 

  • Showcasing new features with in-app announcements 

Once you know what use cases you want to fulfill, that can become a reference point for the product expert to decide whether you are a good fit for the product or not.

What would a successful outcome look like? #

At the end of the day, you want to solve your problem and achieve success by using the solution.

What does this look like, exactly? Does it mean that the conversion rate has become better? Or could it be that you now have a much lower churn rate? Do you have a specific number in mind in terms of an objective you’d like to reach?

Try to think about what your goals are, and what reaching those goals would look like after you’ve implemented the solution. 

Does the product have all the features you need? #

Not every Product Adoption Platform is the same. Some have fewer features, some have more. Chameleon, for instance, has advanced features such as native A/B Testing, Rate Limiting, and Localization. So take a close look at every single feature that the product offers. See if they completely fulfill your needs. 

For example, if you need to be able to limit how many times your experiences are seen by the user, so that it doesn’t become annoying, check if the product has Rate Limiting available. If you’re not sure, or if you feel that what you need is not reflected on the website, note it down and ask during the call. 

What do customer reviews say about the company? #

There are certain things that you can tell from the get-go, such as whether there is a good problem-solution fit, and then there are details that are a bit more difficult to get. 

For example, every company loves to boast about its top-notch customer service. And in the beginning, companies tend to shower attention and care, like one would with a new romantic relationship. Then the honeymoon phase passes away, the response time to emails gets gradually longer, and dissatisfaction starts to build between you and the product. 

This is why it’s important to go through reviews in order to find out what existing or past customers think about the company. 

Is the product easy to use? Is it easy to implement? Does it integrate well with other tools? Is there self-serve support? What is the quality of their Customer Success team? 

Go on G2 or Capterra and find out what people say about the company. If something doesn’t look all right, like a string of bad reviews that cite a certain aspect of the product, mention this point during the call and see what they say. 

Check the operational processes #

A good fit for a solution isn’t just about whether the product works for you or not. The details have to line up. Otherwise, you’d have to find another solution or rethink your plans. 

These things should be known at the time of the discovery call so that you don’t have to do extra back and forth for the answers when these questions inevitably arise or find out way down the line, which is a waste of everyone’s time.

So let’s take a look at a few operational parameters that you should be ready to discuss on the call.  

What is your timeline for implementing this tool? #

As any good product team may know, timing is everything. Some issues are more urgent than others because they are critically affecting you now. Some may not be as urgent but could cause problems later down the road. 

Or it could be a matter of priority. Among the various problems, this particular one can only be addressed after resources have been allocated to other pressing issues.

You don’t have to pick a date by which everything needs to be in tip-top shape. Just have a sense of when you’d like this to be resolved in mind, whether it’s the next quarter or the next year. 

What is your procurement process? #

Buying a SaaS solution isn’t your average shopping experience.

There’s a whole internal process associated with it, such as checking with your leadership to see if this is a worthy pursuit, and making sure with your finance team that there is room in the budget to buy a new solution.

Whatever it is, get familiar with your procurement process, and inform all stakeholders. Bring them into the process if you can. 

Who would take ownership of the product? #

For every new product that comes into the fold, there has to be a champion for it. There should be a team member that readily recognizes the product’s value, pushes for its application, and takes ownership of the product when it's integrated into your software. 

This person will likely be accountable for the product’s successful implementation across the board, as well as for communicating with the product’s support teams. Knowing who this person will be, and involving that individual at the beginning simplifies everything from the get-go.  

Who would approve the purchase? #

Imagine that you’ve gone through every step of the way of the buying process. You’re just on the cusp of implementing the solution. All you need to do now is to get a signature on that contract. 

Then, surprise, the person who needs to sign it wasn’t involved in the process, and wants more information as well as discussion around the product. Make sure you know who this person is from the start, and likely involve them in the calls because, if not, it could slow down the process. Or worse, tank the whole thing.

Know all your requirements in detail #

Outside of whether there is a fit between the product and your problem, the product will have to be seamlessly implemented into your existing system. This can come with all sorts of technical requirements that need to be met. Let’s take a look at the most common and important questions around this. 

What technology is your app built on? #

First, you need to know what your product is exactly built on. For example, Product Adoption Platforms like Appcues and Pendo, despite their size and renown, do not support software built on Cordova. Have an intimate knowledge of the technology your product runs on so that you can check whether they are supported on the PAP of your choice. 

Is your app a Single Page Application? #

A single page application (SPA) is a web app that dynamically loads elements to a single web page with new data instead of the default method of loading entire new pages. Gmail is a famous example of an SPA. 

If your app is an SPA, there will be certain Product Adoption Platforms that run better on SPAs than others. Chameleon is one of them.

If your product is not an SPA, find out whether there is a plan to become one. This can happen as your product moves toward other frameworks. If you’re not certain, check with your dev team. 

Make sure to mention this during the call and find out how well the service will run on an SPA. Otherwise, you could be buying a solution that will slow down load times.

How many MTUs/MAUs will you be tracking? #

How many monthly tracked users (MTUs) or monthly active users (MAUs) are there for your product? This is one of the core details that you need to be equipped with. The number of monthly users that you have usually decides what plan is ideal for you, and if the solution itself is the ideal option for the number of users on your product. 

Do you have a native mobile app? #

If you have a mobile app, and you would like to add in-app messages and experiences, then that is an extra layer that needs to be considered.

Different solutions have distinct capabilities around how they handle mobile apps. Some support mobile frameworks such as Cordova, like Chameleon does Others have full native mobile capacity. Make sure to bring this up during the call. 

What level of security compliance would you require? #

Everyone knows that security is a big issue. What you may not know is just how much of it you actually need. 

Whenever you buy software that will tap into your customer data, there are certain types of security compliances that must be met in order to ensure the safety of sensitive information. One such type is SOC II Type 2 compliance, which measures how well a technology service safeguards data. 

Another aspect of security that you may want to pay attention to is server locations. EU and US-based servers tend to provide the best level of security. 

If you’re not certain, ask your dev department, or other security professionals you may have on your team. Have them provide the list of all security compliances that a technology service should have before being implemented.

What integrations are must-haves? #

Chances are, you’re already using quite a few tools that are connected to your product, if not dozens. Some of them may be vital, such as your Salesforce and HubSpot CRMs. 

This also includes any integrations you would like to have. For example, if you are using an analytics platform to measure user data, like Heap or Mixpanel, and you are quite embedded in that solution, you would want your PAP to be able to do a two-way integration with the tool. 

Find out which integrations in your toolset are absolutely mission-critical.

Are there any special requirements? #

Technical requirements can be vastly different from product to product. You probably have your own unique conditions that you would like to meet. 

These might include:

  • First-party data collection

  • Localization support

  • SSO certificate

Make sure to understand every single special aspect of your product that needs to be matched with the Product Adoption Platform you’re looking at. Bring them all up during the call.

Be as thorough as possible #

What we mention above is far from being an exhaustive list of things to prepare for during the discovery call. So think carefully about all the things you need to find out so that you can be as efficient as possible during the call. 

You don’t want to be doing too much back and forth and wasting all that time and effort just because you forgot to check the number of your MTUs or you weren’t sure of what technology your product is built on. 

Discover why product leaders pick Chameleon

Sign up for free and start building in seconds or book a call with our product experts who will show you around

How to run an effective trial #

Most product adoption SaaS companies offer free trials for customers of all plans to test out the product before they make a buying decision. 

Free trials are a great opportunity to test the mechanics of the tool and evaluate whether it fulfills your team’s needs and is an investment that leadership can approve. 

In this section, we’ll give you some best practices to run an effective trial, from prep to conclusion.

Preparing for a free trial #

There’s a significant amount of work that can go into preparing for a free trial, just as much as running it. In fact, the better you prepare for it, the better the evaluation of the product will be. 

At this stage, you’ve already had your demo or discovery calls and have learned some of the ways the products you’re testing can work for you, but now it’s time to measure their efficiency and usability. 

You’re also likely to be running more than one trial at once, so preparing becomes even more essential if you want to make the best-informed decision.

Set expectations and priorities upfront #

Keep in mind that the trial period is about testing the mechanics of the product. 

The average free trial is 14-30 days long, so you shouldn’t expect to see any results or impact on key metrics at this stage. 

Succeeding with a Product Adoption Platform requires time investment and iteration that cannot happen in 2-3 weeks, but that should be plenty of time to determine whether there’s a fit with your stack. 

In your previous calls with sales reps, you already went through some of your requirements and key features for your goals, so now it’s time to test these out. Ask yourself what you want out of the product and list your priorities based on the answers, rating their relevance from soft to hard.

Here’s an example of how you can organize your requirements.

Product adoption platforms list of product requirements
Use this template ⬇️

Want to start working quickly on the organization of your requirements? Use this template and make it yours.

Involve other teams if needed #

As we’ve said before, in the first part of this Buyer’s Guide, buying a Product Adoption Platform can be a great solution for product teams because they can then take the strain of creating in-product experiences away from the engineers and make the process faster, cheaper, and more intuitive. 

Nonetheless, you do need to check in with other teams before kicking off the trial to get their perspective on how the product will be implemented and tested.

Engineering support

With Chameleon, for example, there are five installation methods to get you ready to try the product in action. For the options where you need to manually add a code, it can be very helpful to check in with devs to evaluate the overhead necessary to get you started. 

Here are the five installation methods for Chameleon:

  1. With Twilio Segment: a three-step no-code install

  2. With Freshpaint: no-code install

  3. With npm: manually adding code

  4. With JavaScript: a two-part manual code install

  5. With Google Tag Manager: install using a snippet manager

One aspect that you might want to test at this stage is if the snippet slows down your product or impacts its performance somehow.

If you also plan on testing out integrations and how to send data between the product adoption software and your product, engineers might also need to check for clearances and make sure there are no security risks.

Product design support

Involving designers isn’t a must during the trial period, but can be very helpful if you want to really have a feel for how your in-product experiences will look like when live.

Designers can help you incorporate your custom CSS to evaluate how your brand identity will fit into the new UX flows or create templates to test out the building functionality.

If testing design features isn’t a hard priority, some product adoption tools like Chameleon offer their own templates that can get you started quickly and help you focus on other more important requirements.

Executing the free trial #

If you’ve done your prep work, you’ll start the trial with a defined scope that will define how much time you need to spend inside the product.

Building a testing framework can help you find value quickly and present your evaluation of the product under clear criteria.

This is also a time for self-serve discovery of the product’s functionality, so give yourself the flexibility to explore beyond your scope – perhaps you’ll be surprised to find your “aha!” moment where you didn’t think to look before.

Create a testing framework and criteria #

Trialing is all about making good use of your time. You know how long you have to run the trial and what requirements you want to test, but how exactly can you go about them?

Chameleon’s Co-Founder and CEO, Pulkit Agrawal, shares an idea for developing a testing framework:

At the end of the trial you might have to present to executives or other people on the team how the trial went, so think about what this presentation might look like before-hand, what the slide deck should include, and it will be easier to structure the trial.

Pulkit Agrawal, Co-Founder and CEO at Chameleon

In other words, think about what product capabilities are most critical to obtain buy-in from the team and approval from decision-makers.  

At this point, you know if the product offers those capabilities or not, so now is the moment to evaluate how well they work.

For example, some product adoption software might have stronger analytics, while others have better editing UI. Your criteria should evaluate how well each feature works in tandem with how high of a priority the requirements are.

Here’s an example of what a priority checklist could look like when you add specific criteria for each requirement.  

Product adoption platforms criteria for product trial
Use this template ⬇️

Add specific criteria to your checklist to easily identify priorities. Use this template and adjust it to your needs.

Evaluate technical support #

During the free trial, you might not need to depend too much on technical support as you’re not ingrained deeply into the product yet, and you can rely on self-serve support from help docs and tutorials. 

For some product adoption companies, a mid-trial check-in with a dedicated Customer Success Manager is part of the process, and that would be a good time not only to get through hanging questions but also to evaluate the quality of the support being provided.

A big part of buying SaaS is choosing the right partners. You don’t want just another product in your stack, you also need to find synergy with the team you’re working with on the other end. 

Here are some questions to help you with that:

  • How easy is it to schedule a chat with support?

  • How quickly can you get responses?

  • Are you provided with additional resources or guided towards where you can find them?

  • How well does the support team understand the way their product works in relation to yours?

Pay close attention to how knowledgeable the support team is, and how much they care about timely resolving your issues. If your problems are getting unstuck efficiently, that's a good sign that the quality of their technical support is high.

Wrapping it all up #

By the end of your trial, you should have a good understanding of the strengths and weaknesses of each product you are testing. It is now time to combine the evaluation you have done for each one in a comparative analysis to determine what is the best fit for your team. 

In the end, this evaluation will be subjective to what you have determined as key requirements and how well each product served them. 

Aside from all of the above, pricing can be an important decision-making factor, too. Our advice for this part of your assessment is to look beyond the digits: weigh the cost of each option you are testing against the features it offers and how much they satisfy your needs. This should give you an accurate idea of whether the investment makes sense for your team.

Next up in our series, we’ll take you through the process of negotiating a deal, handling procurement, and getting security and legal clearances to kick off your partnership with a product adoption tool.

Boost product adoption with in-app messaging

Get started free with Chameleon and harness the power of product tours, tooltips, checklists, and surveys.

Boost product adoption and
reduce churn

Get started free in our sandbox or book a personalized call with our product experts