Vijay Iyengar
Head of Product at Mixpanel
Where to hear and read about Vijay Iyengar1 episode or test
Vijay Iyengar is Head of Product at Mixpanel, an engineer who moved into product leadership and led the company's refocus on its core analytics product. The lesson most worth taking is to keep the whole team out-investing rivals in your core and fund new bets with profits, not people.
you should continue to out invest everyone else in that core
An inside look at Mixpanel’s product journey | Vijay Iyengar
Vijay Iyengar: the story and the lessons
1Vijay Iyengar's path from engineer to head of product
Iyengar went from engineering to head of product at Mixpanel. He started as an intern at Amazon, then worked as an engineer at Uber. At Mixpanel he went from engineering manager to director of product to head of product.
Going straight from engineering leadership into product is uncommon, and he brings an engineer's view to the job.
He had to unlearn the engineer's reflex to say no. Engineers carry the maintenance cost of half-thought ideas that went nowhere, which leaves scar tissue and an immune response against anything new. In product, ideas arrive from many more places than in engineering.
A hard no can kill a whole direction that could have had high reach and impact. He says learning this sooner would have helped his career.
Iyengar spends ten sincere minutes making yes work before saying no. He asks how the idea might work and documents how he tried. If there is truly no path, no is a good instinct.
After being woken three times at 3am by bad ideas, a new idea at stand-up is hard to welcome. Good engineers already balance both sides.
He interviews candidates by having them walk through their life story. Where people spend their time shows what they value. How they describe other people shows whether they use one framework for everyone or treat each person as unique.
The walk-through leads to many follow-up questions.
2How Iyengar's team refocused Mixpanel on its core product
Mixpanel's database edge pulled it toward side products. Mixpanel started in 2009 as product analytics. Events data is orders of magnitude larger than most data, so it built an in-house database, ARB, short for arbitrary segmentation.
ARB was a durable moat for a while. With the SDK in many apps, messaging and data infrastructure looked like easy adjacencies.
Spreading engineers across three products left the core exposed. By 2018 Mixpanel had about 40% revenue churn in its core product. A 50-person engineering team covered analytics, messaging and data infrastructure.
Customers still needed product analytics. They left for competitors with more features.
He cut the side products and put everyone on core gaps. After the refocus, retention went from about 60% to 90% and NPS from 16 to 50.
He says the problem was not the side products themselves but that people were moved off the core to build them. His rule: "invest profits and not people".
The top 10 churn reasons by ARR became the roadmap. Sales and customer success had collected the churn reasons. The team grouped them, sorted by ARR descending, and gave each engineer a bucket and direct access to affected customers. About 100 features shipped in the first year, and win rate and retention improved at once.
The buckets were framed as problems, and engineers invented the solutions. Iyengar says this breaks a million product best practices but fit the context. He calls feature count a vanity metric, and all earlier planning was thrown away in 2018.
3Iyengar on bolt-on products, speed and design
Bolt-on products rarely beat the best in their category. The secondary products added only 5 to 10% of revenue while taking engineers from the core. Few buyers need the sixth best CDP or the eighth best feature flagging tool.
Cutting mild successes was about 10x more painful than expected, because whole teams had roadmaps built on them. A bundle needs an anchor product customers will not give up.
He put speed first, then design, once the basics were covered. In a competitive market with validated table-stakes features, speed comes first. Mixpanel moved on soon after, once it was no longer bleeding on the basics.
His image: "you can't mow your lawn while your house is on fire." The first builds were obvious ones like behavioral cohorts, picked for proven need, not novelty.
Designers got a protected three months to fix the architecture. Designers had been brought in at the end and asked to make features look nice, so they squeezed in simplifications that blew up scope. Mixpanel committed to three months of projects with no architectural impact.
Consistent, interactive charts meant every new visualization applied everywhere, and made dark mode possible. He cites Notion's pages and blocks as the model: many features hang off a few strong building blocks.
4How Iyengar plans and prioritizes at Mixpanel
Teams own long-lived customer problems, and conflicting ones are paired. Cross-functional teams own power, simplicity, data trust, faster onboarding, collaboration and price performance. Power and simplicity pull against each other, so one team owns both.
In his words, "we want one team to own both so that they're kind of forced to confront that tension."
Product and design heads join each team's bet ideation. Planning runs in six-month cycles: a leadership strategy memo, two weeks of pre-work in December, then a two-week solutioning sprint in early January. It ends with a company roadshow.
This works because the company runs only 10 to 12 bets per half, not 50. The sessions are messier and don't scale, but teams leave more confident.
Every bet gets a Notion page, a slide and an execution plan. The template asks for the problem, evidence of demand, reach and impact, how success is measured, the driving hypothesis and a rough plan.
The execution plan covers sequencing, staffing and dependencies, and engineering contributes to it.
He ignores confidence and effort in RICE for big ideas. One team scored every idea last year, and the high-reach, high-impact ones landed at the bottom. He puts engineers and designers in a room for about a week before adding C and E back.
A week of work often reveals a higher-confidence, lower-effort route. The goal is a mix of innovative bets, incremental bets and necessary technical fixes.
He sets a time appetite instead of demanding estimates. Pick a window such as six weeks, then ask what would change with four or eight. Check in at the end for new information and remaining risks.
Engineering used hard time boxes on infrastructure projects that dragged on. Product mostly uses the idea as a thought exercise that forces the core of the problem to be built first.
5How Iyengar keeps engineers close to customers
An open Slack feed of customer gaps has no gatekeeper. A sales engineer, Aaron, built the first automation in 2018. It later added Twitter posts, NPS feedback and win-loss notes, sent to Slack and sorted and tagged in Notion.
At Mixpanel's scale one person can read the feed in 20 minutes a day, and Iyengar read it daily for four or five years as an engineer. Engineers react with an email emoji, then write to the customer and improve the product themselves.
Enriching the feed with account data makes emailing customers safe. Data lands in BigQuery and Census pushes it to Slack and Notion, so each item shows the account, its ARR and the CSM.
An engineer knows to tag the CSM first for a million-dollar account. The trap is over-reacting: after a redesign, the first two weeks bring "I hate this" feedback, and the team had to build a muscle to balance it.
6What Iyengar knows about product analytics
He says client-side SDK tracking is the biggest analytics mistake. On web, ad blockers and other issues drop 20 to 30% of events. On mobile, iOS and Android need separate tracking, and old app versions keep sending old, broken tracking.
Many people treat product analytics and SDK tracking as the same thing.
He tracks events from servers by default. Every platform goes through the servers, so reach is 100% at once, and tracking can be updated for every user.
Engineers already write logs, and an event is a log line with a user ID. Client-only context can be added later.
He sees events as the universal data model on top of the warehouse. A Gong call, an article click and a product action are all events. SQL is built for rows and joins, not for event sequences, so the analysis tool on top must be built for events.
Mixpanel is tightening integrations with warehouse and reverse ETL tools like Census and Hightouch. More customers use the warehouse as their source of events with no SDK tracking added.
An inside look at Mixpanel’s product journey | Vijay Iyengar
Mixpanel's head of product explains why the company cut its messaging and data infrastructure products to refocus engineering on core product analytics, and how it plans, prioritizes and stays close to customers. The refocus took retention from about 60 to 90 and NPS from 16 to 50.
Iyengar went from engineering to head of product at Mixpanel. He started as an intern at Amazon, then worked as an engineer at Uber. At Mixpanel he went from engineering manager to director of product to head of product.
Going straight from engineering leadership into product is uncommon, and he brings an engineer's view to the job.
He had to unlearn the engineer's reflex to say no. Engineers carry the maintenance cost of half-thought ideas that went nowhere, which leaves scar tissue and an immune response against anything new. In product, ideas arrive from many more places than in engineering.
A hard no can kill a whole direction that could have had high reach and impact. He says learning this sooner would have helped his career.
Iyengar spends ten sincere minutes making yes work before saying no. He asks how the idea might work and documents how he tried. If there is truly no path, no is a good instinct.
After being woken three times at 3am by bad ideas, a new idea at stand-up is hard to welcome. Good engineers already balance both sides.
He interviews candidates by having them walk through their life story. Where people spend their time shows what they value. How they describe other people shows whether they use one framework for everyone or treat each person as unique.
The walk-through leads to many follow-up questions.
Mixpanel's database edge pulled it toward side products. Mixpanel started in 2009 as product analytics. Events data is orders of magnitude larger than most data, so it built an in-house database, ARB, short for arbitrary segmentation.
ARB was a durable moat for a while. With the SDK in many apps, messaging and data infrastructure looked like easy adjacencies.
Spreading engineers across three products left the core exposed. By 2018 Mixpanel had about 40% revenue churn in its core product. A 50-person engineering team covered analytics, messaging and data infrastructure.
Customers still needed product analytics. They left for competitors with more features.
He cut the side products and put everyone on core gaps. After the refocus, retention went from about 60% to 90% and NPS from 16 to 50.
He says the problem was not the side products themselves but that people were moved off the core to build them. His rule: "invest profits and not people".
The top 10 churn reasons by ARR became the roadmap. Sales and customer success had collected the churn reasons. The team grouped them, sorted by ARR descending, and gave each engineer a bucket and direct access to affected customers. About 100 features shipped in the first year, and win rate and retention improved at once.
The buckets were framed as problems, and engineers invented the solutions. Iyengar says this breaks a million product best practices but fit the context. He calls feature count a vanity metric, and all earlier planning was thrown away in 2018.
Bolt-on products rarely beat the best in their category. The secondary products added only 5 to 10% of revenue while taking engineers from the core. Few buyers need the sixth best CDP or the eighth best feature flagging tool.
Cutting mild successes was about 10x more painful than expected, because whole teams had roadmaps built on them. A bundle needs an anchor product customers will not give up.
He put speed first, then design, once the basics were covered. In a competitive market with validated table-stakes features, speed comes first. Mixpanel moved on soon after, once it was no longer bleeding on the basics.
His image: "you can't mow your lawn while your house is on fire." The first builds were obvious ones like behavioral cohorts, picked for proven need, not novelty.
Designers got a protected three months to fix the architecture. Designers had been brought in at the end and asked to make features look nice, so they squeezed in simplifications that blew up scope. Mixpanel committed to three months of projects with no architectural impact.
Consistent, interactive charts meant every new visualization applied everywhere, and made dark mode possible. He cites Notion's pages and blocks as the model: many features hang off a few strong building blocks.
Teams own long-lived customer problems, and conflicting ones are paired. Cross-functional teams own power, simplicity, data trust, faster onboarding, collaboration and price performance. Power and simplicity pull against each other, so one team owns both.
In his words, "we want one team to own both so that they're kind of forced to confront that tension."
Product and design heads join each team's bet ideation. Planning runs in six-month cycles: a leadership strategy memo, two weeks of pre-work in December, then a two-week solutioning sprint in early January. It ends with a company roadshow.
This works because the company runs only 10 to 12 bets per half, not 50. The sessions are messier and don't scale, but teams leave more confident.
Every bet gets a Notion page, a slide and an execution plan. The template asks for the problem, evidence of demand, reach and impact, how success is measured, the driving hypothesis and a rough plan.
The execution plan covers sequencing, staffing and dependencies, and engineering contributes to it.
He ignores confidence and effort in RICE for big ideas. One team scored every idea last year, and the high-reach, high-impact ones landed at the bottom. He puts engineers and designers in a room for about a week before adding C and E back.
A week of work often reveals a higher-confidence, lower-effort route. The goal is a mix of innovative bets, incremental bets and necessary technical fixes.
He sets a time appetite instead of demanding estimates. Pick a window such as six weeks, then ask what would change with four or eight. Check in at the end for new information and remaining risks.
Engineering used hard time boxes on infrastructure projects that dragged on. Product mostly uses the idea as a thought exercise that forces the core of the problem to be built first.
An open Slack feed of customer gaps has no gatekeeper. A sales engineer, Aaron, built the first automation in 2018. It later added Twitter posts, NPS feedback and win-loss notes, sent to Slack and sorted and tagged in Notion.
At Mixpanel's scale one person can read the feed in 20 minutes a day, and Iyengar read it daily for four or five years as an engineer. Engineers react with an email emoji, then write to the customer and improve the product themselves.
Enriching the feed with account data makes emailing customers safe. Data lands in BigQuery and Census pushes it to Slack and Notion, so each item shows the account, its ARR and the CSM.
An engineer knows to tag the CSM first for a million-dollar account. The trap is over-reacting: after a redesign, the first two weeks bring "I hate this" feedback, and the team had to build a muscle to balance it.
He says client-side SDK tracking is the biggest analytics mistake. On web, ad blockers and other issues drop 20 to 30% of events. On mobile, iOS and Android need separate tracking, and old app versions keep sending old, broken tracking.
Many people treat product analytics and SDK tracking as the same thing.
He tracks events from servers by default. Every platform goes through the servers, so reach is 100% at once, and tracking can be updated for every user.
Engineers already write logs, and an event is a log line with a user ID. Client-only context can be added later.
He sees events as the universal data model on top of the warehouse. A Gong call, an article click and a product action are all events. SQL is built for rows and joins, not for event sequences, so the analysis tool on top must be built for events.
Mixpanel is tightening integrations with warehouse and reverse ETL tools like Census and Hightouch. More customers use the warehouse as their source of events with no SDK tracking added.