If you are like me (and condolences if that is the case) you wake up every day with an idea for a mobile app. The hardest part about designing and building mobile apps is determining what NOT to include in the release. The app should be compelling enough to entice users to download it and reviewers to review it, but not too complicated to require months or years of development prior to launch. Eric Ries calls this the MVP or Minimum Viable Product.
My goal is to launch an MVP within 45 days of design completion. This means that you’ve already completed the design specifications, the rough wireframes, the first and second design comp AND the final design. This can take months or weeks, but I’d argue that if you’re really working on it, ‘design completion’ should only take 30 days. In my experience it really takes four people to design and build an application in this 30 + 45 day timeframe.
Product Manager – Owner of the product vision
UI/UX Designer – The artist responsible for the look and feel
App Developer – The guy who builds the frontend that’s on your phone
Backend Developer – The guy who builds the backend on a remote server to make the app work
I’ve done it with more and less people, but I’d argue that any fewer resources and you compromise the timeline AND quality. Interestingly, having more people will similarly compromise the timeline and quality. You need enough other people (i.e. three) to help you get a quality product out the door, but too many people (i.e. four or more) and you risk having too many cooks in the kitchen. Two frontend developers will just get in each other’s way. Your app shouldn’t be so complicated that you could easily divide the work between two developers. The same goes with the backend. You can have two UI/UX people, but again, it will likely slow you down because you’ll have more choices. Sometimes choices lead to paralysis. Finally, if you start getting more than three other people involved you’ll need a project manager and then he’s going to want everyone to attend regular meetings to get everyone on the same page. You’ll argue about everything. Some of your folks will get frustrated and undermine the project. Stay small and lean as long as possible.
If you’re not an artist or developer AND you’ve got the idea for the mobile app you are the ‘product manager’. It is your responsibility to determine the who, what and why (even where). This is actually a full-time job. First, you’ll need to work with your designer to determine how to create a user interface that meets the what and why of your app. If you’re smart you’ll keep reducing your idea over and over until your app does ONE thing really well. If there are TWO things you think you can really do well don’t include the second on your first release. You’re going to learn a lot from your first release – mainly that launching a mobile app is a lot harder than you thought. Additionally, you’re going to want release that second big feature in your second release – i.e. to get reporters, reviewers and new users to get in the game. Don’t blow your wad in the first release.
We’re knee deep in the development effort of the CultureMap (CultureMap’s Mobile App) and everyday we’re removing features and functions from the first release. Interestingly, the app is getting better and better the more we cut out of it. The most important thing to start is to release your application quickly. Don’t build up expectations – just do one thing really well and ship. You can start working on the second release the moment the first release is in the market, but you might want to take a break and focus on quality assurance and customer feedback before adding something new to your app. You might want to read my post about NOT building a mobile app unless it includes three important things.