☷

Product / Growth Case Study

☷

Guru Light Users

☷

Creating a freemium motion inside teams by introducing a new user role.

☷

The user & business problem

☷

"Does this person really need a license?"

☷

Guru is a knowledge management platform. Our expansion motion was constrained by per-seat pricing. Existing teams hesitated to invite people who only needed light access as full paid seats, but we wanted Guru to expand across every department in the company.

☷

The signal

☷

Knowledge wants to spread. Per-seat pricing held it back.

☷

100K+

unique anonymous viewers hitting a dead end on Guru cards every week

55%+

of the anonymous traffic came from Slack & MS Teams

☷

The Hypothesis

☷

If we remove cost as a barrier to sharing and adoption, then Guru will spread across departments more naturally. Those users will find value and eventually we can convert enough Light Users into paid Core users to outperform our existing paid-only model.

☷

Potential solutions

☷

I chose the option that matched the behavior we wanted to unlock.

☷

Option	Upside	Why we didn't choose it
Full Core trial	Full value exposure	Cliff after trial; doesn't solve ongoing sharing
Guest / link access	Fast, lightweight	Weak tracking & admin control; harder to convert
Volume discounts	Familiar to Sales	Still requires a purchase before value; not true PLG
Light Users	Durable freemium loop	Chosen — best match to behavior (accepts permission complexity)

☷

Making the proposal

☷

For this to work, we needed to do the following:

☷

Step 1

Drive adoption

Make adding a user nearly frictionless and let anyone invite, not just admins.

Step 2

Convert to Core seats

For any account, Core users had to outpace the seats they'd have bought under the old model.

Step 3

Grow total ARR

The hardest part is that early on, all-paid teams look better because every seat is paid.

☷

The operating model

☷

A three phase model

☷

We approached the experiment in phases rather than treating it as a single huge project to cut down on over-investment.

☷

Phase 1

Prove adoption

Signup paths & lightweight upgrade mechanics. Does removing seat friction change behavior?

Phase 2

Earn monetization

Activation, conversion, and admin controls. Can adoption become durable revenue?

Phase 3

Scale the model

Sales-driven expansion and wall to wall deployments. How far can it go without risk?

☷

Phase 1 · Prove adoption

☷

Ship the smallest version we could responsibly build.

☷

Signup paths & new team exposure
Pricing page experience & variants
Lightweight upgrade mechanics
Experiment flags and routing
Avoided building every edge case

☷

Phase 1 · Engineering

☷

Where PM/EM partnership mattered most.

☷

We had to separate requirements for launch from nice-to-haves after we saw signal.

☷

PM clarity	EM sequencing
What are we trying to learn?	What has to be true technically to learn it safely?
What is the minimum viable Light User experience?	Which entitlement and permission work must ship now?
Where should we avoid overbuilding?	Which edge cases can wait without creating risk?
What risks are we accepting?	How do we preserve QA time before launch?

☷

Phase 1 · Metrics and decisions

☷

+47%

more users added by variant teams

+30%

more MAU per team

+91%

higher conversion rate

-19%

average MRR per team

☷

Decision gate

Roll out experiment 50/50 to all new teams while keeping existing customers on their current experience. Continue monitoring revenue quality and expansion behavior.

☷

Phase 2 · Earn monetization

☷

Turn adoption into durable monetization.

☷

Our experiment roadmap here really focused on onboarding, clearer paywalls as LU's tried to do more, and improving the admin UI and dashboards so that the people managing the Guru instance understood why a user would need to be upgraded to a full paid seat.

☷

Phase 2 · Metrics and decisions

☷

The test wasn't whether one metric ticked up — it was whether the adoption thesis was real.

☷

We launched Phase 1 as a split test on a small share of new teams. The early signal was strong.

☷

+50%

more users added by variant teams

+70%

higher paid conversion rate

[X%]

Light User activation rate

☷

Variant teams drove less MRR up front — expected, since the control teams were all paid seats.

☷

Decision gate

Proceed. Roll out to a full 50/50 split of new teams while keeping existing customers on their current experience — and keep monitoring revenue quality and expansion behavior.

☷

Phase 2 · Metrics & decision

☷

Sometimes the output of a phase is understanding, not a clean win.

☷

We didn't hit every goal right away — and that's normal. Some metrics moved, others dropped. The value was knowing exactly where the model was outperforming and where it wasn't.

☷

"Now we understand where the model is outperforming and where it's underperforming."

☷

For example, activation up but conversion flat raised the question: are we giving away too much value for free? The admin changes were the hardest to read — does the admin actually know these teams, or is Guru just another tool they manage? Honestly, this phase took about twice our estimate, because the results weren't always clean.

☷

Decision gate

The question at the gate: did we have enough levers to improve monetization without giving back the adoption gains?

☷

Phase 3 · A fork in the road

☷

A fork in the road.

☷

This was a real company debate. I'd make a recommendation, but the go/no-go sat with Leadership — primarily our founders.

☷

The case to keep going

We hadn't hit our overall conversion goal, but activation was up, we saw org-wide expansion, and retention beat the control group. With more runway and resourcing, I believed we could reach break-even on conversion.

A new strategic opening

On the core product we'd shipped Enterprise-first features — intranet, internal comms, HRIS. Sales-led, not PLG — but they raised a question: could Light Users be a Sales lever for wall-to-wall deployments, giving company-wide visibility while day-to-day knowledge workers still become Core?

☷

As much as I love an academically clean experiment, we were running a business — and a lower-friction path to multi-department deployment from day one was hard to turn down.

☷

Decision gate

Leadership's call: roll out to all new teams (adoption was real); Product Growth prioritizes upgrades and admin controls to improve monetization quality; and build the basic internal tools so Sales can test the wall-to-wall lever — all while keeping existing customers on their current experience.

☷

End of Part 1

☷

The rest of the story — coming when you're back.

☷

This is where you'll add the future slides: how the scaled model performed, the final results, what surprised you, and the close.

☷

The slides below are your previous Results, Learnings, and Closing — parked here as reference so nothing gets lost while you rebuild this section.

☷

Results (parked reference)

☷

Strong measurable results — and a repeatable operating model.

☷

+46%

more users added by Light User variant teams

+87%

higher paid conversion rate

+17%

higher total MRR

☷

The more important result: a phased operating model for a high-risk growth initiative — each stage with a clear learning goal, evidence thresholds, explicit risks, leadership alignment, Engineering requirements, and a decision to proceed, hold, or adjust.

☷

Learnings

☷

What I learned

☷

Drive upside while making tradeoffs clear enough so leadership can choose risk
Make sure Engineering knows exactly what to build and doesn't overinvest
Help the company learn while minimizing operational chaos

☷

What I'd do differently

☷

If I could do it again, I'd define the monetization boundary earlier — a sharper, earlier call on which actions stay free, which trigger an upgrade prompt, and which Light User patterns are negative signals. We defaulted to generosity, which left money on the table and slowed how fast we learned to drive free-to-Core conversion.

☷

Closing

☷

Hold the whole system in view

☷

Most product growth work creates levers that move metrics. Light Users was about making that lever into a durable product system.