App concept to MVP in 406 days
The story of three products: Bootleggr, ThreeNewTracks and finally, Combo.fm
TL;WR: This is a rather long post. I’ve written it all with the hope that it can help others understand exactly what some of the commitments that go into taking a side-project into a full-time business, and what building a product looks like around that.
I really hope it’s helpful.
A little backstory
I used to be a video editor. I’m an iOS developer now. The main reason?
I quit my full time job as a camera-op/video-editor and took up development so I could listen to music all the time.
Once I’d eventually built up enough confidence and knowledge to put together my own server applications and iOS clients, it was only a matter of time before music found its way into one of my experiments.
In all honesty, I’d have no idea it’d take me down a path that would ultimately end up becoming my livelihood through 2016.
This is my business partner, Jamie, and I, just a month or so after we’d first met, ready to jam for the first time. (Still cringing internally at my pose in this one).
We met whilst working late nights at our full-time jobs at Dojo, a city discovery startup in the heart of London.
We bonded pretty quickly through a mutual adoration of third-wave ska-punk music, which was really exciting for the both of us at the time as neither of us knew anybody else even remotely into it.
Jamie was an Amazon veteran, UX and design extraordinaire; and I was a self-taught script-kiddie with a raving passion for iOS development.
Together, Jamie looked after the product’s design, and I looked after iOS development.
We didn’t really know it at the time, but just shy of two years after meeting, we’d be in the terrifying position of being founders ourselves; building a digital app fuelled almost exclusively on our fiery music passion.
…but in all honesty, it took bloody ages to get there.
Bootleggr: Or, why jumping in to building something straightaway is probably a terrible idea
Whilst I was at Dojo, I’d spent many evenings and weekends building up a side project to practice my Swift learnings from Dojo. It was called Bootleggr, entitled as such as it recommended bootleg (geddit?) remixes of songs from artists you liked using the Echo Nest API.
Or at least, it did at first. Bootleggr very quickly “pivoted” to recommend you three songs you hadn’t listened to every day that weren’t bootlegs. Just, any old stuff, really.
Building Bootleggr was super educational. I found that I could test stuff out I’d implement into Dojo with Bootleggr. It went both ways; I could then use my improved practices I’d developed at Dojo to clean up Bootleggr as I went.
But that was the problem.
Bootleggr was in development for around 12 months.
Twelve. Friggin’. Months.
It never hit the App Store because it was never finished — the code was eternally being cleaned up, classes were always being re-written, and despite getting it to a point where it was ready to ship, I still held off because it was never perfect. And so in beta is where it remained.
This was one of the earliest learnings I had, and didn’t actually connect the dots until way after we made the next step; a product in users’ hands will begin to build itself straightaway. What I mean by this is that when real people use a product, you, the product owner, open up a conversation to gain early feedback from real people and use it to make your product even better.
Bonus points: by listening and working on making it better for the user, you’ll also begin to start grabbing your early product ambassadors. When you begin fixing user’s gripes and letting them know (via personal email, for example), they’ll be naturally more enthused about using the product because they’re aware you’re building it for them.
Six months pass. It was a cold Monday morning the following February that Jamie asked me “Oh yeah! How’s Bootleggr coming along?”, to which I shrugged and muttered something about not having enough time, staring back at the layout script I’d just written for a new image viewer for Dojo.
In all honesty, I was pretty gutted that Bootleggr had gone the same way as many other side-projects before it and had found themselves on the proverbial “shelf” (an action which happened frequently enough to leave me in an eternal state of the Zeigarnik Effect).
Up until this point, I didn’t really think Jamie cared too much about Bootleggr, but this time, something was different. The app’s post-mortem was news to him, and he seemed surprised.
Out of hours, our conversations over the course of the next few months became less about our current employment, and more and more about small business; startups, funding…it was becoming pretty clear that the both of us were interested in starting something independently.
The elephant in the room; why not just join forces?
We were, of course, still employed by Dojo at the time; and since we played pivotal roles in terms of the product’s existence, we began to schedule more serious chats out-of-office. From business concepts, to app ideas, to personal ambitions, we chatted over our future desires.
One thing was clear though; it had to be on our terms, and as far as we were concerned, that meant creating something that we owned.
“What about something like Dojo, but…for music, instead? Mojo!” Jamie laughed, sat in the painfully hipster Vinyl café one Sunday afternoon in Deptford. Sat across from him, the pun was received only by a knowing eye-squint; the expression for “I mean…that’s probably actually a really good idea”.
ThreeNewTracks: Validating a concept
If Medium has taught me anything over the past few years, it’s that products often fail because it hasn’t gone through enough testing prior to launch. So before we made any serious leaps, we decided to build ourselves a little Twitter bot.
Its goal was fairly simple; scrape a couple of popular music blogs for new tracks then post a YouTube link with a random message next to it. Three times a day. Easy.
Bootleggr had taken far too long. This needed to prove a point fast — so I gave myself a hard deadline of one weekend to get this up and running.
Full disclosure?
I’d written just one other server application prior to this.
I didn’t have time to learn the ins and outs of server infrastructure. I didn’t have time to sit on Treehouse and do all of the Node.js courses. I didn’t have time to write gloriously semantic, well-documented code.
This just needed to work. Fast. And prove the concept.
And Christ. Code-wise, this thing did not take long to get well and truly out of hand.
It was a hulking mess.
This was one of the early wake-up calls that starting a company wasn’t going to be solely cupcakes and rainbows. I’d spent the last three years learning Javascript and Swift — understand the best patterns, approaches, techniques — then proceeded to basically totally ignore them.
Not even that, actually use the knowledge to cut corners.
I was having to force myself to write pretty terrible code. I imagine the design equivalent is something like designing a wedding invite in 15 minutes with everything typeset in Comic Sans.
The weekend dragged on. Every new line of code felt like I was taking steps further and further away from everything that I’d spent the last few years teaching myself.
But Sunday evening rolled around, and sure enough; I’d hit my deadline.
I hit the deploy button, dragged my feet to my room and went to sleep, shrouded in a fog of uncertainty and shame.
It was a slow start, but over the coming month, leaving the bot to its own devices, we finally started seeing some results…
We even started getting feedback and even constructive criticism from new followers!
Armed with the knowledge that this wasn’t going to be a total waste of time, Jamie and I had a new fire in our collective bellies; there was just one more thing to think about.
Let me lay it out:
Working for a startup with a lot of product responsibility is really hard.
Working for a startup and working on building on your own at the same time?
Friggin’ impossible.
And as that conclusion dawned on Jamie and I mid-pizza slice one Thursday night in Farringdon, we knew that there was nothing for it.
To take the next step, we’d have to leave our full-time posts at Dojo.
Combo.fm: Overdoing the MVP
For the first time since I’d had the idea to build a music app almost a year prior, I actually sat down and actually began to take my next steps seriously.
No jumping in to the deep end blindly.
No doing things by halves.
This time, things would be different; this time, we’d have a strategy.
This time, we were going to build a music discovery app — and use everything we’d learned to do it right.
We regrouped back at Deptford for another round of lattes, both subscribed to another morning of discussion over future plans.
Jamie and I put our heads together and decided that there were a few things we’d need before embarking on the next step:
- A problem
- Savings
- A shitload of passion
1. A Problem
A problem is the spine of any successful product.
Airbnb? “I wish finding a place to stay in Amsterdam was easy.”
Kayak? “It takes me forever to find cheap flights to Cape Town.”
Combo.fm? “Finding new music that caters to my taste is really difficult.”
Having a problem makes explaining what you’re doing to people a lot easier. Talking about a pressure point, existing solutions, how they satisfy and why they don’t satisfy a need; that’s all great — and opens up huge opportunity for conversation and personal opinion from other people.
Unfortunately, whilst it was easy to talk at length about the issue at hand to our friends and family, we would later discover that being concise was ultimately what a lot of investors would want from us. We’d need to find a way to cut it down from 10 minutes to about 10 seconds.
Spoilers: We uh… we never did.
2. Savings
The best thing to keep in mind when you’re about to throw caution to the wind and embark on something as ballsy as this?
Hope for the best, plan for the worst.
For us, that meant difficult money conversations between Jamie and I. Prior to starting the company, I bloody hated discussing my financial situation with anybody.
However, after just a couple of days after making the decision to leave, it became pretty clear pretty quickly that as a business partnership, you need to know each other inside and out. Warts and all.
Deep breaths were taken. Numbers were revealed. We both figured out between us, we each had enough in personal savings to make it through to the end of 2016.
We agreed that if things were looking shaky, we’d need to be realistic and throw in the towel. If we ever needed to, we took respite in the knowledge we’d try to freelance our way out of a tight financial situation.
3. A shitload of passion
Simply put, we had to have enough confidence in the product that we were solving a real problem, balanced with a comfortable (yet realistic) level of blind optimism to get things moving in the first place.
We’d read the stats; we knew that most startups were doomed to fail from the start. So for us, a tiny two-man team with everything to gain and nothing to lose — that was when that stubborn attitude would become imperative to moving forward fast.
With those in mind, we didn’t have much more left to do. We’d formulated a plan we were fairly comfortable with, and with heavy heads (and a feeling that we’d regret our decision within hours of leaving the building), we both handed our notices in, and began to take the next steps. It was time to start building a product.
…and that almost brings us up to today — two years of back-of napkin sketches, other apps, social media tests, industry chats (and, of course, eight weeks of scribbling and keyboard-bashing); our solution to music discovery, Combo.fm — was live, and available to download on the App Store.
The months that followed the leap from Dojo and the beginning of Combo mark some of the biggest growth periods of my life.
We met more people in the world of startups than we’d expected.
We found space in our idols’ studios.
We even had some meetings with Apple themselves about our little app.
On a personal level — this was all stuff that I’d always hoped would happen, but had never taken the steps to actually pursue them.
Anyway, if I told all those stories, we’d be here until next Christmas; so I’m just going to cut to the chase.
The Launch
With all that research and we’d had, I foolishly had believed we’d done enough to get a solid spike in downloads.
In all honesty; our initial launch?
It was okay.
We hit the Deploy button. Watched the app status change to Ready for Sale, and, well…nothing.
We weren’t inundated with creative criticism — just a couple of people tweeted about the app.
We weren’t overrun with server requests. Our servers barely flinched.
That’s when we knew that we’d missed something.
Here’s what we’d do if we did it again.
Put the minimum into minimum viable product
Unfortunately, our key advantage that many early tech startups seek— having the ability to design and develop native digital products within the core team — was one of our biggest setbacks.
Being so passionate about designing and building quality apps, we cared a little too much about our product’s behaviour and appearance.
Our MVP was too far along.
In hindsight, my ideal MVP would have probably looked more like an on-demand text service, or even a message-based bot service, delivering a new song manually every day. It’s difficult to say, but my hunch would suggest that we could have received similar feedback within an eighth of the time it took to develop Combo.fm for iOS.
We could have benefited more from more critical feedback from our core sell (music discovery and our approach), rather than blindsiding users with a pretty-looking app.
Thankfully, eight weeks end-to-end isn’t crippling for a design and development cycle; but if we’d been in a position where we’d been paying an external agency for the build, we would have likely put more consideration into the product beforehand.
Think about the metrics you want to see improvements on beforehand
I’ve never been much for numbers or statistics when building a product, but when you’re responsible for getting your own product off the ground, it’s really important to understand what does and doesn’t make your users tick.
We put in all the correct technical hooks to ensure we were picking up all the data we needed from our users to study their behaviour; but in all honesty, we didn’t do very much with it.
Thankfully, Jamie was seasoned to speak directly to existing users, and did so with the new app — and with that information, we were able to validate some of our future concepts to develop the product further. We could have gotten so much further in those early months with a better understanding of those key metrics beforehand, though.
Think about the physical acquisition process
When we submitted the app to be reviewed by Apple, I foolishly dropped the “.fm” from the “Combo.fm” app with the sole reason of making the title look a bit nicer — making us just “Combo — Discover New Music”.
As the above image states, this was a bit of a colossal screw-up. Even our friends and family couldn’t download our app; we simply didn’t rank for the search term “combo”; users would have to be linked to the App Store directly (not convenient), or search for “combo.fm discover new music”, which totally sucked.
We updated our app’s name and resubmitted immediately afterward; and seeing as we had a lot of our early users on a mailing list, it just meant we needed to focus on other acquisition methods that favoured linking (Reddit, Product Hunt, Designer News…).
Get a marketing strategy in place before going live
This was huge for us. I regret not speaking to other startups about this earlier. Jamie and I were laser-focused on building a functional, attractive product. This is great if you have an audience prepared to launch it to; but if that isn’t in place, then it’s all for nothing.
What I’d do differently; Get the press release written before even picking up the tools. After reading through a lot of competitors’ press releases, I began to understand exactly what they’re striving to do to make them stand out from others; and in turn, that brought clarity to our own product’s goals. If this had been done from square one, we would have had a clearer path to helping define our key features.
On top of that, I would have also sat down with some relevant bloggers, showing them some initial designs before we’d started building. Not only could we get some early feedback, but as mentioned before, acting on that gives the opportunity to build early ambassadors for the product; and if those people have a direct channel to your target audience, it’s a powerful combination indeed.
To sum up?
Hindsight’s 20–20.
We’ve made a lot of mistakes.
But in all honesty, I don’t regret any of them. Financially, it’s been a difficult lesson to learn, but making these is the only way Combo.fm will get better as a product, and Jamie and I as people.
In fact, I honestly really hope I’ll be writing another one of these in six months.
We’ve got a lot of potential new features we’re planning to roll out for Combo.fm. For the small ones, we’ll continue iterating over the existing; but the larger ones we’ll definitely approach with more of an MVP mindset.
We’re also considering marketing for future large updates before we get started. It’s noticeably trickier to be picked up for an update than a launch, however — so adding some more marketable firepower to our releases is definitely another area we need to explore.
As far as I’m concerned, the key way to improve a digital product is to acknowledge your previous mistakes and act to ensure they don’t happen again — and that’s why we’re learning from these points and iterating to make sure Combo.fm grows to be the best music discovery product on the market.
Bloody hell, you’re still here. Thanks for sticking around. I’d love to hear any feedback you have on this post, either by dropping a comment below, or by reaching out directly to sam@combo.fm.
We’re doing our best to document the development of our product, our startup and future careers through this blog — so a subscription to our publication would go a long way if that’s something you’re interested in hearing more of!
