Product Adoption Platforms: Planning Your ROI when Building or Buying

Welcome to Part 2 of our Product Adoption Platforms Buyer’s Guide. Have you read Part 1? Make sure you do before getting on to this part! 🤓

Now that we know what Product Adoption Platforms are (a.k.a. Digital Adoption Platforms, or even “DAPs”), let’s examine whether you need one or not in the first place for the problem you have. 

We’re taking a deep dive into the options you have for solving your problems, and how to maximize your ROI whether you are building, buying, or even making do with what you already have.

Before you can determine whether you want to build or buy, let’s do a thorough examination of the pros and cons of both. 

Pros:

• You’ll have a custom-built platform that fits exactly your team's and product’s needs

• A tool built in-house can fit the context of your business and can provide for more nuanced needs.  

• A tool built in-house can become a core asset for your business, aggregating additional value to the company

• You have full control over the solution, and its development roadmap.

• You have closer support and maintenance since it’s an in-house product. 

Cons: 

• You’ll need a lot of time and dev resources to build and maintain the software.

• A costly solution, especially if you need to hire new people for the execution and maintenance of the software. This also includes other unanticipated costs that may be involved. 

• Consider additional maintenance costs over time, you will still have a recurring expense even if the development has already been paid in full.

• If you end up not using the product for the long term, your investment will likely be a loss. 

Pros:

• You can save dev resources that would’ve gone into developing the software. 

• Easy setup that needs minimal engineering support. Some product adoption software can be installed with a single code snippet and a Chrome extension.

• Quick results that can show ROI in a few weeks and can be tracked in real-time through reports or built-in dashboards. 

• You can try before you buy. A free trial period, if taken advantage of, can be enough to determine whether the software works for your team or not.

• No dev time is needed to keep the software running and in use. This means that your product, marketing, Sales, CS, and other teams can use the software independently, easily adjusting it to their needs and goals. 

• No coding skills are required, as product adoption platforms let you create in-product UX flows intuitively with point-and-click selection and real-time editing. With an in-house solution, your hands are tied by engineering. Buying immediately empowers product teams with a tool that’s ready to go.

• Integrates with your GTM tech stack to expand the functionality, allowing you to target users more precisely, analyze the performance, and execute your product adoption strategy more effectively.

• Enables you to take advantage of industry experts who are solely focused on product adoption trends and best practices.

Cons:

• Might not have all the requirements you need, such as insufficient integrations. 

• The buying journey can take longer than expected: The process of evaluation and purchase of various B2B SaaS solutions can take a few months, and it can take longer depending on how specific your use case is.

• The product might disappear along with all your work on it because the company stopped supporting it or the company went under. 

• You might be signing up for a much heavier product than your use case requires. 

Carefully weigh the advantages and disadvantages and see how they apply to your situation and your team. The key is to make an informed decision that sets you up for long-term success. 

Now that you’re fully aware of your problem, your solution, whether you need software or not, and the arguments for either building or buying that software, it’s time to get down to the actual ROI. Let’s crunch some numbers.  

Building your own solution requires engineering resources. So this will pull people away from your dev team, and the money that you pay your developers will be the primary source of costs in the case of building. 

Let’s say your estimated time of development is 6 months.

Then let’s assume that you have two developers and a product manager on the task. 

Let’s say that their combined salaries consist of 40,000 a month. You multiply 40,000 by 6 and you get an answer of roughly 250,000 as cost. 

And that is just the dev cost alone. Let’s not forget ongoing maintenance costs. There will be bugs galore, and there will be updates, some necessary, others highly desirable. In addition, there will be opportunity costs. Those devs could have been generating other value by creating new features or improving your existing products. Let’s say that there is $1,000 a month of additional cost for maintenance and upgrades. 

Let’s say you have a product that charges $20 a month. You determine that the Lifetime Value of your customers is at around 6 months, which means LTV per user is $120. 

At your current 60% conversion rate, You acquire 3,000 new paid users a month. 

By building your own product adoption platform, you’re aiming to improve conversion by 5%, equating to 150 additional subscriptions each month. 

Now, multiply that by the LTV per user of $120, and you’re getting $18,000 a month in additional LTV with the product. 

If the software costs $250,000 to build, and it costs $1,000 a month to keep. At $17,000 a month in net value, it’ll take approximately 15 months to make back the cost. 

Of course, you’ll need to consult your engineering team to get a more accurate estimate of the hours spent on the project. Once you have those details, you’ll be able to deduce how much cash you’ll have to burn in order to build. 

Buying a solution means you have to spend money, but as long as the benefit is greater than the cost, it is money well spent. 

