On July 10, 2008, the Apple App Store opened with about 500 apps: over 40 billion app downloads later, from 500 million accounts, with a choice of more than 775,000 apps, you could logically draw the conclusion that making apps must be rather easy. Truthfully, the technical process is not exactly rocket science, but that, I think, misses the point.
If there were also numbers available on how many of those apps were actually downloaded, used and were found to be useful, that number would probably be pretty small – if you then extract from 'useful', throwing birds at pigs, the number is even smaller. At which point you could draw the logical conclusion that building useful apps is not only statistically unlikely but is also potentially rather hard, and that’s certainly what we found with Guidewire Live.
So why is it so hard? I think some of it is muscle memory – we’re used to building and using very large enterprise applications, millions of lines of code packed with features and functions, indeed RFP’s would indicate ‘the more, the better’. App’s on the other hand are small, do one, or a few things well and have no ambitions to do more, even in the next development iteration, they should continue to do what they do, but better; apps are fast and efficient to deploy into your business process.
Doing that when you are used to building and buying large apps is a bit like fighting nature, we have the urge to pile in more features and consumers like the idea of more and more features as the product matures – that’s value right? We must all fight the urge!
The good thing about apps with focused functionality is that they are small, that means they are faster to build. Apps, can have their own release cycle – they are responsive, they are not beholden to all the other features and necessarily long release cycles of installable and upgradable software. Given the way that apps are hosted and delivered, you - the end consumer of them - get the benefits faster.
Once you get over not building it big, the next challenge we faced was not building a tool, when talking about a tool we find ourselves saying “it could do this and, then it could help you do that”. With apps you need specific use cases and maniacal empathy with the user, you need to have in mind exactly how they will use it, when and for what.
Because I like lists, here are five principles we use when we’re managing our app development. They might also be useful reminders for your internal projects too, even if you’re not building apps per se.
1. Have Empathy: Know who you’re building for – you’ll never get the product or adoption right if you don’t understand who will be using the app, you need to understand when and why they will turn to the app.
2. Always design with intent: Know why you are building it – have a laser like focus of what it is the app needs to do to complete the use case that the end user has given you.
3. Usefulness is not proportionate to size: Know when to stop – this is incredibly important (and remarkably difficult to do), define the app's boundaries, an app is meant to be small. We’re so used to increasing value by adding in more features and functions – don’t.
4. Start with minimal viable functionality: Know when to start again – apps should be developed quickly, initially providing minimal viable functionality. After initial release you should then see how it is being used and take input from users on how the product can be improved. Because much may change as you iterate and learn more, the app is small you may find yourself totally rewriting it, that’s OK, in fact that’s probably an indication that you did the right thing.
5. Be honest: Know when to throw away – some apps just don’t work, but because they are small the investment was small and that’s OK too. Failing fast is better than investing a massive amount up front or continually trying to add more features to see if someone will eventually love your app.