Building Community Through Mobile

I used to do a lot of presentations and panels, but not lately. Until the last two weeks. Tonight I’m on a panel at Puppet Labs about Building Community Through Mobile.

As the page says:

Hear from our panelists on how social media content, advertising and design factor into the growth of mobile communities. Learn how communities have come to the forefront of business development, customer retention, customer research and other operational functions. Find out what the future looks like as communities dominate our conversations.

Click here for details. I know I’m looking forward to it and hope to see you there.

Build Businesses, Not Apps

I’ve spent the past five years attempting to understand the changes to the software industry brought on by the iPhone and the app store. Most importantly, I’ve been asking the fundamental question of how we, as software developers, transition into this new era.

Last Monday at Mobile Portland I was able to give this presentation. It’s an expanded version of the one I gave at CocoaSlopes last fall, which was not available on video. I am introduced around the 7:15 mark, if you’d like to skip ahead.

Please enjoy and, if you’d like to follow along with a copy of the slides, please download them here.

All images were found via Google search images. Attributions are on a slide at the end of the deck. In addition, sources for all data and quotes are available on individual slides via the links in the lower, right corner.

Good Reads VI

As I mentioned last Friday, I have a bunch of links saved up. Last week’s links were business-oriented. This week’s are for fun instead of profit:

The Best I Can Do Is Learn From Mistakes

The best I can do is learn from mistakes. I will always make them.

When we released version 4.0 of powerOne, apparently, it was quite controversial. I guess I should have anticipated that since iOS 7 was so controversial and we were following Apple’s design aesthetic here. We changed colors within the app, darkened the calculator, removed lines around the buttons, etc. I and everyone I had shown it to thought it looked incredible.

Some of my customers didn’t, though.

Oh, boy, did I hear about it. Some were polite, offering constructive criticism, and some, frankly, were bordering on belligerent. I didn’t take it the wrong way, though. Their passion for our products far outweighs any negativism they could throw my way.

We reacted as quickly as we could. Each email received a prompt response, sympathizing and telling him or her that we are formulating a plan. After a few days to make sure we had much of the feedback, we developed a plan, executed that plan, and released a new version. We decided to add themes to the calculator, simplify the breadth of colors, and revert some back to the 3.0 originals. I wrote a blog post and sent it to all those who emailed, making sure they were okay with our direction before developing it. Finally, after approval yesterday and today, I emailed everyone to tell them the new versions are available.

I’ve always cared deeply about providing incredible customer service. I believe this is part of the reason our customers are so loyal. We try to respond to emails within an hour of receiving them and try to treat our customers with the respect they deserve. After all, they paid us money for our products.

Some Of The Worst Start-up Advice I’ve Ever Read

The irony is this comes on the heels of my talk Monday at Mobile Portland (video and slides coming soon) where I spent 40 minutes outlining options and advocating over and over again to stop, think, and do what is best for your business. But here it is from First Round Review, which usually has incredibly good articles, The Five Mistakes Startups Make When Building for Mobile. In short, here are his five myths and realities:

  1. Myth: Building apps natively per platform is a waste of time and money.
    Reality: If you want a five-star app, build natively. Period.
  2. Myth: My backend infrastructure is ready to support mobile apps.
    Reality: You will need to change, upgrade, or completely rebuild your backend to create the best mobile experience.
  3. Myth: You can build your mobile app internally as fast as an outside firm.
    Reality: Building your app yourself will take 4x the time.
  4. Myth: If I outsource to a mobile development firm, I won’t have to do any work.
    Reality: For the best outcomes, clients need to be heavily involved with the firms they’ve contracted.
  5. Myth: Once I start working with a development firm, I’ll be stuck with them forever.
    Reality: Working with an external firm at first can make it even easier to build internally in the future.

First thing is first: this guy is biased. He works for an outsourcing firm so I’m not surprised he is advocating outsourcing everything.

Second things second, I don’t have a problem with most of it. #2 is probably correct. Adding any new platform, interface or screen dimension may very well require backend changes. #4 is definitely true and #5 is true, too, although sometimes it is hard to pick-up other people’s code.

#1 and 3, though…

However you slice it #1 is bad advice. No, a five-star app does not have to be native. I’ve seen plenty of excellent applications that use HTML5 or use a combination of HTML5 and native code. All of our apps use native and HTML5 to a certain extent. Equals note interface, for instance, is all HTML5 — it was by far the best way to do it at the time we started working on it. Equals also uses a lot of native code. Equals also uses a ton of ANSII C. Anything written in HTML5 and ANSII C can be ported to other platforms so it is our goal to minimize the native Objective-C, Ruby and Java that we use, and we are willing to do that for anything that would feel natural even when it isn’t native.

#3 is also odd. How important is the code to your business? Do you have more money than time? Do you have an outsource contractor who you can have a long term relationship with? Do you have development skills? Is this a skill set you need to be successful? How sure of your product are you? Do you need to be making rapid changes and tweaks, releasing code on a weekly, daily or multiple times per day basis? How much time can the contractor give you? Will they act as apart of your team or is this a throw it over the wall to get it done situation? How active will the contractors be over the long run?

Anyone who has been around the block will instantly know that the author’s advice needs to be considered. Anyone who hasn’t, though, may believe it hook, line and sinker. And that’s what bothers me.

In all cases the answer is, it depends. And the only way to determine which way to go is to know who you are, what you are trying to accomplish, where you are today and where you want to be tomorrow.