LLenny's Podcast
← All episodes
Vijay Iyengar (Head of Product)26 January 2023

An inside look at Mixpanel’s product journey

9Frameworks
15Insights

Frameworks in this episode

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Myth Buster· 1

Myth Buster25:00

RICE's Hidden Trap: Confidence and Effort Kill Innovation

Vijay likes the RICE framework but warns its confidence and effort factors cause teams to prematurely deprioritize high-reach, high-impact but innovative bets, because those are inherently murky. On one team, RICE-ing everything pushed the most innovative ideas to the bottom. His fix: ignore confidence and effort a little longer, spend a week seriously exploring the big ideas with engineers and designers, then add them back in.

  • RICE's confidence and effort factors cause premature deprioritization of innovative bets
  • High-reach, high-impact ideas are inherently murky on confidence and effort, so they sink to the bottom
  • Fix: ignore confidence and effort longer than is comfortable and sit with the big ideas
  • Spend a week with engineers and designers committed to actually solving them, then re-add C and E
  • Vijay often just cuts the confidence factor entirely, finding it not that powerful

the c and e the confidence and effort tends to cause you to prematurely deprioritize potentially high reach high impact bets really Innovative things

Vijay Iyengar · 25:30

just ignore the c and e for a little longer than it's comfortable and and just sit with those high reach high impact ideas with…

Vijay Iyengar · 26:00
#prioritization#frameworks#rice#product

Hot Take· 2

Hot Take10:30

Great Products Win or Lose on Their Architecture

Vijay argues many products succeed or fail based on their underlying architecture, not just features. He points to Notion's pages-and-blocks model as an example of core building blocks you can hang many high-impact features off of. Mixpanel's design-led phase focused on defining the fewest possible building blocks and how users discover and relate them.

  • Many products win or lose based on their architecture, not their feature list
  • Notion's pages-and-blocks architecture lets many features hang off a few strong building blocks
  • The key design questions: what are the building blocks, how few can we have, how do users discover them
  • Consistent architecture multiplies the reach of every feature you add

so many great products win or lose based on their architecture cutting notion for example like that pages and blocks architecture is is so strong…

Vijay Iyengar · 11:00
#architecture#design#product#notion
Hot Take35:00

The Biggest Analytics Mistake: Client-Side SDK Tracking

Vijay's hot take is that the biggest mistake in setting up product analytics is relying on client-side SDK tracking in web and mobile apps. Web tracking drops 20-30% of events to ad blockers, and mobile forces you to reinvent tracking for iOS and Android and leaves you beholden to users updating their apps. He recommends tracking events from your servers instead: instantly cross-platform, fully under your control, and essentially just structured logs with a user ID.

  • Most people conflate product analytics with client-side SDK tracking, which is a mistake
  • Web SDK tracking drops 20-30% of events due to ad blockers and unreliable JavaScript
  • Mobile forces duplicate tracking across iOS and Android and different teams
  • Client tracking leaves you beholden to users updating their apps for new or fixed tracking
  • Server-side tracking is instantly cross-platform, controllable, and gives 100% reach
  • Events tracked from servers are just structured logs with a user ID, so engineers need no new SDK

the biggest mistake is is setting up analytics using client-side sdks client-side tracking

Vijay Iyengar · 35:00

just start tracking events from your servers instead of from your clients and if you need to supplement it later on with context that's only…

Vijay Iyengar · 37:00
#analytics#tracking#engineering#data-quality

Explainer· 3

Explainer19:30

How Mixpanel Plans: Six-Month Bets and Collapsing the W

Mixpanel organizes cross-functional EPD teams around long-lived paired problems like power vs. simplicity, and plans on a six-month horizon. Planning starts with a leadership strategy memo, then teams develop 'bets' (a problem, a solution hypothesis, a plan to win, and a way to measure success). Uniquely, Vijay and the head of design collapse the middle of the usual W-shaped review by jumping into teams' ideation directly, since the small team only runs 10-12 bets a half.

  • Teams are cross-functional EPD groups organized around long-lived paired problems like power vs. simplicity
  • Planning runs on a six-month time horizon starting from a leadership strategy memo
  • A bet contains the problem, a solution hypothesis, a plan to win, and a success metric
  • They collapse the middle of the W by having leaders join teams' solution discovery directly
  • The small team runs only ~10-12 bets per half, enabling high-bandwidth, unstructured collaboration
  • Output is three linked artifacts: a Notion bets database, a presentation, and an execution/sequencing plan