Let’s look at the same scenario above, where you’re getting $18,000 a month in additional LTV with your product adoption platform. 

Say you buy software instead of building your own, and this software costs $20,000 a year. You’re almost making back the cost within a month. Plus, all that cost from dev time can be redirected to other more critical projects. Also consider the time that you were able to save with buying. With building you would have had to wait for months if not years for the software to be ready to use. With buying, you can jump in right away. 

This model is adjustable depending on your assumptions and expectations. Perhaps you can achieve a 10% improvement in conversion rate. Maybe your individual LTV is high enough that you only need a small improvement to make your ROI make sense. 

Let’s do the math now based on the above numbers. 

Building will cost $250,000 in total one-time. 

Take the same LTV increase as above, and that’s $18,000 a month in LTV increase. 

Thus, for the $250,000 to be worth it, you’ll need $18,000 per month for 14 months, resulting in $252,000 in LTV gains. After that, it’s all extra gravy. 

Now, let’s take a look at buying. Buying will cost $20,000 a year. 

At $18,000 a month, you’ll make back your investment very quickly after only a month. 

However, it is a recurring cost, unlike building. If you keep the software for over 13 years at $20,000 a year, it’ll amount to $260,000, overshooting the cost of building. 

Let’s now compare it side by side. 

As you can see, it’s not just about the costs involved in the solutions themselves. There’s also the matter of maintenance. You can’t just let it run on its own after building it. You have to make sure it’s updated and bug-free. On the other hand, an in-house solution is less prone to external risks. 

This is where you have to see how much resource you can throw at the problem. If you have the cash, then you might consider simply building and owning a product for the long term. If you don’t, or if you need to spend money elsewhere, then you could try to save your money and buy a product adoption platform. 

To demonstrate further, here are 5 common use cases of product adoption platforms to help you understand what they can achieve, and what business cases they can fulfill.

User activation is when new users are ‘activated’ via a specific series of steps and events to be completed. The goal is that they’ll recognize and internalize the value provided by the product, nudging them toward conversion. 

Business case of user activation 

User activation can lead to ensuring less customers cancel their subscription as well as leading to more trial users signing up for a paid subscription after clearly seeing your product’s value. 

Let’s say that user activation has resulted in increased retention rate. You used to have 100 paid users leave every month, now that has been reduced to 80. You have 20 users per month who now stay with you instead of canceling. That’s an LTV lift. Using $120 as the LTV figure, we come to: 

20 x $120 = $2,400 per month 

At $2,000 for monthly cost, $2,400 - $2,000 = $400. 

$400 is 20% of $2,000, which means the ROI is 20%. 

Example: DataCamp

Here is a great onboarding example with DataCamp. First, it introduces the user to the tutorial, but it allows the user to easily skip it.

Afterwards, the user onboarding experience continues to highlight different aspects of the UI, clearly outlining what the user can do.

If you want to check out the full DataCamp onboarding experience, view it in our inspiration page.

Increasing trial conversion is one of the lowest-hanging fruits because you have their attention already. They’ve leaped over the hurdle of whether they want to try your product or not. So you can optimize free trial conversion by reducing onboarding and usage friction and by coaxing users to upgrade to paid plans from their trial. This could be in the form of in-app messaging that reminds users to upgrade when they try to access certain premium features. Or it can be a notification that their free trial is expiring. 

Business case of optimizing free trial conversions 

Every single conversion you win through an in-app experience created by a product adoption tool is that much more in customer LTV that you gain. Depending on your pricing, that added value can be more than enough to justify buying software. 

Let’s say that you currently have an average of 500 trial users who churn every month. User activation could lead to 10% lift in those trial users actually converting. That would result in 50 new trial users per month. Using LTV of $120, we can come to the following conclusion. 

50 x $120 = $6,000 a month 

At $2,000 for monthly cost, $6,000 - $2,000 = $4,000. 

$4,000 is 200% of $2,000, which means the ROI is 200%. 

Example: Zenefits 

Here is a nice example from Zenefits. It’s a bottom banner that is reminding the user that their trial is ending. It’s eye-catching, but at the same time also doesn’t interfere with the user experience. It’s a simple and straightforward nudge. 

(Source)

One key engine of growth is upsell. If you have a basic plan that costs $100 a month, and a premium plan that costs $150 a month. Upgrading just two basic plan customers to the premium plan is the equivalent equivalent acquiring a net new customer. And an upsell is much easier (and cheaper) to facilitate than a new subscription since they’re already using your product, they know your value. 

For this scenario you can create a simple modal that pops up when your user has reached the maximum usage with their plan, a tooltip that lets users know a certain premium add-on can benefit them, or anything else that fits your product.

