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.

John and I started chatting on Twitter a bit about the idea behind an MVP. Knowing when to ship is hard, especially when you're talking about a version one.

I view the idea of an MVP as less of a hard rule, and more of a lens to judge features against. "If I remove this feature, will customers be unable to use the product?" Now, there is some nuance here: it isn't "Can my customers do everything they want?", but rather "Can I provide value to them, today? Can I be a compelling solution, today?" I'm not as hardcore MVP as many in the web SaaS arena are; I still indulge myself, I still polish. But I try to never lose sight of what that's costing me.

A lot has already been said about MVPs, pretty graphics and all, so instead of rehashing what you can read elsewhere I thought it'd be useful to look back at Slopes v1 and some of the decisions that went into features that didn't make the cut.

Enter: The Bobs

Slopes does a lot of stuff now a days, but at the core I've always thought of it as "displaying your ski data in a way that lines up with the way you think." For skiers / snowboarders, by a snowboarder.

That was what my v1 had to prove - "I get you." Oh, and of course "yeah, this works."

So what made the cut for v1?

• I had to be able to record and parse out lifts vs runs using GPS alone. This was a huge undertaking in and of itself and was just the minimum entry into the market (although you'd be surprised how many ski apps I've seen not get this anywhere close to right).
• My core "I get you" was instead of a nav stack of "run 1 -> tap for details, run 2 -> tap for details", I'd have a scrollable tableview of runs and lifts for the day. Quick browsing of one's day was at the core of Slopes.
• I had to provide an map view outlining their day above that table, which would show which run they were looking at in the tableview as they scrolled. They needed to see where they went.
• My big "wow" factor was my 3d graph idea, so I had to have that in some form.
• I had to build a database of GPS coordinates for over 2,000 resorts world-wide so I could at least identify "you recorded this at Blue Mountain." This almost didn't make the cut.

It took me five months to ship that core list of features; mostly using my nights and weekends, but I did take a month away from consulting towards the end. I didn't expect a lot of revenue from the app at first (healthy/realistic expectations), so I didn't want to take much longer than that. I knew I wanted the app, but I had to validate there was a market for the app before I could justify spending much more time on it.

Beyond v1.0

So if that's what I shipped, what did I cut to get Slopes out the door in five months? What I shipped in the four months post-launch has a lot of features I originally slated for v1.0:

• Editing previously saved activities. I cut it because I'd rarely seen people edit activities with apps like Nike+ / Runkeeper / Strava. "It'll be in the next version" was an OK explanation here.
• Full-screen version of the 3d graph, with playback capabilities. I was learning OpenGL as I went, so I just didn't have the time to get animation and playback controls working. Cut for necessity.
• Photos / notes attachments for recordings. Felt like a pretty obvious nice-to-have, not a must.
• A whole new summary screen for each recording that showed things like lift vs run time, photos, notes, high-level stats. Again, a nice-to-have. I was able to get the tableview to show enough in v1 to ship without this.
• Social sharing. I knew I wouldn't "go viral" anytime soon, and the social sharing was more OpenGL work (3d map -> image).
• Support for seasonal metrics based on which hemisphere you are in. I got to cheat and delay this because souther hemisphere didn't start until June-ish.
• Offline support. Most of the time people were OK at resorts, and I made it so they could always fall back to not-at-a-resort mode.
• Tons of polish and little details that really hammered home the "I get you."

The first 4 of those seem like no-brainers for inclusion in a v1.0, and truth be told they are! I often tell people I consider v1.2 my "true" v1.0. It took me four months after launch to achieve the true core of what I had set out to do.

But at the same time, shipping without those features didn't kill me. On the contrary limiting my v1 time and launching in September, when the majority of the northern hemisphere really gets going in December / January, did a few things for me.

I was able to validate my product idea in five months instead of nine. I got paying customers, backing up that validation, much earlier. It left me with a healthy roadmap of features for my first season (customers love knowing an app is under active development). And lastly I got a ton of real-world data coming in from early-season skiers that helped me catch GPS issues before I entered peak season.

Staying Lean

This process of trimming the fat has stayed with Slopes well past shipping v1.0. Even today I heavily debate every feature I add, and the order in which I add them.

There are some features I know I can't really take on until I get a team. There are some I know would be awesome, but at the end of the day wouldn't really make Slopes that much better. Others are boring as hell, but will help me grow the business. Some, rarely, are no-brainers.

Most of the time I'm stuck in a grey area, forced to make judgement calls that weigh the many aspects of the business and customers. Usually I'm tempted to just roll a d20 and be done debating, but you can't shortcut this. These decisions can be just as important, if not more, as any engineering work you put in.

Taking the time to practice the skill of truly weighing the necessity of a feature is a still that'll prove useful long past shipping an MVP.