we plan on a six-month time Horizon

Vijay Iyengar · 20:30

we kind of collapse the middle part of the W where myself and our head of design actually spend time with each of the teams…

Vijay Iyengar · 21:30
#planning#process#product#okrs
Explainer27:00

Appetites Over Estimates: Time-Boxing From Shape Up

Vijay argues estimation is broken because you're asked to estimate before you know what the thing is. Borrowing from Basecamp's Shape Up, he flips it to appetites: fix the time box as the input and scope to fit. Rather than Basecamp's rigid six-weeks-for-everything, he picks a reasonable appetite and explores two-to-three options around it to find the efficient frontier of cost and impact, then checks in honestly on new information.

  • The core problem with estimation is being asked to estimate before you know what the thing is
  • Shape Up flips estimates into appetites: the time box becomes a fixed input and you scope to fit
  • Basecamp suggests picking six weeks for everything and being austere about scoping down
  • Vijay's variant: pick a reasonable appetite, then ask what you'd do with 4 or 8 weeks
  • Exploring options around the appetite reveals the efficient frontier of cost and impact
  • Check in after the time period and be honest about whether new information warrants continuing

instead of making the estimated output of flattening you make the time box or an appetite the input

Vijay Iyengar · 27:00

you pick a reasonable sounding appetite and just explore the two to three options around it pick six weeks and then say what would we…

Vijay Iyengar · 27:30
#estimation#shape-up#process#prioritization
Explainer37:30

The Data Warehouse Becomes the Center of Gravity

Vijay sees the rise of scalable, SQL-standard data warehouses like Snowflake, BigQuery and Redshift as a huge trend, with tools making it cheap to load and push data in and out. The warehouse becomes the single source of truth where product, marketing and sales data all land. He argues events are the universal data model for analytics, but SQL isn't optimized for them, so the opportunity is moving that trusted warehouse data into a tool built from the UI down for events.

  • Scalable, SQL-standard data warehouses have spawned an explosion of tools around them
  • The warehouse becomes the center of gravity and single source of truth for all company data
  • Events are the universal data model: every sales call, marketing click, or product action is an event
  • SQL is optimized for rows, tables and joins, not sequences and segmentations of events
  • The opportunity is moving trusted warehouse data into a tool optimized end-to-end for events
  • Companies increasingly use the warehouse as the event source instead of adding SDK tracking

the data warehouse becomes the center of gravity for all data in your company whether it's product marketing and sales data they all land there

Vijay Iyengar · 38:00

events um like like a Time series of users did this action at this time are the universal data model for analytics

Vijay Iyengar · 38:30
#data-warehouse#analytics#trends#events

Story· 5

Story07:30

How Mixpanel's Expansion Led to 40% Revenue Churn

After early success with product analytics, Mixpanel expanded into messaging and data infrastructure adjacencies that leveraged its SDK. By 2018 it faced roughly 40% revenue churn on its core product. Digging in revealed customers still needed analytics but were leaving for competitors because a 50-person engineering team spread across three domains couldn't keep the core competitive.

  • Mixpanel expanded from analytics into messaging and data infrastructure adjacencies
  • By 2018 the company had roughly 40% revenue churn on its core product
  • Customers weren't leaving because they stopped needing analytics; they left for competitors
  • A 50-engineer team building across three domains was spread too thin to close core gaps

what ended up happening was that by 2018 we we had this big churn problem we had something like 40 churn Revenue churn

Vijay Iyengar · 08:00

it wasn't that people were churning because they didn't need product analytics anymore they had the need they were just churning to competition because we…