Business case of upsell optimization

To understand the ROI of upsell optimization you have to first remember that premium plans are often priced many times your basic plans. Meaning that every upsell of an account results in an outsized effect on your revenue. 

Let’s say you have 10,000 users all paying for the basic plan at $15 a month. So that’s $150,000 a month. You have a premium plan at $50 a month that isn’t doing so well. 

Using a product adoption platform, you create various experiences to nudge users into the premium plan. This results in a modest 4% conversion among your existing users for upsell. 

Now, 400 users are paying $50 a month, which results in a bump of $14,000 to your monthly recurring revenue. That’s nearly a 10% growth without getting a single new customer in. 

Example: Asana

Here, Asana launches a modal when a user clicks on a feature that isn’t available in their current plan. It clearly outlines the value that the user would get if they go through the upsell. Clean and concise, highlighting key features efficiently.

(Source) 

Self-serve support addresses two issues with customer support teams. 

The first problem is that human-driven support is often not available 24/7. It is very costly to have the support team work around the clock. 

Second, timing and context are less than ideal in conventional support settings. Usually, support tickets are submitted outside of the product, by which time the user has moved away from the context under which they needed the support. 

Instead, by having the help accessible in-product, users can get the information when they need it, all without a support ticket ever being generated. This can be in the form of a widget that contains all the resources a user would need. 

Business case of self-serve support

Self-serve support can lead to higher customer satisfaction, which can lead to many benefits, such as lower churn because people are happier, increase LTV because people are staying longer, and even upsell because customers see how reliable you are. 

But more importantly, it saves work hours. Self-serve support eliminates the need for your customer success team members to tend to repetitive requests and questions. 

For instance, let’s say these repetitive support tickets take up a quarter of your employees’ time. Let’s assume that your customer success manager’s salary is $70,000. If you eliminate them with self-serve support, that frees up time equivalent to: 

0.25 x $70,000 = $17,500 per employee

That is huge in terms of value, and it is time that your CS teams could direct towards more high value tasks. 

Example: Figma 

Here, Figma’s widget has everything you need for all-around self-service support. It even directs people to contact support in case your answer isn’t there. The widget is styled so that it looks native to the website, while being unintrusive to the user experience. 

(Source)

As important as it is to create onboarding flows that delight, the same goes for cancellation. 

Cancellation offers you a unique opportunity to engage with that user for one last time and gain insights into why the user is leaving. As such, creating a well-formed cancellation flow can be very beneficial.

With a DAP, you can easily add user experience elements to enhance the flow like modals to remind them of the benefits they would be losing. You can load modals to remind them that they’d be losing all the benefits of their current plan, or a Microsurvey to get user feedback. 

The business case of cancellation flows 

Every customer that you prevent from leaving is retaining whatever LTV you might have lost.

Say your churn is around 100 users, and your cancellation flow optimization leads to a 5% improvement in churn. That’s 5 users not leaving every month.

With LTV of $120, that comes to: 

5 x $120 = $600 a month. 

At $2,000 for monthly cost, $600 - $2,000 = -$1,400. 

Now, in this particular situation there is no return on investment for this use case alone, and if this was the sole use case to be taken advantage of, buying could make no sense. However, if this use case was simply an added benefit to a use case with a bigger ROI, then it would make more sense financially. 

Example: Zoom

Zoom’s cancellation flow involves a modal in which a user can see what exactly they could lose by canceling. In this example, it says the user has 475 cloud recordings that they won’t have access to anymore. It’s clear and concise. But Zoom also doesn’t try to back the user into a corner by holding those recordings hostage. It gives them an option to download them. 

(Source)

Keep in mind that these business cases are not exclusive to one another. You can have several different business cases that are being addressed by a single product adoption platform. Thus, you could technically gain all of those LTV value lifts mentioned above. That is where the true value lies for product adoption platforms and their ROI. They’re versatile and can be used to solve multiple problems. 

Now, you should be fully ready to assess whether it makes sense for you to either build or buy a product adoption platform in order to address your problem.

Remember, whether building or buying is better really depends on your specific situation. Carefully weight the pros and cons of both sides, and see which fits your context better. Do you have enough devs to cover the additional demand on engineering to build your own? Or are you barely scraping by on your current feature developments? Are you prepared to commit long-term to have an onboarding solution? Or are you just looking to try one out?

Try to map out the business cases that would apply to you, and then see whether those contexts deliver you returns worth investing in.

Only come to the decision to buy, when the value offered by buying far outweighs any other option. That’s how you get the most out of buying a product adoption platform.