How we designed and developed Player FM’s premium plans in beta

In just a few days, Player FM 4.0 will launch with a major interface redesign, premium features, and many other updates. We’ll post more about the release in coming days, but this post is specifically about what we’ve learned after over six months developing the premium plans in conjunction with the beta community, and what we’ll be doing in the future.

The freemium model

Premium plans are not unusual at this point, but not much of a presence in the podcasting world, so it’s still worth understanding our rationale for introducing them:

In an ideal world, you’d slap on a price tag of few bucks and watch the cash roll in, but that’s not how apps work in 2017, nor how it worked when the app launched in 2013. Too many free options, they may not be the best available, but are “good enough” to bury newly launched paid apps into the netherworld of app store discovery. Furthermore, a one-time payment makes little sense for a product that relies on server resources 24-7 and aims to provide helpful human support, ongoing.

All well and good, but we’ve seen some problematic applications of this model:

  • Making the upgrade a pure donation without adding any value. Or showing copious advertising in the hope users will pay just to remove ads.
  • One-time “unlock” fees which are supposed to offer premium features forever.
  • Contrived features no-one would actually want.
  • Requirements to pay multiple times for new features or access on other devices.

In building Player FM’s premium model, we wanted to avoid these pitfalls. Here is how we set about doing that.

Charging for memberships as we built them

Fortunately, we’re blessed with an active user community and chose to charge real money as we built the premium plans. This was a way to validate the model, i.e. check whether the plans are really something worth paying for, and early feedback was positive.

Beta-testing with real premium memberships also helped to produce valuable feedback, as with all beta engagement. This allowed us to polish the features ahead of the production release. We published regular updates to the community, listened to their feedback via several channels, and ran an email survey for those who’d upgraded early on.

A good example of this was the bookmarks feature, which enables episodes to be remembered with multiple timestamps and notes per episode. One user upgraded to Gold mainly because he wanted this feature in a cloud-synced app, and he then gave us suggestions we were able to use to improve it. In particular, a way to expand individual bookmarks instead of opening the related episode; a way to expand them all; and he also found a display bug when using dark mode. These iterations help us to launch with battle-tested features from Day 1.

Over 100 beta testers upgraded to paid plans across all three tiers during this period and most of the corresponding features evolved considerably thanks to their input.

A final benefit of beta-testing premium plans was proving the payment mechanism and subscription model. The actual task of charging is far from trivial, especially when payment establishes a cloud-based membership on our own servers. Essentially the app takes payment and submits it to our servers, which then have to verify the payment from Google’s servers. There are many scenarios to consider, e.g. a user could have multiple phones, each tied to a different Player FM accounts but still sharing the same Play account. Or the phones could be tied to the same Player FM account but different Play accounts. And that’s just Android, now introduce the web app and iPhone into the mix, and you have all the makings of an N-dimensional programming challenge. Having a real payment model in place helped us iron out these kinds of issues during the beta period.

Learning from past feedback

How do you know if a potential feature is genuinely useful? The most important thing is to drive features from real user needs and requests. Each premium feature we built was driven by user needs and feature requests we kept hearing.

An obvious example is play position syncing between web and Android. Up to now, subscriptions, favorite topics, and the main “Play Later” playlist have always synced for all users. But a fairly obvious need was to sync position and played status. Barely a day goes by where users don’t ask about this. Making this part of the premium offering was a no-brainer, because only the more engaged, serious, users are interested in using the app across multiple devices.

However, not all features “leaped out” at us. Some had to be derived by listening to users’ concerns, and then us transforming those concerns into tangible features.

An example of a concern is limited device storage, which led to the “Space Saver” audio compression feature. This is a feature we didn’t hear about, yet we did often hear about the pain point that drove the feature. Users are frequently sharing their concerns over device space, not surprising when a podcast app uses more storage than any other app on many devices. In this case, the problem was clear and evident. It was a matter of conceiving the solution – perform lossy audio compression in the background – and verifying the community would be interested to use it.

Cloud synced and recurring

Users nowadays expect accounts to sync across devices. While it’s fairly easy to handle in-app payments or in-app subscriptions on a local device without any server component, it’s just not a convenient model for users. Furthermore, it means users can be assured the premium account will apply to other platforms in the future, and this will be the case with our iPhone app due to enter beta testing in a couple of months.

As the app has always synced accounts in the cloud, it was a no-brainer to apply this logic to premium accounts too. As mentioned earlier, this introduces significant complexity, but it’s worth the effort.

One downside here is you have to use multiple payment mechanisms, as each platform has its own standards. (This is more than a user-friendly guideline; it’s a rule in the case of in-app payments for virtual goods on Android and iOS that apps use the platform’s payment mechanism.)

So far, we’ve only implemented payments on Android. The web app, though it supports the cloud-synced features, will make little mention of premium plans until payments have been integrated. There is only a mention of the current membership on the user’s settings page, where it refers to upgrading in the Android beta (and did lead to some users setting up beta and upgrading). We certainly plan to add web and Apple payments in future, but taking payments via Google Play has been “good enough” with the beta and even for the production launch.

Just the beginning

We’re at the end of the beta-testing phase, but just at the beginning of premium plans being available to all users. We’re anticipating new feedback and new challenges ahead, but the approach to development outlined here gives us confident that we’ve built genuinely in-demand features with a cloud-based model that makes sense. Now looking forward to next week’s release and building on these new plans.