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.

Friend-of-the-blog Jasdev Singh and I were chatting over iMessage about finding inspiration for my ambitious next feature for next season, he prodded me to talk about how I go about planning my release schedule for Slopes as a one-man shop.

Sometimes it really doesn't feel like I do any real planning. There's a lot on my plate, and often it can feel like I'm just flailing and grabbing the next thing to work on at random from my Trello board. But I think over the years I've fallen into a kind of ebb-and-flow for my planning and releases, mostly thanks to the seasonal nature of my business.

As I said before, constraints help me produce great work, and my roadmapping is no different. Lets dig into how the seasonal nature of my business affects my planning and feature choices.

~April: This is when the season is coming to a close. There will be a bit of a long-tail into May, but for the most part things have wrapped up for the ski industry. There's a lot less "average person" skiing and we're just left with the enthusiasts. I won't see usage anywhere near these levels until November / December, so I've got about 7 months before most people use Slopes again (there is skiing in the southern hemisphere, but it is a lot smaller compared to the northern market).

April is when I take a step back and start to figure out what major things I want to work on next. While I like my "Just Keep Shipping" approach of shipping new features when they are done, I do like to stay aware the fact that very few people are going to notice major feature launches in Slopes over the summer, so I pick my features wisely here. If I launch some new feature during this period, I'll usually try to go for some great quality-of-life improvements (such as the introduction of the Lift & Run editor last summer, where users could self-correct runs detected by Slopes) to start with. Otherwise I'm planning out the features that will launch in November and beyond.

This time of year is also when I work on features that will take more effort than others. For example, when I rewrote my 3D engine to go from simple rendered GPS tracks to placing those 3D tracks on a virtual mountain, I did that over the summer. I like to ship some major features during the season itself, so to keep pace with that I'll make sure to prioritize the large-efforts for the summers and save some easy-wins for the winter.

When I'm planning out my features over the summer it is usually trying to follow some theme, if I can. Last summer was loosely about "sharing", which took multiple forms. The new Family Pass which let users share their Slopes Premium with other people in their household, being able to post your day on Strava or Instagram Stories, and the new multi-day Slopes Pass bundle (where users could send any individual day pass to another user, so a bit of a group discount). All those, minus IG stories, took some big changes to my server, so I needed the summer to futz with that.

~ June: Oh, hey, shiny new toys! Thanks Apple! At this time of the year I'll usually take stock of what will be useful for me to support when the new OSs launch in September. When I'm planning in April I try to leave myself 75% of my time free between now and September open so I can pivot to support anything major by the OSs releases. If there is nothing major I need to tackle thanks to WWDC, like in 2018, I'll just bring that time back in to work on those larger features.

~September: At this point I start up crunch mode. Anything I plan to launch the season with I have ~2 months to wrap up. I make aggressive cuts here to defer anything that won't make it by Nov 10 (my unofficial "season start"). When picking what I want to cut, I often take a good hard look at any big feature I'm working on and asking what the MVP of that feature-arc is. Often I'll cut parts of a feature-arc, vs an entire feature itself.

For example while working on those 3D mountains, they weren't added as an option on the share cards in the initial November release. The share card enhancement was a release or two later (which went on to be the most popular "look" for the share cards).

~November: The season is starting, and I launch my first major update for the season on the 10th. Usage of the app is still low(ish) until the week of Christmas, but I'm officially in Just Keep Shipping mode now. This is usually where I fall out of any real "planned" mode and go back into my "roll with it" mode.

Any parts I cut out of a feature-arc to make the Nov launch I'll usually focus on adding in as part of the next update or two. Beyond that, I'll usually have squirreled away "what does v1.1 of this feature-arc look like" and work on that. This works out well for me because I'm able to get a large new feature out there, have users on it (and finding any bugs early in the season), and have them start to provide feedback to inform that I was on the right path with that feature. Sometimes I make a big gamble (like the 3D engine rewrite), but I often like to test the waters first.

From Nov - April I really don't fall into much of a pattern. I'm having to balance bugfixes, patterns I'm seeing in customer support and figuring out ways to minimize peoples' need to write in, and the features I want to tackle myself. I'm keeping a good eye on customer support and looking for any patterns of popular requests or common pitfalls to try to get ahead of them, ideally before January / February when usage of the app is at its highest.

I try to ship 2 - 4 "major" features during this time. Customers love seeing active development on the app, and most of my competitors only ship a big early-season splash update and a few small bugfixes after that. I also try to take some time to focus on a "bug week" or two, where I tackle just bugs on my backlog. I'll try to get in the simple bugs as I go with the normal feature updates, but the harder ones often get saved until one of these weeks (unless it is critical).

Rinse and repeat a few times and we're back to April.

OK, so that's the logic of how I space out features throughout the year, but how do I pick what to work on? I have a pretty extensive Trello board cataloging everything from tiny customer issues to larger pie-in-the-sky feature ideas:

As for how I prioritize all those cards in Trello? What's my sage master plan?

Truth be told, I don't have one, I'm all over the place here. But it is an organized-chaos!

Generally speaking quite a few of these fall into a feature-arc (ex: "redesign the recording screen" or "add social components" or "add web interface") and I'm OK defering those features until I'm able to tackle the feature-arc at large. Sometimes I can get a quick v1 of a feature in (ex: allow users to "trim" their day, removing accidental "oops I left it recording in the car ride home" before worrying about a full lift & run editor which does that and more) without having to tackle that entire feature yet. I also try to keep in mind what kind of impact implementing a feature will have on future-me. As a one-man shop I have to make sure I'm leaving plenty of room for development in the future – I can't add a feature if it means next season I'll need to spend 30hrs a week supporting it. If a feature has that kinda smell to it, it gets bumped way down the priority list.

Otherwise, it's mostly a gut check, and this is why that Nov - April timeframe can feel more like (slightly controlled) flailing than any kind of intelligent design. A lot of times my Nov - April timeframe has a roadmap of ... well .. just the next release.

But I try to keep in mind I need a balance. I need to polish Slopes, but not spend too much time past the 80% level of polish. I need to tackle bugs, but I need to be OK leaving some there if they can be customer-supported and don't impact many people. I need to keep shipping new features, but I can't just drop a feature and move on, often there is some more work around that feature that can be done to enhance it even more. I need to listen to customers and their requests, but I need to be OK saying "no" or "not yet." I need to do what I can to minimize customer support (saving future-me), but I need to be OK just having to deal with issues via support for a while.

I try to pace myself and not neglect any one of those buckets for too long.

This lack of roadmap during the season, while sometimes leaving me feeling like I'm just flailing, does let me stay incredibly flexible. Being able to bounce between all those buckets as-needed, without having to manage the complexity of a million things in-flight, lets me constantly focus on "what can I do, right now, to help Slopes the most?"