Vijay Iyengar · 08:30
#product-strategy#churn#focus#mixpanel
Story08:30

The Hard Refocus: Churn Reasons Became the Roadmap

Mixpanel made the hard call to say no to its two adjacent categories and point the whole engineering team at product analytics. To operationalize it, they threw away all existing planning and built a roadmap straight from years of collected churn reasons, grouped by category and sorted by ARR. Every engineer got direct customer access and a bucket to own, optimizing purely for speed.

  • They said a hard no to the messaging and data-infrastructure categories to refocus on the core
  • All prior planning and execution work was thrown away
  • Churn reasons collected by CS and sales were grouped and sorted descending by ARR
  • The top 10 became the roadmap; every engineer got direct customer access and a bucket
  • Speed comes from extreme clarity and focus on what you want to do

we took all the churn reasons that our customer success and sales teams have been painstakingly collecting for years group them by category which was…

Vijay Iyengar · 09:00

speed comes when you have extreme Clarity on what you want to do and focus

Vijay Iyengar · 09:30
#prioritization#roadmap#focus#execution
Story09:30

Shipping 100 Features, Then Fixing the Holistic Design

In the first refocus year Mixpanel shipped around 100 features and quickly improved win rate and retention, though Vijay warns feature counts are vanity metrics. Shipping that fast neglected holistic design, so features had low reach and had to be rebuilt for every part of the product. A parallel design-led stream fixed the system architecture, and over the phase retention rose from about 60% to 90% and NPS from 16 to 50.

  • Mixpanel shipped roughly 100 features in the first year and saw win-rate and retention gains
  • Feature counts are vanity metrics; the number shipped doesn't mean anything on its own
  • Fast shipping neglected holistic design, so each feature's reach was low and needed rebuilding
  • A parallel design-led stream defined the core building blocks and system architecture
  • Over the phase retention went from ~60% to 90% and NPS from 16 to 50

we shipped something like 100 features in that year and closed a lot of gaps

Vijay Iyengar · 09:30

our retention went from about 60 to 90 and our NPS went from 16 to 50.

Vijay Iyengar · 11:30
#design#product#metrics#architecture
Story15:30

Giving Designers Room Away From the Tactical Fire

Mixpanel's talented design team was stuck on tactical projects, brought in at the end just to make things look nice, which Vijay calls a waste. A key juncture was deciding to do the next three months of projects without any design so designers could take dedicated time to rethink the system architecture. Without a dedicated space, design had been squeezing simplifications in at the end and blowing up scope.

  • Designers were pulled onto tactical projects and asked only to make things look nice at the end
  • The controversial call: do the next three months of projects without any design
  • This freed designers to spend three months rethinking the product's system architecture
  • Squeezing design changes in at the end of projects is a classic way to blow up scope

hey we can actually do the next three months of projects about any design which was a kind of controversial thing to say

Vijay Iyengar · 16:00

that's just a classic way to blow up scope at the end of the project because there wasn't a dedicated space for design-led projects

Vijay Iyengar · 16:30
#design#team#process#management
Story30:00

Let Engineers Email Customers: The Raw-Feed Culture

In 2018 a Mixpanel sales engineer built an automation piping all customer gaps reported by CS and sales into a Slack feed with no gatekeeper. Engineers and designers read the raw feed daily, and a ritual emerged where an engineer reacts with an email emoji, then emails the customer directly saying 'I built this feature, tell me more.' Vijay says this empowers engineers to think like PMs, and the feed now enriches each item with account and ARR context so outreach is informed.

  • A sales engineer built an automation piping all customer gaps into an open Slack feed in 2018
  • There is no gatekeeper, process, or pre-aggregation between engineers and raw customer feedback
  • At their scale, all daily feedback can be read in about 20 minutes a day
  • An email-emoji ritual lets engineers claim an item and directly email that customer
  • The feed is enriched with account, ARR, and CSM context so outreach is informed
  • This empowers engineers to think like PMs and takes gatekeeping load off the PM

all engineers and designers could consume that raw feat of direct points of customer with no gigkeeper no process to access it no pre-aggregation

