Slopes Diaries is my ongoing journey to turn my indie app into a more sustainable part of my business. First time reading? Catch up on the journey so far.
What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.
I spoke at Release Notes last week about how I've used the SaaS industry and their practices as an inspiration for how to ship Slopes. Release Notes will put the talk online, so I'm looking forward to being able to share that more widely, but I did want to touch on something more immediately as I try to figure out how I want to fully embrace it.
"Features, not versions."
This is something that has stuck in my head more and more about the SaaS industry since a conversation with Belle and her SaaS a few months back. The SaaS industry rarely ships versions. They have no big 2.0. Bugfixes just go out as fast as possible and major features go out when they are ready. No bundling features together for a big splash, just continuous improvement.
I like continuous improvement. Customers like continuous improvement, heck they expect their apps to just keep getting better. And they certainly don't care about version numbers; they care about features.
Some traditional "apps" are thinking this way already. For example Instagram didn't launch v18, they launched Instagram Stories. And then Polls. The versions have disappeared from their marketing efforts and they focus on marketing the individual awesome new features as they are ready.
Over the last two seasons I've tried to embrace shipping often, always shipping 3 major updates during the winter season. But I've started to wonder what things might look like if I didn't bundle up all these changes into 3 major versions, but instead focused on shipping a feature at a time. Smaller more frequent releases give me more room to experiment and improve.
Up until recently shipping more frequently was harder to pull off on the App Store. At least with any real frequency. But with the latest changes to the App Store, specifically ratings no longer being reset when you push out a new version and the dramatically improved review times (I had 2 updates to the same app make their way through the review process in 8hrs two weeks ago), getting frequent updates out doesn't hurt us like it used to.
(Now of course I write all this when I'm just two (🤞) weeks away from a major 3.0 release. But I view 3.0 more as "Slopes gets sync and goes online", and what I'll be able to do going forward with that, than a big marketing thing.)
This idea is a pretty big shift though, and I'm fighting the engineer-side of me that is obsessing over how I'll structure my version numbers and release notes going forward. I'm excited to try, though.