My Latest 8 App Development Mantras
During a hackathon, we’re constantly evaluating whether “it’s worth it” on any given problem.
By Anna Billstrom (iOS & Facebook App Developer, Self)
Maybe, perhaps because I’m an English major, I tend to notice patterns in my speech.
I noticed recently that I keep saying the same phrases in discussions regarding mobile app development: secret sauce, no login, no back button, mentoring, phase 2, did the customer want that, don’t say user, and is it needlessly complex?
These discussions came up in hackfests, in client work, and in advising on technical projects. What the repetition of these phrases means to me, is that I need to reinforce certain concepts.
So we all like Lean Startups and Customer Development, but are we essentially practicing those behaviors in our day to day work? The fact that I have to repeat them means that they’re having a hard time sinking in. You can know something, but to do it is another thing entirely.
What this app actually contributes, essentially, that is different in the market. The copyrightable, trademarkable essence. The actual chemical recipe for turning water into wine, for example. It’s the core concept that you’re testing, and everything else is a distraction, and muddies the customer testing. You need to narrow down the experience to highlight this secretsauce.
It’s very hard to start a project and not begin at the login process. But, you know what? Logins are assuming that people are going to come back. It’s not actually a pre-requisite for an app. You can grab session information, conduct a Facebook login later down the line, heck, just leverage Facebook entirely for login, etc. There are other options. Is it part of the secretsauce? Largely, it’s not.
No Back Button
I really hate them. It assumes that it’s important to store the customer’s “state” at all time, and it assumes that it’s core to the app idea or “secret sauce”. Back buttons are key to making a bloated big application with lots of overhead programming. This was a revolution in thought to me, to exclude them, and now that I’ve gotten over it, I’m not going back!
I’ve met really horrified faces when I say this, but it’s true. Integrating a back button means sometimes three times more work, so only include it if it’s part of the “secret sauce.” Usually, users can go through a flow and come back to home. No back button.
Basically it’s a license to mentor, coach, or delegate the work to someone else. You hire a mobile developer, but you can also, (gasp) hire a developer to MENTOR you in mobile development, and then you can (gasp!) do the stuff yourself. You know, teach a man to fish, etc. It’s key to find someone who has good teaching skills, knows their stuff, and has time and interest (it’s non-competitive) to teach you.
During development, you will think of new things, and they will be great ideas. And you should keep a list of those ideas. And you should not involve them in the current phase. You should say no. Say no to the new idea. Keep focused, deliver the secret sauce.
Did The Customer Want That?
During development, you will think of new things. They will be awesome things. But you know what? You’re not the target demographic. I think the hardest part of customer development is not making an app that is precious and owned and used entirely by you, but spread out in the world and owned and used by others. So you have to constantly validate new ideas by the customer base (when you get them). We’re too close to the project and our opinions and use cases aren’t really worth much, essentially.
Don’t Say User
From Sarah Allen, who said in a talk, “Why call them users… are they drug addicts?” that cracked me up. Stylistically it’s outdated to call your customer a user. We are not all at terminals with our keyboard inputs. We’re at the playground watching our kid, checking Facebook, or in a club taking photos of old college friends, etc. Getting an idea of your customer and thinking of them that way is a big fat step towards making relevant, good apps.
Recently at a hackfest my only feedback on a PowerPoint pitch for an art festival presentation was – “call them festival goers” because it’s going to show that we “get it” to the judges. It shows you’re connected to the customer and not a bot.
This is an old concept in customer relationship management, but still is so maligned and not used, it’s sad. Basically, getting used to saying “festival goer” is halfway way to actually getting to know, and develop cool stuff, for your customer. Imagine going into a Disney pitch and saying, “user” instead of “parent” or “delighted kid” (who will become a parent, of delighted kids, etc.).
Is It Needlessly Complex?
A great thread on a geeky point probably worth an entirely new blog post, this thread brings up some key points – essentially the original poster wrote an abstracted class against the wishes of his client, and he was terminated.
I don’t consider myself a great programmer – my strengths are not in impressing other geeks but impressing my clients and making great apps. One mantra that helps me “get it done”: I don’t make a routine, method or subclass unless it’s merited by repeat use. Essentially, don’t go all abstraction unless you need to. I can overprogram shit on my off hours.
Certain architectural decisions are smart, some are needlessly complex. For example, off-loading logic onto the server, because you’re going to do two mobile versions, and you are using the iPhone simply as an interface controller: good idea. Building out a data model and data feed for a series of buttons that could be static in the first version: needlessly complex (and, assuming that the options will change without customer input… “phase 2? and “did the customer want that”).
Do you have mantras? Would love to hear, if you do.
This post was originally posted at Banane.
About the guest blogger: Anna Billstrom is an iPhone and Android mobile developer, specializing in social apps. She’s worked at Momentus Media, a startup that made the “8 Bit Your Pic” for Black Eyed Peas app, which saw 2 million users in 2 weeks. She’s done the gamut of OLAP DB modeling to Java development and Ruby on Rails. Follow her on Twitter at @banane.