Vijay Iyengar · 30:30

Engineers will go into that channel and react with a message with an email Emoji which means I'm going to email this customer and find…

Vijay Iyengar · 31:00
#customer-feedback#culture#engineering#process

Tool· 1

Tool42:00

Vijay's Book and Thought-Leader Recommendations

In the lightning round Vijay recommends The Goal by Eliyahu Goldratt, a thriller-style novel about the theory of constraints and improving productivity by finding and removing bottlenecks. For product thinkers he points to Gibson Biddle's writing on proxy metrics and the shape of metrics, and Shishir Mehrotra of Coda on eigenquestions and marginal utility contribution.

  • The Goal by Eliyahu Goldratt teaches the theory of constraints in a fast-paced novel format
  • Gibson Biddle's piece on proxy metrics elegantly frames measuring reach and impact together
  • Shishir Mehrotra of Coda has essays on eigenquestions and marginal utility contribution
  • Non-tech pick: Cool Gray City of Love by Gary Kamiya on the history of San Francisco

there's this book called the goal by Elijah goldron and it's kind of an old book but I like it because it's sort of written…

Vijay Iyengar · 42:00
#books#recommendations#product#metrics

Takeaway· 3

Takeaway04:00

Unlearning the Engineer's Instinct to Say No

Moving from engineering to product leadership, Vijay had to unlearn the reflexive hard no to new ideas that engineers build up from maintaining half-baked features. He argues ideas are fragile and a hard no can kill a high-reach direction. His fix: sincerely try to make yes work first, and only reach a no after genuinely attempting the idea.

  • Engineers develop 'scar tissue' and an immune response that says a hard no to new ideas
  • Ideas are fragile in their infancy and a hard no can kill a high-reach, high-impact direction
  • The best way to reach a no is to earnestly try to make yes work and document the attempt
  • Spend 10 minutes sincerely considering how you might make an idea work before rejecting it

the best way to get to a no if you ultimately need to get there is is to try to make it work like start…

Vijay Iyengar · 04:30

just take 10 minutes to consider the idea just sincerely consider how might we make it work and if at the end of those 10…

Vijay Iyengar · 05:30
#leadership#engineering#product#decision-making
Takeaway17:00

When to Expand Beyond the Core: Invest Profits, Not People

Vijay's lesson on adding new product lines: the trap is moving people away from the core, which leaves you open to disruption by someone who can out-invest you there. Leaders should keep out-investing everyone in the core and fund new bets with profits, not by pulling people or raising venture capital. He warns adjacent categories rarely pay off because few customers need the sixth-best CDP or eighth-best feature-flagging tool.

  • The trap in expanding is taking people away from the core, exposing it to disruption
  • Keep out-investing everyone else in your core product if you're the leader
  • Fund new bets with the profits from the core, not by moving people or raising VC
  • Adjacent bolt-on products are rarely best-in-class; few need the sixth-best CDP
  • Secondary products may add only 5-10% of revenue while pulling engineers off the core

you should continue to out invest everyone else in that core and then invest you know the profits that come out of that core into…

Vijay Iyengar · 17:30

there's not that many people that need the sixth best CDP or the eighth best feature flagging or the 10th best message targeting tool

Vijay Iyengar · 18:30
#product-strategy#focus#expansion#leadership
Takeaway18:30

Cutting Mild Successes Is 10x More Painful Than You Think

Vijay warns that killing products which are mildly successful is far harder than cutting outright failures. These products have whole teams and roadmaps attached, making the decision organizationally painful. Leaders should think very hard before starting adjacent bets they may later have to cut.

  • Cutting a mild success is about 10x more painful than cutting a clear failure
  • Mildly successful products have whole teams and roadmaps that make cuts organizationally painful
  • Think hard before kicking off adjacent bets you may later have to kill

it's also 10x more painful than you think to cut mild successes than than anything else and organizationally painful and there's teams that have whole…

Vijay Iyengar · 18:30
#product-strategy#focus#leadership#decision-making