Five Key Lessons from Sarah Tavel's Time Scaling Pinterest as First PM

Sarah Tavel joined Pinterest in 2012 as their first Product Manager when the company had just a handful of employees. She helped scale it through hypergrowth, launching their first search and recommendations features. Here are the key lessons she’s shared from that experience.

Lesson 1: MAUs Are a Leaky Bucket

Early on, Pinterest’s growth team set their objective to increase Monthly Active Users. It seemed intuitive—MAUs is what social networks report, after all.

The problem: While MAUs increased, they had a leaky bucket. New users poured in but churned out just as fast.

The fix: They shifted focus from MAUs to Weekly Active Pinners (WAPers)—users who completed the core action at least once per week. This forced them to care about engagement, not just acquisition.

“People often say that what you measure, improves. While true, it overlooks how strategic the decision of what you measure is. If you get stuck measuring the wrong thing, you could end up wasting your time on the wrong initiatives.”

Lesson 2: Full-Stack Teams Changed Everything

Pinterest initially had siloed teams—separate engineering, design, and product orgs. Moving to full-stack teams (cross-functional pods owning end-to-end features) was transformational.

“When we switched to full stack teams, it was night and day. Everything moved faster, we could prioritize better, we built better products, and everyone was a lot happier.”

Lesson 3: Balance User Feedback with Data

Your most vocal users aren’t representative of your future users.

“If you build every feature your users ask for, you’ll end up with a very small, highly engaged user base.”

Pinterest had to make changes that irritated power users but unlocked growth for the next 100 million users. The key: listen to data over the vocal minority, communicate changes clearly, and be willing to ignore feedback when data points elsewhere.

Lesson 4: The Core Action is Everything

Pinterest’s entire product revolves around pinning. Every feature decision was evaluated against: “Does this help users pin more?”

The discovery engine creates a virtuous loop:

  • More pins → Better understanding of user interests
  • Better understanding → Better recommendations
  • Better recommendations → More pins

This flywheel made the product self-improving simply by users using it.

Lesson 5: Hiring for Hypergrowth

In hypergrowth, you’re constantly hiring people to do jobs that didn’t exist six months ago. Tavel emphasized hiring for learning agility over specific experience—people who could figure out new problems as the company evolved.


Key Takeaway: The Pinterest scaling experience reinforced that growth without engagement is vanity. Measure what matters (core action completion), organize teams for speed (full-stack), and optimize for your next 100M users, not your current vocal minority.

What lessons have you learned scaling products through hypergrowth phases?

The full-stack teams lesson resonates deeply. We made this transition last year and it was harder than expected.

What worked:

  • Giving each pod full ownership (design, eng, PM, data) of a user journey
  • Letting teams set their own sprint cadence
  • Clear metrics ownership—each pod owns specific KPIs

What was painful:

  • Engineers initially resisted “losing” their eng manager reporting structure
  • Designers felt isolated without a design community
  • Knowledge sharing across pods required deliberate effort

How we solved the pain points:

  1. Guilds: Weekly cross-pod meetings for each function (design guild, eng guild) for skill-sharing and consistency
  2. Rotation: Engineers can rotate between pods every 6 months to spread knowledge
  3. Shared design system: Prevents each pod from reinventing UI components

The result: We shipped 3x more features in the following year, and NPS from both customers and employees went up.

One thing I’d add to Tavel’s point: the transition period is brutal. Expect 2-3 months of lower productivity while people figure out new working relationships. Leadership needs to protect teams from pressure during this adjustment.

Anyone else navigate this transition? What worked for you?

Lesson 3 about balancing user feedback with data is where I see teams struggle most.

The challenge: Qualitative research (interviews, usability tests) tends to over-index on current users and their current mental models. But data shows you what’s actually happening at scale.

My framework for balancing both:

When to trust qualitative feedback:

  • Understanding why something is happening
  • Discovering unmet needs and new use cases
  • Evaluating new concepts before building
  • Accessibility and usability issues

When to trust quantitative data:

  • Measuring what is happening at scale
  • Prioritizing features by impact
  • Validating that changes worked
  • Identifying where users drop off

When they conflict:

This is where it gets interesting. Users might say they hate a change, but data shows retention improved. Pinterest clearly faced this.

My approach: Separate the signal from the noise in qualitative feedback. If power users complain but new user activation improves, the change is probably right. But if the reason for complaints reveals a genuine usability issue, fix that while keeping the strategic direction.

The Pinterest lesson about “next 100M users” is crucial. Every research participant is, by definition, someone who already uses your product. They can’t represent the people who bounced.

Great lessons! I want to dig into how these apply specifically to mobile-first products, since Pinterest’s growth was heavily mobile-driven.

Mobile-specific considerations:

Core Action on Mobile

On mobile, the core action needs to be completable in < 30 seconds. Pinterest nailed this—see something, tap to pin, done. Contrast with products that require too much typing or multi-step flows on mobile.

Question: How do you handle products where the core action is inherently complex? Do you simplify it for mobile or accept lower mobile engagement?

Notification Strategy

Pinterest was aggressive with notifications to drive re-engagement (part of their virtuous loop). But mobile notifications are a double-edged sword—too many and users disable them or uninstall.

What I’ve learned:

  • Personalized notifications (based on actual user interests) get 3-4x the engagement of generic ones
  • Timing matters enormously—Pinterest clearly invested in send-time optimization
  • Give users granular control or they’ll disable everything

Mobile Metrics

The shift from MAU to WAP makes even more sense on mobile. Mobile usage is inherently more frequent but shorter. Weekly active on core action is the right frame.

Question for the group: Pinterest was early to mobile. For products building mobile-first today, what’s changed? Are the lessons still applicable, or has the mobile landscape shifted (attention scarcity, notification fatigue, etc.)?