I always enjoy reading Year in Review posts – I find them to be insightful, inspiring, educational, and just generally fun to read. I hope you find this one to be all of those. I’ll break down what we did, how it went, and what I learned so you can learn from my experience without having to go through the pain I did this year.
In case you’re not familiar with Roadfire, we focus on building iOS apps for businesses, and consulting makes up a majority of our business. This year we started to experiment more with products, introducing an iOS app and a workshop. For 2014, we’re going to focus more on growing the product side of our business.
As it was last year, consulting was a huge part of our business this year. We worked with several companies to get their apps into the App Store and worked on updates for others. We’re proud of the work we did on the Good Measures apps, as well as the work we did for iGoDigital, an ExactTarget company, a Salesforce company. :) (Our long-time client iGoDigital is now part of Salesforce. It’s kinda cool to be able to say that Salesforce is a client.) We added an Android developer to our team to build the Good Measures Android app, and he’s done an excellent job.
In addition to the standard iOS development we’ve been doing for clients, I got to spend even more time this year doing what I call one-on-one consulting, where I helped a developer work through problems in their iOS app. I discovered that I absolutely love this sort of work, so if you’re looking for someone to help you through an issue you’re having in your iOS app, send me an email and let’s discuss.
What I learned
Hiring a good developer is difficult – it requires a lot of phone calls, portfolio/resume reviews, and some good judgment – but it’s very rewarding, and I’d much rather have a good developer than an average one. Our contractors have done an excellent job and it’s great to not have to worry about whether things are getting done or whether they’re getting done well. I still check over their work from time to time but don’t spend so much time worrying about whether things are being done well.
Hiring developers does not necessarily reduce the amount of work I have to do. I had thought that if I hired someone to take some of the development off my shoulders, I’d have less work to do. But I learned that when I hire someone, I spend more time paying invoices, invoicing clients, verifying hours and making sure work is done as the client requested. I spend more time doing administrative work and project management.
Helping people is fun and rewarding. I really, really enjoy helping people solve their problems, and as an expert in iOS, I’m happy to help you solve problems you’re having with it. If you’re stuck on an issue you’d prefer not to post on Stack Overflow, send me an email and I’d be happy to help.
Coauthoring a book
I coauthored Developing an iOS 7 Edge this year. To kick it off, we had a weekend sprint where we produced our first draft. It’s amazing to me that we wrote the majority of the content for that 100+ page ebook in only two days. The publisher and the team of authors were fun to work with, and I’m glad I got the experience of writing a book. It was all worth it, too – it’s helped to establish me as an authority on iOS 7 development and allowed me to to see the full publishing process. And people are impressed when they hear I coauthored a book. I’m so glad I got to see the publishing process, as I hope to write a book myself in 2014. The experience I have from coauthoring Developing an iOS 7 Edge will certainly come in handy.
What I learned
Writing a book is hard, but it’s not. Yep, you read that right. Writing a book is hard, but it’s not. It was hard, but not in the way I thought it would be. I thought I’d have nothing to say, that I’d never be able to fill a chapter with things from my head. That was definitely not the case. I had tons of stuff pouring from my brain as I wrote. The hard part was to keep going, to write for 8 hours straight. (OK, well, I took a lunch break, but you get the idea.) And then to do it again the next day. And to stop thinking about iOS 7 after the weekend was over. And to edit my brain dump later. And to get good screen shots.
Collaboration with others from around the world is doable with tools like Hangouts, Basecamp, and Skype. We tried a smattering of tools for collaboration. We eventually settled on Basecamp for discussions, files, checklists, and deadlines. We used Skype for real-time chat (after trying Google talk, Campfire, and HipChat) throughout the sprint weekend. We created our Table of Contents and initial brainstorm in a Google Doc. And we used Google Hangouts for our first getting-to-know-you/planning meeting.
Launching a failed product
Well, saying the product failed is a bit harsh… I have made almost $50 on it… :)
But anyway, I launched Zero Inbox to a very very small audience, and I made a very very small amount of sales. I had thought that App Store discovery would be a little better – I thought more people would just find it, see the value, and buy it. Sadly, that’s not the case – people don’t just search the App Store for a tool that lets them send email without seeing their inbox. What did work, however, was that I built a list of 15 or so people who were interested in the app (largely friends and family, but some people I didn’t know) before I released it on the App Store, and made a good number of sales in the first few days.
What I learned
The App Store does not do marketing for you. They do not make sales for you. You do all the sales and marketing, even if you put your app in the App Store. I guess I had hoped that most of my list would buy the app (a lot of them did) and then the App Store would help me sell more. I don’t know how many sales I was expecting – maybe one a day or so – but that certainly didn’t happen. Since the launch, it’s been more like one a month, with zero marketing effort. I expected the App Store to help me sell one a day without any marketing on my part. I was wrong.
Building an email list is a great way to make sales. As I mentioned, I built a pre-launch email list of 15ish people who were interested in the app when I told them about it. A good percentage of them bought it when I sent them an email telling them it had just launched.
Launching a successful product
In addition to the failed product launch, I did launch a successful product this year. (I don’t consider the book I coauthored to be a product since I don’t own it – the publisher does.) Randy and I have finally teamed up to start offering a workshop for developers who want to learn to build iOS apps. We sold 11 tickets to our first class and are working on our second (which is happening on January 11). We learned a ton when we taught the first one, so we’ve been reworking the curriculum to make the next one so much better.
What we learned
In a workshop, focus on hands-on learning, rather than slides. In our first workshop, we did an overview of Objective-C with slides for the first hour (lecture-style), but when we heard from people afterwards we determined that this first hour of lecture was largely unnecessary. Next time, we’re going to skip the slides and just teach by example, having people follow along as we write code in the classroom. We’ll take breaks to explain concepts, of course, but our next workshop will be much more focused on writing code so our students can learn by example.
Running a workshop is hard. There are lots of things to think about when running a workshop. We had a checklist of things to do; there must have been more than two dozen items on it. A lot of the work was promotion – emailing and tweeting to get the word out to the right crowd – but some of it was preparing the content, getting the room set up, making sure the doors would be unlocked, and other logistics.
Email sells. We used an email list to sell tickets to people who indicated interest at some point in time. It worked remarkably well. We sent multiple emails during the last week of Early Bird ticket sales and included a 20% discount in each. It was a small list, but since it was also a qualified list, tickets sold very well during that week as a direct result of the emails we sent.
I have lots of people to thank for our success this year – some of them are below. I’m sure I’ve left people out, but these are the ones who stick out as the reason we did so well with consulting and product sales this year. I’m mainly listing them here so you can learn from the people I learned from this year.
Thanks to our clients for trusting us to build their mobile apps and get them through issues they’re having. You’ve been excellent to work with.
Thanks to everyone who attended our first workshop and those who have purchased tickets to our second. You’re the reason we’re able to do it.
Thanks to Troy Mott at Bleeding Edge Press for asking me to coauthor Developing an iOS 7 Edge.
Thanks to Launch Fishers for providing a great place for me to work and the perfect venue for our workshop.
Thanks to Brennan Dunn for teaching me so much about consulting this year through the Consultancy Masterclass and The Recurring Revenue for Consultants Bootcamp, making our 2013 even better than 2012.
Thanks to Amy Hoy for teaching me a ton about building and selling products via her blog and various podcasts. I’m on my way to building a profitable product business thanks to you, and you’re the one who taught me what I need to launch a product, which worked very well in selling tickets to our workshop.
Thanks to Nathan Barry for teaching me to teach others in order to build a profitable audience and how the right packaging can significantly increase revenue.
Goals for 2014
I’m very happy with how things went in 2013, and in 2014 I’m planning to focus even more on products and growing that side of our business. I’m particularly interested in growing our iOS Dev Training workshop and in building and selling other related products. And on the consulting side, I’m looking to grow our one-on-one iOS development consulting, so if you’re stuck on an issue and want a second pair of eyes on it, email me and I’ll see if I can help.