Vijay Iyengar: preference

Transcript context

…Mixpanel started in 2009 as provide product analytics to EPD teams. And I think early on, it saw a lot of success because it built this in-house database called Arb, which stands for arbitrary segmentation. And that was necessary because events data, which is the fuel for product analytics, is few orders of magnitude larger than most other types of data that people collect, and so you need a specialized approach to deal with it. And so that I think spurred the first wave of explosive growth, because product analytics was a really burning problem at the time. People were shipping mobile apps like crazy and they needed a solution that could scale, and that was kind of a durable mode for Mixpanel for a while. And I think because we had this SDK that was installed in so many apps and we had this really scalable event collection and analytic interface, it was just natural to expand into a few adjacencies that would leverage those same technologies. So, the first one was messaging, being able to send targeted messages to users, which is something that's fairly natural, you might want to do, especially if you have an SDK already installed. Yeah. The other aspect that we've added into was data infrastructure and trying to be the single source of truth of data in companies. And what ended up happening was that by 2018, we had this big churn problem. We had something like 40% churn, revenue churn, our core product. And when we dug into, 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 were just not up to the market in terms of the features we had in our core. And when we dug into why that was, it was just that we had a 50% engineering team that was building products across three domains, product analytics, messaging, and data engineering stuff. Our engineering team was just spread too thin to address all of those core gaps in functionality. And so we made a really hard call at the time. We said the hard no to those two other categories and decided to focus our entire engineering team on closing the gap on product analytics and innovating there. And from a process standpoint, how we operationalize this was we threw away all our planning and all the execution and that we work that we'd planned to do so far, and we did something very simple. We took all the churn reasons that our customer success and sales teams had been painstakingly collecting for years, grouped them by category, which was roughly product features we needed to build, sorted descending by ARR, took the top 10 things and made that our roadmap, just give every engineer direct access to customers and give them a bucket to go work on, which I think goes against about a million product best practices out there of just doing that. But I think given the context at the time, we needed to optimize for speed, and speed comes when you have extreme clarity on what you want to do and focus. best practices out there of just doing that. But I think given the context at the time, we needed to optimize for speed, and speed comes when you have extreme clarity on what you want to do and focus. And so we really just optimize for speed in that time. And so in that first year we moved really quickly and we shipped something like a hundred features in that year and closed a lot of gaps. Again, these are all vanity metrics. Measuring number of features doesn't mean anything. And what year was this by the way?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.