Lenny's Newsletter · Product & Work
TIER 4 2023-12-05
*P.S. Don’t miss [Lennybot](https://www.lennybot.com/), my AI chatbot that’s trained on every newsletter post and podcast interview.* I recently heard about an app called [Saturn](https://www.joinsaturn.com/) that reached the top of the App Store charts—and stayed there. This is incredibly rare. As I dug in and chatted with the founders, I was blown away by how methodically they were able to articulate what it takes to build a viral consumer app (particularly one targeted at Gen Z). They launched the company back in 2019, while still students at the University of Pennsylvania, and today have scaled the app to millions of users and nearly 20,000 schools. Their cap table is also unreal and includes General Catalyst, Insight, Coatue, Dick Costolo and Adam Bain’s 01 Advisors, and folks like Marc Benioff (CEO and co-founder of Salesforce), Dara Khosrowshahi (CEO of Uber), Ashton Kutcher, Robert Downey Jr., Mike Vernal (Sequoia), Bezos Expeditions (the personal investment company of Jeff Bezos), Elad Gil, and Dylan Field (CEO and co-founder of Figma). I’m not an investor, but I wish I were. Below, co-founders [Dylan Diamond](https://www.linkedin.com/in/dylancdiamond/) and [Max Baron](https://www.linkedin.com/in/max-baron-saturn/) share their biggest lessons on building a viral social consumer app, including: 1. **Embracing single-player mode as a wedge for social products** 2. **Building a product that users feel was built just for them** 3. **Why it’s OK to be unscalable—you can make it scale later** 4. **Building a familiar product is much easier if you’re solving a problem you’ve experienced** 5. **Playing the long game** I spend most of my time looking for patterns across many successful companies, but often you can learn more by studying a single example in depth. This is an excellent example of the latter. *For more on Saturn, check out [joinsaturn.com](https://www.joinsaturn.com/).*  Saturn is a social network built around the calendar. We started in high schools by building the most powerful real-time calendar ever made exclusively for students. Today we support millions of students at nearly 20,000 schools across the country, entirely bottom-up through the students themselves, without a single school partnership.  It took years to build critical mass by launching at enough schools to see a significant inflection in our growth and the development of real network effects. This August, we reached fourth overall in Apple’s App Store and second on the Social Networking charts, while maintaining a tailored and closed network for each school.  We have a long way to go and millions more students to support, but here are a few lessons we’ve learned that might be useful in building your own consumer social product. *Quick note/disclaimer: No two apps, or growth journeys, are going to be exactly the same—so these lessons won’t be directly interchangeable, but hopefully you can draw from some of them in making your own product and go-to-market decisions. We also note some of the (many) lessons we’ve learned from other major social networks and social utilities since getting started ourselves in 2019.* ### **1. Embrace a single-player mode as a wedge for social products** Many people talk about the value of a “single-player mode.” The reason is simple: it usually unlocks retention, and retention unlocks time—time to iterate and improve on your product. In our case, having a single-player mode gave us more time to launch and refine key social features that improved the network effects of our product. Great retention reduces the cost of making mistakes, and allows you to take bigger risks and learn faster. Chris Dixon wrote about this in a 2015 [piece](https://cdixon.org/2015/01/31/come-for-the-tool-stay-for-the-network) called “Come for the tool, stay for the network,” observing that “starting a network from scratch is very hard. Think of single-player tools as kindling.” From the beginning, Saturn combined a (primary) single-player utility as a user’s daily calendar with a multiplayer or “social” value that came from being able to see what your friends were doing during the high school day. Over time, we’ve introduced new utility and social use cases and continue to invest in those, but our retentive hook has remained a calendar, originally single-player, eventually multiplayer, that perfectly supports each school.  Since we started Saturn, many apps have achieved “hypergrowth” in various demographics with novel multiplayer social features and more impressive K-factors than ours, but, without a retentive single-player utility, most of them seem to have experienced a destructive inverse K-factor as well. As your friends start leaving, the product quickly gets significantly worse. That decay in value is *nonlinear*. Early departures disproportionally worsen the overall value of the network. Here’s an example of how this happens: A new app is super-popular. All of your friends are posting to it once a day. Over the course of a weekend, three of those friends don’t post—it’s not a coordinated effort, but they just aren’t motivated by the notification loops and existing content. Suddenly the library of available (and relevant) content has been significantly reduced, and the product as a whole has become significantly less compelling. Over the coming days, another three people open the app, just to check in, but don’t feel like they need to post. In the span of just a few days, you’ve lost 60% of your creators, and for those final four users, the product is a shell of what it was just a few days before. When the value of an app is almost entirely social, any change in the network will have outsized effects on its overall health. When a network starts shrinking, things spiral quickly, and when a few of your friends stop creating or participating, there is less of a pull for you to participate. These are products with great social loops but lack a legitimate single-player use case that keeps you coming back. This rarely works out. You want to build a product where users can survive in smaller pockets—or, better still, alone. Saturn works well even if you are alone, since our calendar provides single-player value and helps you manage your schedule, regardless of how many others may be on the platform. This shows in our new-user retention across the whole platform:  For context on D30 retention, all of Snap, TikTok, Twitter, and Facebook have D30 new-user retention between 28% and 40% ([source](https://a16z.com/do-you-have-lightning-in-a-bottle-how-to-benchmark-your-social-app/)).Ours is currently in the mid-30s. It’s important to note that there are social products that have built single-player utility after they built a network, and others, like Facebook, that never had to. But many did. For example, Venmo didn’t start as a social payment network with a robust activity page; it had a clear utility-based user story that was deeply valuable to you: “get paid by a friend.” Of course, over time, as the network formed, they developed a significant moat and a network effect that resulted in the story changing to “get paid by your friends—all of them—even faster.” There was a very clear utility-oriented use case along the entire journey—and one that helped them survive within friend groups, even if it didn’t work initially between them. **Takeaway:** Look for (and double down on) a single-player use case to increase retention (both short- and long-term) that will help unlock time to figure out multiplayer social features that create lasting network effects. ### **2. Build a product that users feel was built just for them** Most experiences on your phone feel remarkably impersonal. From day one, our approach helped make Saturn a refreshingly personal experience. We started by white-labeling an app for the students at Connecticut’s Weston High School. We spent a month working with our student ambassador there to deeply understand the complexities of her schedule and the challenges it resulted in for her and her friends. Then we built iWeston to perfectly support their calendar. The night we launched, more than half of the student body joined in just the first three hours. For our first 17 schools, we repeated this process of launching white-labeled apps, each with the school’s letter as its icon, making the app more recognizable and reducing friction to download on the App Store. Another benefit: it looked better on users’ home screens.  When you logged in to any of these apps, you were greeted with an experience that was colorized for your school and perfectly supported the complexities of your schedule. It felt like the app had been built just for your school, because it was.  These school launches were really exciting. We’d recruit an ambassador and then work with them to understand the mechanics of their school, which took less time as we became more familiar with complex schedules. We’d then work with them to spread the word on “launch night” and in the days that followed. They were consistently excited to launch at their schools, and frequently earned social capital for having been our ambassador. For the first few launches, growing at a school was as simple as orchestrating Facebook posts in school-related groups and texts in group chats to help make sure people knew the app was available. Over time, we honed this process, adding sharing links, developing custom landing pages, and adding dynamic content that could be shared directly to your social stories—all of this with the goal of making it easier to invite your friends to join you. By virtue of this product and growth strategy, we came to market with an experience that was unusually perfectly fit to the audience of a specific school. This translated into incredibly fast adoption at schools. It was common to win a critical mass at schools in hours:  By the time we reached 18 schools, we were balancing the need to ship new features and bug fixes and also launch at new schools. We decided to finally consolidate into a single app: Saturn. By consolidating, we unlocked a significantly faster school launch rate while preserving the personal touches users were loving.  We wanted the experience of joining your school to be magical regardless of our scale. Even today, you arrive, add your classes, and everything is reflected perfectly. It leaves you with a “how did they do that?” feeling. The calendar is what feels the most familiar—it’s your daily schedule, after all. The app is still colorized for your school, and you’re greeted on arrival with your school mascot and friends’ avatars. Delight *always* matters.  We chose to scale this personalized product approach, instead of changing the product to make it less personal. This now results in bespoke support for our nearly 20,000 schools. To be clear: we weren’t the first to do this. Facebook, for example, went to significant lengths to support their early schools well, which was fundamental to achieving significant depth in each. This got the network off the ground and eventually allowed them to expand to a broader product. There are two schools of thought around these kinds of bespoke models: 1. Avoid silos at all cost, as they will naturally inhibit scale. 2. Silos enable better product-market fit by solving for users who are very similar, and over time that will help you build a product that remains high-fit across the country. We are believers in the latter—although this approach requires patience and, if you’d like to scale nationally without compromise (as we did), a willingness to invest heavily in building unique tools and infrastructure and hiring more people. Some founders may not choose to do this or may not be able to raise the capital to support it. We didn’t really have a choice; our product was built around a utility that was complicated to develop and maintain. This forced us to build a larger, more experienced team, capable of handling the operational overhead that would come with growth. One note: When developing products for small audiences, be careful not to *overspecialize* for a specific area, community, type of user, etc. For us, this meant a school district, or geography. A good way to avoid this is to use an approach around opposites. If you’re launching urban schools, try suburban schools; if they are predominantly affluent schools, try schools with students from more mixed economic backgrounds, etc. Our first schools were all in southwestern Connecticut, a very affluent region by national standards. In order to ensure the product had fit with students from different backgrounds (and different types of schools), we next launched schools in more economically diverse parts of New Jersey, Massachusetts, etc. This is especially important if you want to raise venture capital. Investors will always want to know the “bounds” of users you have tested with: across age, income level, region, etc. The more types of users you’ve *proven* your product can win over, the better. **Takeaway:** When users are in your app, they need to feel at home. Much like a personal gift from a friend, building a deeply personal user experience earns user trust and engagement. Always be thinking about the things, big and small, that can make users feel that magic. ### **3. It’s OK to be unscalable—you can make it scale later** For us, this was not only relevant in the context of building custom apps for each school when we were getting started, but also building a team of local ambassadors to help us win over the students at each school. Using the calendar as the retentive “backbone” of the product presented a problem. We learned quickly that inaccurate calendars caused user churn, and it was very challenging to maintain accurate ones. Schools have unique schedules and are changing them constantly, for reasons as simple as the weather. A single storm system can cause chaos for millions of students, and our retention was only as good as our ability to maintain accurate data. Without it, users wouldn’t stick around. There was also no centralized source of data, which made this extremely difficult. To start, we sourced data on these changes from students on the ground, and also gave them responsibilities to help with growth. Many investors told us this ambassador program was fundamentally unscalable, and while we agreed that it added significant friction, the lessons we extracted from the program, the consistency of the early growth they provided, and the access to our users were so valuable that we grew the network to more than a thousand students anyway. Instead of discarding the program at a few dozen schools, we went deeper, refined it, and adapted our approach. And even when their growth responsibilities were eventually retired, we maintained a cohort from this passionate group and continue to leverage them as an invaluable resource for user research. Scaling our ambassador count to grow our user base wasn’t pretty, but it worked for years. We were able to iterate through the most challenging constraints of building the program and successfully use it as our default model to launch the majority of our first 1,000 schools. **Our ambassadors were helping us in three ways:** 1. Providing us with the data, context, and information about a schedule necessary to launch a school on Saturn, including keeping us in the loop as schedules changed 2. Helping to “seed” schools (remember, we have a product that works well even if you’re alone, so the first few users are still really valuable) 3. Spreading the word and establishing a larger initial cohort of users from which we could grow over time Eventually, we stopped trying to force scale through ambassadors and instead began to productize each of these responsibilities. It’s worth noting that some things can’t be productized, like the need for users who care enough about your product that they grow it organically through word of mouth. We began to source our data from users on a waitlist. When we launched our first one in July 2021, more than 100,000 students from 10,000 schools joined in 90 days. This gave us a backlog of the information needed to get more schools live. We turned to crowdsourcing to help maintain calendars, which was simple once the network hit sufficient scale. Instead of relying on ambassadors to keep a school’s schedule up to date, we could entrust our users with this responsibility and use consensus modeling to provide even more accurate data. In this respect, growth gave us optionality and allowed us to eliminate this dependency. The users’ interest was aligned with ours—if they submitted data, they would have an accurate calendar for themselves. It was a reasonable ask. In our case, overcoming this data challenge wasn’t optional; it was a *prerequisite* to creating a retentive platform. With more data on school performance over time, we began to see a very clear trend that schools were growing significantly year over year. This validated our hypothesis that once a school was “seeded,” we could invest in it for the long term and it would eventually become fully saturated. If we could get a school live, it didn’t really matter how we got the first few installs, and it was infeasible to launch tens of thousands of schools with a hand-picked student at each one. Once the schools were live at scale, it unlocked new (less targeted) strategies for the top of our funnel, like performance acquisition. Scaling this program resulted in a deep familiarity with the operational challenges we’d have to overcome and an understanding of growth at the school level—including how to reach and acquire users at a specific school and how to catalyze the growth flywheel consistently, both of which were critical for us to achieve national scale. In short, this most unscalable part of our business provided the insights and lessons we’ve leveraged since to hit a point where our social product could begin to drive real user value. **Takeaway:** An advisor once told us, “Startups exist to do things other companies wouldn’t do—or can’t do.” Be scrappy and have a high tolerance for “pain” at the beginning. It will often unlock key lessons you’ll need to scale. ### **4. Building a familiar product is much easier if you’re solving a problem you’ve experienced** Empathizing with other people is really hard. It’s much easier to self-empathize. Thus, it’s much easier to build a product that’s intuitive to users if you build it for yourself, or at least solve a problem you very deeply understand. This is especially important for consumer products. Saturn evolved from an app we built to solve our own problems when we were students. High school schedules happen to be unimaginably complicated: from bizarre rotation patterns asynchronous with the days of the week, classes starting at random times (almost never on the hour or half-hour), lunch waves, modified schedules, and periods with different lengths, to one-off schedule changes that make things almost impossible to keep up with. These were nuances that most people couldn’t see, and they fundamentally didn’t understand the problems and the use cases we were solving for. We didn’t start with a formal product roadmap. We had intuition informed by years of struggling to manage these byzantine calendars ourselves. Our demographic understanding informed what we added to the app and helped us build an early product with features that drove real value for users each day. Sometimes that demographic understanding comes with proximity of age, and that can be an unfair advantage. It was one of the key factors enabling us to recruit and earn trust with our ambassadors at the beginning. We were close in age, and they were motivated to help support us. It likely wouldn’t have been possible if we were twice their age, but it worked well given the circumstances. Lastly, almost all of the other apps that provided similar utility had been built for schools rather than the students—and so in selling to the schools, they were never solving the problems for their actual end users. This differentiated us, as we were always singularly focused on students’ problems and how we could effectively solve them. **Takeaway:** You’re more likely to be successful if you are building a product for yourself, or to solve a problem you deeply understand. Instagram was built by passionate photographers—it wasn’t an accident. ### **5. Play the long game** There are plenty of apps over the past few years that have rocketed to the top of the charts virtually overnight (in some cases eclipsing some of the aforementioned giants), with very strong growth mechanics on the back of a novel social use case. But they have almost universally failed to establish themselves for the long term. Many of these have struggled with an inverse K-factor that ultimately hurts them over the longer term. Major apps like Facebook, Instagram, and TikTok are at such a scale that ambient activity in their networks throws off tens of thousands of installs per day. That’s your competition—both for users’ attention and for chart positions. With TikTok, it took years, multiple iterations, hundreds of millions of dollars in paid ads, and various acquisitions to nail their growth mechanic. This is the most potent and *enduring* app (and growth model) anyone has seen since Snap. One of our investors calls our growth approach “fast and steady.” We have been willing to prioritize healthy, enduring, long-term growth at the community level, and build features that support this growth by solving real user problems. This meant skipping features that may have thrown off faster growth but would not meaningfully improve the actual user experience on Saturn. When you think about apps like Snap, TikTok, Instagram, etc., what’s impressive is not only that they have reached the top, but that they have stayed there for so long and remain relevant to so many different people who are demographically so distinct. With Saturn, for example, our initial TAM is high school students, which provides a natural ceiling. Within that group, we constantly need to be iterating to ensure that we provide value to every incremental user and school—even if they don’t look exactly like the schools we launched at in the very beginning. Reaching the top of the chart is just a signal that you’re acquiring users quickly. If you’re not looking at a massive TAM, you will start thinking about expanding your TAM faster than you’d expect. Be ready for that, and build a product that you think can be modified quickly to start expanding into new markets. For us, it’s been somewhat easier to be patient, with the knowledge that a new class of freshmen would arrive each year more excited about the product than the previous one, but it’s always tough to be patient when it comes to user acquisition. Our long-term focus has allowed us to be more thoughtful with the product and focus on helping each user get through their day. **Takeaway:** Be patient. Getting a consumer product right takes time and constant iteration. If you’re looking for overnight success, you run a higher risk of coming up short. You’ll invariably wind up forging your own path—and hopefully one of these lessons can help as you do. *Thank you, [Max](https://www.linkedin.com/in/max-baron-saturn/) and [Dylan](https://www.linkedin.com/in/dylancdiamond/)! For more on Saturn, visit [joinsaturn.com](https://joinsaturn.com/).* *Have a fulfilling and productive week 🙏* ## 👀 Hiring? Or looking for a new job? I’m piloting a white-glove recruiting service for product roles, working with a few select companies at a time. If you’re hiring for senior product roles, apply below. [Apply to join](https://www.lennysjobs.com/talent/) If you’re exploring new opportunities yourself, use the same button above to sign up. We’ll send over personalized opportunities from hand-selected companies if we think there’s a fit. Nobody gets your info until you allow them to, and you can leave anytime. **If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already. There are [group discounts](https://www.lennysnewsletter.com/subscribe?group=true), [gift options](https://www.lennysnewsletter.com/subscribe?gift=true), and [referral bonuses](https://www.lennysnewsletter.com/leaderboard) available.** Sincerely, Lenny 👋