[DigitalOcean] Onboarding - Optimize the Paywall

Company overview

DigitalOcean is a cloud infrastructure provider offering simple and scalable solutions for developers, startups, and SMBs. Its platform provides virtual servers, managed databases, scalable storage, and networking tools, enabling users to deploy, manage, and scale applications efficiently. DigitalOcean is known for its developer-friendly interface, predictable pricing, and robust support for small-to-medium-sized businesses.

Project overview

Timeline:

• On and off throughout Q1 & Q2 2024 

Role and Responsibilities

• Lead designer

• Pseudo-Product Manager (we didn’t have any product managers on the team so drove discovery, strategy and planning) 

Team

• Myself & another designer

• Development team of 2 FE engineers and 1 BE engineer

• Product director 

• Cross-functional teams: Revenue marketing, security, customer success and billing

The problem

The payment setup page in DigitalOcean’s onboarding process was identified as a significant barrier, with an average drop-off rate of 64% (equating to approximately 89,826 users per month). This was substantially higher than the 14.5% average drop-off rate across other steps, meaning two-thirds of users abandoned the process at this stage.

I spearheaded the discovery phase of this project, thoroughly investigating the underlying causes of this challenge. I facilitated workshops, collaborated across teams to develop hypotheses, designed targeted solutions, and iterated based on experimental outcomes.

Throughout the process, I worked to strike that tricky balance between keeping things secure, making the experience easy and enjoyable for users, and hitting our business goals. 

Why don’t users want to give us their payment method?

We can all relate to abandoning a sign up process. Maybe it’s taking longer than you expected or maybe you were just signing up for something to just try it out but then you’re asked for payment info right up front. 

Users signing up for DigitalOcean shared similar frustrations. Through multiple channels like NPS surveys, support tickets and social media, we were able to identify 3 main pain points:

1. Casually exploring: don’t have a solid use case or serious interest in DO to justify sharing their payment info

2. Lack of trust and frustration: not sure why we require a payment method at all or a prepayment

3. Failure in adding a payment method: payment not supported or encountered errors or locked out while inputting a payment method

The biggest question I had was, “Why do we require a payment info at sign up?”. It seemed like the most obvious thing was to move the payment set up outside of the sign up process.

Why do we require a payment info at sign up?

I worked with stakeholders from security, legal, and revenue marketing to propose moving the payment setup page. I shared user feedback and competitive research showing that while most competitors require payment during signup, they also offer free credits or trials to encourage risk-free exploration. My proposals included either moving the paywall to resource creation (when users are billed) or offering free credits.

Across the board, there was strong resistance due to:

• Security & Legal: Payment methods act as critical security signals to deter bad actors and meet legal requirements.

• Revenue Marketing: Moving the paywall could skew Month 1 revenue metrics, and there wasn’t sufficient justification to budget free credits for all new signups

My conversation with the revenue marketing stakeholder was especially helpful since he also led me to data & previous experiments done that showed:

• Users signing up with free credits (e.g., the $200 trial on our website) had higher churn rates and lower lifetime value.

• A 2022 experiment where the paywall was moved to resource creation actually increased drop-off rates compared to the control group.

Additionally, DigitalOcean’s platform is built using two different frameworks: Ember and React. The resource creation pages are written in both languages, so pursuing a solution that would impact all of them would require double the engineering effort. This was a significant concern for the engineering team, especially since Ember is being phased out. 

What now?

From a cross-functional and business perspective, I understood the hesitation—there were valid concerns backed by data. At the same time, I strongly believed there was value in addressing the drop-off at the payment setup page, particularly to better target new customer segments who might be deterred by an upfront paywall. 

To bridge the gap, I needed to balance the business's reservations with a thoughtful, phased approach that addressed both their concerns and user pain points.

The plan

This led me to develop a structured series of experiments  to methodically explore solutions while building a strong case for the higher-effort changes we aimed to implement.

I presented this plan to my team and cross-functional stakeholders and there was broad agreement on this strategy, with consensus to only advance to the next phase if the current one proved unsuccessful. 

Phase 1: Better communication

Hypothesis:

• Modifying how and where we communicate info related to the paywall will results in varied user info absorption during the payment step, leading to more trust and less hesitation 

Pain point addressed:

• Lack of trust and frustration: not sure why we require a payment method at all or a prepayment

