From Enterprise-Only to Self-Serve: Launching a Freemium Product

Context

Experience.com helps organizations manage their online reputation: collecting reviews, surfacing ratings, and giving businesses insight into how customers perceive them. For years, the entire business model was enterprise and mid-market B2B, sold through a dedicated sales team.

That model worked, but it left an entire market on the outside looking in.

The Opportunity

As a member of the leadership team, I helped identify and shape the case for a freemium tier. Three patterns kept surfacing:

1. Demand we couldn't serve. Individual professionals and small teams of 3 to 10 people regularly asked to join the platform, but accounts that size didn't make sense for our sales team to take on. We were turning away willing customers.
2. Users who outgrew their accounts. Professionals who used our platform at a large enterprise would leave to go independent or join a smaller company. They knew the product, they wanted to keep using it, and they were willing to pay. We had no way to keep them.
3. A large untapped market. Millions of independent professionals (agents, advisors, doctors) had never touched the platform at all. Our hypothesis: give them a genuinely useful free version, and they would either upgrade to a paid subscription or become internal advocates who bring us new enterprise accounts.

Rather than treating freemium as a threat to enterprise sales, we positioned it as the top of the enterprise funnel. That framing kept the whole company aligned and avoided the cannibalization fights that often sink projects like this.

My Role

I joined Experience.com in 2019 as the company's sole designer and grew the design organization to 8 people while progressing from Senior UX Designer to VP of Product Design. Along the way I built the company's design system from zero during a ground-up platform rebuild. By the time the freemium initiative kicked off, the team, the system, and the operating practices that made this launch possible were ones I had built.

For this project, I partnered directly with the CEO, VP of Product, and VP of Engineering on product strategy, including how we packaged the offering into Free, Grow, and Pro tiers and which features belonged at each level. The line we held: the free tier had to deliver real standalone value, while the paid tiers had to feel like a natural next step rather than a paywall surprise.

On the design side, I owned the overall design strategy and direction, ran the design operations that kept the project moving, and personally designed the highest-risk feature in the product. More on that below.

Design Strategy and Vision

A freemium self-serve product demanded a fundamentally different design approach than our enterprise platform. Enterprise users get onboarding calls and account managers. Self-serve users get one chance to understand the product on their own, or they leave.

To keep a multi-designer team aligned on that shift, I made the vision tangible rather than relying on documents alone:

• Design principles written specifically for the self-serve experience, giving the team a shared decision-making framework
• A design guide and component library that defined where the freemium product shared components with the enterprise platform and where it deliberately diverged for a different user type
• A working React prototype of the product vision, built by our UX developer, so executives and engineering could experience the direction instead of imagining it from static mocks

One of the trickiest ongoing strategy calls was that shared-versus-divergent component question. Sharing too much would saddle individual professionals with enterprise complexity. Diverging too much would double our maintenance burden and fragment the design system I had spent years building. We resolved it case by case through critique, guided by a simple test: does this pattern serve the user in front of it, or the org chart behind it?

How the Team Worked

I led a design org of 8: a design lead, 5 senior designers, a UX writer, and a UX developer. For this launch, 3 designers plus the writer and developer were dedicated full time, while the rest of the team kept the enterprise product moving. Balancing those two workstreams without letting either stall was one of the hardest leadership challenges of the project.

The operating rhythm I built:

1. Design briefs. I took feature and product requirements from the executive and product teams and translated them into design briefs, so every designer started with clear context, constraints, and success criteria instead of a raw feature request.
2. Daily critique. The full project team met every day to review work in progress. This is where I gave feedback and steered direction, which let me guide quality and consistency across the product without becoming a bottleneck on every screen.
3. Writer embedded in iteration. Our UX writer worked alongside designers as they iterated, not after. In a self-serve product, the words are the onboarding.
4. Prototype-driven handoff. Once designs were finalized and approved by the exec team, our UX developer built them as React prototypes. Engineering received working interaction patterns instead of static specs, which dramatically smoothed handoff and cut down on interpretation gaps.

This operating rhythm wasn't invented for this launch. It was the design ops foundation I had built over the previous years, which had already increased the org's shipping velocity 2 to 3x. The freemium project was where that system got stress-tested by running two products at once.

The Feature I Kept: The Claim Flow

When dividing the work, I deliberately assigned myself the riskiest moment in the entire funnel: the profile claim flow.

Because professionals already existed in our system through their enterprise employers' data, many new users weren't creating a profile from scratch. They were claiming one that already existed. Early versions of this flow confused users about whether to claim or create, which drove abandonment at the exact moment we needed conversion and generated duplicate profiles that polluted the platform's data.

I redesigned the experience around a streamlined claim path that resolved the claim-versus-create ambiguity up front, and designed a separate profile merge tool to clean up duplicates when they did occur.

As the leader, taking on this feature myself wasn't about not trusting my team. It was about putting the most senior judgment on the problem where a failure would be most expensive, and modeling the level of craft I expected everywhere else.

Outcomes

• Nearly 50,000 new users in year one, from a segment the company had never served
• A new self-serve revenue stream with Free, Grow, and Pro tiers, plus a repeatable funnel feeding the enterprise sales pipeline
• A design org that shipped two products at once. The team supported the enterprise platform and launched a 0-to-1 product in parallel, on the strength of the briefs, critique, and prototyping pipeline above
• A faster design-to-engineering handoff through React prototyping, a practice that outlived this project and became standard for the org

What This Project Says About How I Lead

I work at the level the problem requires. On this project that meant shaping packaging strategy with the CEO one day, running critique the next, and personally designing a high-stakes flow when the risk justified it. I make vision tangible through prototypes and principles rather than decks, I build operating systems that let teams ship without me in every room, and I treat design strategy as inseparable from business strategy.