I recently tried out HEY, the email and calendar combo from the team over at 37Signals (e.g. Basecamp). I won’t be continuing with the trial because it’s missing several features I need—namely, email specific signatures and write capabilities to Google Calendar and iCloud. Reading through the comments on YouTube, it appears I’m not the only one hoping these get added.

37Signals is a great product company so these must be intentional decisions. They certainly thought of a deeper integration with Google. This brought to mind two concepts—capturing state to improve retention and avoiding the power user trap—both of which are relevant for consumer SaaS apps.

I first learned about state from Julian Shapiro’s guide on retention:

It’s a concept borrowed from video games: the more you play a given game, the more “state” you accrue. This may include your armor, weapons, character skins, and so on.

More state compels users to stick around because (1) they don’t want to lose everything they’ve worked for and (2) they can exploit their increasing status to gain more state more easily.

He goes on to describe several ways products build state including non-transferrable reputation, audience, and data.

Once you internalize this concept of state, you begin to see it everywhere, particularly in subscribed-based products—Spotify playlists, Strava activity data, and 1Password login credentials to name a few. This concept of state is relevant for HEY (also subscription-based).

For any calendar, state is stored in the form of non-transferrable data. You can move all of your events to a new calendar setup, but it’s a big pain. For email apps, it’s more about your social graph. Sure, you can forward your mail from Email A to B while you tell everyone about your new address, but again, it’s a pain. Plus, you just might miss something important.

This concept of state is important for consumer SaaS tools. There’s a start difference between being a client and a full-fledged platform:

1. Building an email/calendar client brings your existing data into a better interface. Under the hood, you’re still using GCal or iCloud to store your data, but HEY provides a slicker UI.
2. Building a platform that powers both the data (i.e. builds state) and the UI.

The latter is much stickier, and while it might lead to less conversion upfront, I’d wager it earns significant gains in LTV and retention. By contrast, Fantastical, the beloved calendar app on iOS focuses more on being the best calendar client in the game, which leaves it more vulnerable to churn if iOS or GCal decide to build these features natively.

Now, let’s move on to the power user trap, a term I first learned of from the Unsolicited Feedback podcast. There’s a predictable lifecycle for consumer-oriented SaaS startups. Here’s roughly how I think about it:

Step 1: Overcome uncertainty. Packy McCormick writes about how this is the first true moat for a startup, but it expands to any product idea. Will this work? Is this feasible?

Packy goes on to reference two types of uncertainty:

1. Novelty uncertainty – Can you build what you say you will build? (e.g., ChatGPT)
2. Complexity uncertainty – Can this business model actually work? (e.g., AirBnb)

Once both of these aspects are apparent, the competition heats up. Uncertainty is your biggest cover while you’re building, so use it to get a headstart.

Step 2: First customers and product enhancements. Once you overcome the uncertainty, you start to attract your first customers. These are the easiest to obtain because they’re early adopters. This is where you build past an MVP and begin rounding out the product to improve activation and retention. These early first customers are likely cheaper. With a lower CAC, you have some wiggle room to play around.

Step 3: Scaling acquisition and solving for product/market fit. Beyond your early adopters, you have to find a way to acquire customers at an acceptable cost. Casey Winters dives deep on this in his post about consumer subscription businesses. Companies often start with paid acquisition, but this becomes less of an option over time:

Every company uses paid acquisition to target its best potential customers first, which usually creates a healthy payback period… But to scale, the company needs to target more and more customers who look less like the core customer over time. Those customers fare more poorly on every metric: ad response, conversion on the landing page into trials, conversion from trials to subscriptions, and retention after subscribing. This leads to predictable degradation in payback periods year over year until, eventually, you run out of people to acquire profitably and paid acquisition is no longer viable.

Step 3 is a true crossroad that challenges the business model and the product roadmap. As you grow your user base, each additional user looks less and less like your target customer. You might try to build in network effects to improve acquisition, but now, you’re incentivized to add even more of these “marginal users” or even add lower cost plans. Ivan describes this challenge well in his post on the Tyranny of the Marginal User. Maybe you elect to add a B2B aspect of your consumer product. After all, B2B SaaS is generally more predictable and profitable. With B2B though, now you need a sales team for this new market.

In short, without dedicated focus, your product roadmap can get trapped in two traps:

1. Building more and more features for the marginal user. Your original product grows bloated and hard to use over time.
2. Serving your sales team. After all, these B2B contracts are now vital for the business. The needs of B2B are different than consumer, though. Again, your product grows bloated and confusing over time.

This is the power user trap. You rely on B2B contracts or insane user growth to make your business model work. To serve that master, your product devolves into an unrecognizable mess. This is how Jira becomes Jira and gets completely upended by Linear.

Pulling us back to HEY, you have to build a disciplined stance and robust business model ahead of time to avoid falling prey to the power user trap. You also have to be comfortable with customers graduating out of your product. HEY isn’t trying to replace email for large companies. They’re building a specific product for a certain type of user. They’re building it with strong opinions and full recognition of the tradeoffs.

Although HEY wasn’t for me, I’m excited to watch the future unfold and see where they take it from here.