• Ran control (current content) against 2 variants

• Ran for 1 month, each treatment was shown to ~40k users

Results

• As expected, not significant improvement in conversion but there was no negative impact either, with treatment leading to only a 0.01% increase. 

Phase 2: Better experience

There was a lot of input from various stakeholders in this phase, so I organized a workshop to dig deeper into the payment method flows and gather everyone’s ideas. We brainstormed a wide range of potential improvements to the experience. To prioritize these, I worked with the product director and the team to map them on a value vs. effort chart. This allowed us to identify one key experiment to focus on, along with a list of smaller, high-priority “must-do” improvements.T

Main experiment

Hypothesis: 

• Setting credit card as the default payment method in a one-page experience, it will lower the entry barrier and reduce hesitation, ultimately decreasing dropoff.

• This was supported by current usage data showing that users are 2x less likely to drop off once they have selected a payment method and that over 95% of users who get past the paywall use a credit card

Pain point addressed:

• No direct user pain point but 

• Ran A/B, A=control, B= one-page experiment 

• Ran for 2 weeks

Results

• One-page showed ~2.5% increase in conversion. While I initially thought this as insignificant, the revenue marketing stakeholder highlighted during the results readout that even a 1% change can make/break their goal for the quarter.

• Breaking down this impact: this 2.5% translates to 3,476 additional monthly users, converting to approximately 1,993 billable accounts. At our average $50 monthly bill, this generated an additional $96,125 in monthly revenue. 

Must do improvements

Pain point addressed:

• Failure in adding a payment method: payment not supported or encountered errors or locked out while inputting a payment method

Error message updates:

• Errors were vague & uninformative

• We also did not have any standard inline errors like when an invalid credit card number was entered 

Through my analysis of ~20 FullStory session recordings, I observed users frequently encountering a critical 'limbo state' - receiving no or vague system feedback, which ultimately led to abandonment of the signup flow.

We implemented industry-standard error handling, including in-line error messages, specific messaging for cases like unsupported credit cards, and clear pathways to support assistance for users experiencing repeated failures. 

Survey to poll highly requested payment methods

• In the one pager, we added a “not seeing what you need? Reach out to us” and polled the highest requested payment methods not currently supported which were: Alipay, virtual credit cards and ACH transfers. 

• We passed these onto the billing team who is responsible for adding new payment methods and as of Dec 18, 2024, DigitalOcean supports Alipay as a payment method!

Phase 3: Better offer

Unfortunately, due to a reorganization and reprioritization of initiatives, we had to pause after Phase 2. However, as of January 2025, the Growth team has resumed where we left off and is exploring the best way to implement this phase. While I am no longer directly on the team, I have taken on an advisory role and am excited to see the results of this continued work.

Takeaways & Challenges

Data access challenges

One of the key challenges we faced early on was getting any granular data. Data tracking tools we used, like Pendo, rely on unique URLs to track user behavior, but all of our sign-up flow existed under a single URL. This made it difficult to isolate data, even for dropoffs at each sign-up step, which was the baseline data we needed. To access this, we would have to write scripts in our data lake—a process none of us were familiar with.

To address this, I set up weekly syncs with representatives from the data engineering and user research teams, who work with our data lake every day. In the short term, we learned that a pre-written script already existed that tracked each sign-up step, as well as a script that segmented the data by user group. This gave us a clearer view of how our target segment was interacting with the payment setup step. In the long run, this increased our team’s ability to handle data requests independently, setting us up for smoother data analysis in future experiments

Rollback Plan & Async communication

When we implemented the Phase 1 experiment, we were confident that it wouldn’t negatively impact conversion rates, so we decided to roll it out to 100% of customers instead of using an A/B test with a control group. In day 2 of the experiment, a stakeholder raised a valid concern about this decision, pointing out that, despite our confidence, we couldn’t guarantee the result, as it was still just our hypothesis. We had to roll back and release the experiment again with a control group.

This highlighted an important lesson: even small changes can have a big impact, as we saw when the revenue marketing team noted that even a 1% improvement could make a huge difference in their quarterly goals. It reinforced the value of more rigorous testing processes to better understand the true impact of our work. 

This led to 2 changes: future experiments will always have a control group and we decided to implement synchronous review sessions before going live with any experiments to ensure we’re all aligned and can address any potential issues beforehand.