Designing monetization


2024


As our user base and features expanded, we finally got the signals that it was time to monetize. 

We needed gracefully onboard end users onto freemium and also build admin tools to manage teams. 


What is Magical?

Magical is a browser extension that helps users automate mundane tasks.

Through text expansion and data entry, 700k+ users saved 7+ hrs per week (on average). 

Most common user types: sales people, recruiters, and customer support. 


What was my role?

I led all product design work while collaborating closely with one PM and four engineers. We interfaced daily with the GTM team to align on pricing and strategy.  


What problems are
we solving?

1. As a free product, how do we build a cohesive notification system that effectively communicates monetization to our users?

2. Admins weren’t supported by Magical and building an in-app team was incoherent. How do we equip admins to set-up and support their teams? 






What is Magical’s vision for collaboration?



The vision


    


For users: 
Save time through task automation across their teams.

For us:
Equip champions/admins so we can monetize large teams and companies.





Research



Business goals

$Xm in two quarters - There was an appetite for paid plans, so we wanted to act and expand fast. 

Create an admin product that can drive collaboration - Magical didn’t have any features for admins. When users signed up for Magical, they couldn’t easily find their teammates nor a universal content library. 



User research


(25 users, 45min each)
 Jeanne (Money PM) and I asked users in target companies:


1. How are purchasing decisions made and who get to make them?

2. When do you like to collaborate vs when do you like to keep things solo?


What we learned:







Breaking down the work

Make team the content owner


To encourage teams to build a content library, we needed to make content owned by the team/company rather than the individual. 

An example of this method is Figma getting rid of drafts and forcing users to move projects to teams. 


Introduce paid plans to users


No one (including myself) will ever be excited about paying for software. It was important for us to be consistent and clear about how and why we were monetizing. 



Build tools for admins to manage their teams


In order to monetize, we needed a way for people to pay, choose plan type for their team, and communicate with us.









Final designs



Team as a content owner


When onboarding onto Magical, we auto-match user email (ex: @redfin.com) with their team and suggest they join. Eventually, we’ll force all of these emails into one team. 





Introducing paid plans


Paid plans had more advanced actions (ex: data transfers, AI writing) than Free and Core.

We gated users after they reached a certain number of advanced actions. 

For future: design a more robust and consistent framework in-product to differentiate free and advanced features. 













Building admin tools


I designed a simple provisioning dashboard for admins to manage their team plan. 
For future: reporting, bulk adding, and improved invite experiences.









Results

+$Xm in subscriptions



We only targeted in-bound accounts, but we were still thrilled to hit our goal. Users were willing to pay for Magical. 


Company pivot

Asking users to pay taught us a lot about what we did and didn’t needed to build

Few wanted to shell out for text expansion tools, which was how most of our users perceived us, despite our investment in the automation space.We needed to invest heavily in a brand and product pivot to change this perception. 

From the beginning, I was a staunch advocate for this pivot. Though painful, I’m glad experimenting with monetization highlighted this issue for others.