Wombat Mobile Blog

Wombat Mobile Blog http://wombatmobile.com/ Notes from an Indie App Developer <![CDATA[The Downside of Failing Fast]]> http://wombatmobile.com/blog/downside-failing-fast.html
Just an aside, I don't recommend trying to juggle 40 apps and 2+ million downloads on your own. I handle all the development, support, ops, marketing, partnerships, QA, biz admin stuff for Wombat Mobile by myself and got overwhelmed around 1 million downloads several years go. The products have really suffered since then, and, in hindsight, I should have done things differently around 750k downloads.

But that's a topic for another time. It's been far too long since I've written anything. Let's do this.

First off, I LOVE the concept of Failing Fast. It just fits really well with the current App environment. Put out an MVP, assess the interest, and see if it's worth pursuing further. If not, then move on to the next idea. It's less effective for larger platform/infrastructure plays, but most of the startups I run into these days are aiming pretty low.

There are some downsides, though, to failing fast that I don't see mentioned very often.

Definition of Failure

Some failures are easy to spot. Say after 6 months, you've got less than 5,000 downloads or only 100 monthly active users. It might be time to pronounce the project dead. Is there a good pivot option? What's the opportunity cost of spending more time on this idea versus a whole new concept. At this point I'll usually do a post-mortem and take a cold, hard look at what went wrong.

Was the concept bad? Did people just not care? Was the app buggy? Did people not know about it?

If people didn't know about it, then, looking back, maybe that week that I spent working on some esoteric feature for an edge use case would have been better spent thinking about how I was going to acquire users and make things more viral.

But most of the time, it's less clear if a project is a failure or not. You might get some really dedicated users, some good press, but it's not a runaway success. Also, someone running a lifestyle business might have a different definition of failure than a well-funded team. Or the bar for your first mobile app might be a lot lower than after you've had some successes and are looking for bigger upside plays.

Success & Failure Metrics

One of the metrics I like to look at is Time to 10k. How many days did an app take to get to 10,000 downloads? For evaluating interest in an app, I like to first look at downloads. Are people even willing to download the app in the first place? I put on a different hat and mindset when looking at Retention and Monthly Active Users, but that's a topic for another post.

Another thing I look at is the enthusiasm of initial users. I usually get a lot of feedback on my apps either within the app or they'll email me with suggestions. Sometimes people can be REALLY into an app. They love the concept, have dozens of suggestions and become evangelists for the app. I love users like this, I find one of these power users is more valuable than 50 regular users. If I get a lot of folks like this, then, even if overall downloads are less than normal, I have to think to myself: maybe there's something here.

Depending on the concept, I'll sometimes look at revenue when assessing a new project. I made a new app a little while ago that made way more revenue per user than my other apps. The backstory behind it is that it was in a space that I wasn't very familiar with, so to understand it better, I made an app as a trial balloon to become more familiar with it and to reach early adopters in the area. While the overall download numbers weren't as high as other apps, the absurd revenue per user suggested paying more attention to it.

The key for me is just to have the metrics in place from the beginning to match whatever goals I have for the project whether it's downloads, revenue, #referred users/virality, whatever.

A Trail of Abandonware

Another downside to Failing Fast is what happens to the project when you move on to the next one. Say you've got an app with 100k downloads and a nice percentage of active users. There's good interest in the concept and people are happy with the execution, and it makes a reasonable chunk of change per month. It's a nice app, but the upside is limited.

The app makes enough money that you're still supporting it, but creating new features might not be cost-effective, especially when faced with other projects with potentially massive upside.

I usually just leave the server-side of things up and running so that everything still work since folks may have spent a lot of time in the app and would be upset to see it go away.

But there was one time, many years ago, I had to shutdown a project because I was tired of running separate co-located Linux and Windows servers and wanted to focus on just one platform on the server-side. I had written an Evite alternative for people to invite others to events and informal get-togethers. I left it running untouched for a long time thinking all the events had passed, but after I shut it down someone contacted me because they had used the site to invite guests to their wedding in a few months. I still feel bad about that one.

Won't Somebody Please Think of the Users

This is the biggest downside of Failing Fast. That your failure can affect hundreds, thousands of users that embraced the idea. I still get emails from things I've written a decade ago from users asking me if I know of a replacement/alternative for something I wrote and later abandoned.

When I make an app, I often get to know some of my users very well. Some users will email me really excited about the app with suggestions and get a dialogue started. We'll usually exchange a lot of emails, and I try to understand as much as I can about how they're using the app, what they might want from the app, ideas for other apps based on how they use their phones. Sometimes we even become Facebook friends or connect on LinkedIn.

Since it's just me trying to juggle 40 apps, I often have an app's power users determine what should go in the next release sort of like de facto Product Managers. So declaring a project a failure and moving on is a tough decision on a project you've spent a lot of time building with your users together.

This post is getting longer than I'd like, but even after writing out these downsides, I still think Failing Fast is the best way for me to operate. I know too many folks spending way too much time heads down trying to perfect a concept in isolation when they could find out pretty quickly of a project's potential by getting it out in front of users.]]> Seni Sangrujee http://wombatmobile.com/blog/downside-failing-fast.html#comments Tue, 03 Feb 2015 17:30:34 GMT http://wombatmobile.com/blog/downside-failing-fast.html <![CDATA[Winning Google Ship Wars]]> http://wombatmobile.com/blog/winning-google-ship-wars.html
I was skeptical going in, but the event far exceeded my expectations (and not just because I won first place).

Everyone was raving about how much fun it was, and I was amazed how much people were getting into it. It's a credit to the game that after it was over, everyone was talking about wanting to play again and what they would do differently next time.

As for the game, I won't say anything about it out of respect for the creators and the game itself. It's really the most fun when everyone starts off on a level playing field. Prior knowledge going in would taint the process and ruin the fun for future participants. I will say that it's probably the closest I'll ever get to Ender's Game.

It reminded me of the fun of hackathons of yesteryear. These days hackathons are all about the presentation and pandering to the judges and the code rarely seems to matter anymore. Which may be a realistic reflection of the marketplace where sales and marketing often trump the underlying technology, but that's a topic for another blog post. However, in Ship Wars, it all comes down to your code.

It was such a blast, I'd participate again in a second. Although since I won, they probably won't let me participate again, but I would do it even for no prize (or even just to help finetune the game and adjust the gameplay balance/tradeoffs) Heck, I'd even volunteer the next time they run it to help people get up and running.

Plus there was a ton of swag given away:
Ship Wars

(l to r) Android plush doll (traded an Android charger for this), Awesome Timbuk2 Laptop/Messenger bag, Chromecast, Google Mirrored Rubik's Cube, Nexus 7 Tablet, [Attendees received:]Water Bottle, Google Headphones, Play Store Gift Card, Android Lego Puzzlebot]]> Seni Sangrujee http://wombatmobile.com/blog/winning-google-ship-wars.html#comments Fri, 22 Nov 2013 21:13:07 GMT http://wombatmobile.com/blog/winning-google-ship-wars.html <![CDATA[This is what it sounds like when devs cry]]> http://wombatmobile.com/blog/This-is-what-it-sounds-like-when-devs-cry.html DVLUP developer rewards program, and I'm really excited about it. The concept is that developers get awarded points for completing tasks like submitting an app using certain hardware features, attending events, or reaching a certain number of downloads. These points can then be exchanged for schwag or even devices if you accumulate enough.

I think it's a brilliant idea. I participate in a lot of developer programs for various companies, and this concept addresses some of the flaws I often see in dev programs, such as how do companies tell which developers are really engaged and participating. I've seen examples of this at numerous events around Silicon Valley where some folks get given free phones and just turn around and sell them on eBay the next day, and I'm thinking to myself, "Damn, I've been working my ass off building apps on this platform, making hundreds of thousands of users happy, and evangelizing it everywhere I can. I could use a new device to develop with more than the guy who's going to sell it on eBay."

Signing up for DVLUP (which is in beta and look amazing) was smooth and uses a Windows Live ID, but signing up for the Nokia Premium Developer Program didn't turn out to be as easy as I had expected (which doesn't appear to be in beta).

I successfully created a new Nokia account, but then was asked to link my old Nokia Developer account. I can't manage to get past this screen.

The first time I tried it, I got a Single Sign-on redirect error:
LVLUP

The weird thing is that I'm not sure if I entered the right username/password for my old account to link it properly or if I remembered the wrong password. (it's been a while since I've used that account)

So I try a different approach, this time I click on "Forgot your password?" and get this screen:

Oh. I'm going to need my glasses.

Hmm, ok, I'll click the image for a new captcha.

Ze goggles, zey do nothing!

Maybe I need to adjust the brightness/contrast on my monitor

OMG, is this what it feels like when my parents try to use a computer?
Who turned up the degree of difficulty on the Internet?

Could this be some sort of intelligence/psychological test,
where only the pure of heart may enter?

Each year, the Great Captcha rises out of the Internets and picks the mobile
developer that he thinks is the most sincere. He’s gotta pick this one. He’s got to.

Aw, come on!

...to the last, I grapple with thee...from Hell's heart, I stab at thee...

Please, make it stop. I just want to sign up for your
dev program and write some apps. :'(

OK, I get the hint. You're got a reputation for red-hot platforms. Don't play with fire if you don't wanna get burned. But I still want to jump on.

Pretty please?

]]> Seni Sangrujee http://wombatmobile.com/blog/This-is-what-it-sounds-like-when-devs-cry.html#comments Thu, 08 Nov 2012 21:57:00 GMT http://wombatmobile.com/blog/This-is-what-it-sounds-like-when-devs-cry.html <![CDATA[5 Keys to Android and iPhone App Development That Often Get Ignored]]> http://wombatmobile.com/blog/5-keys-to-android-iphone-app-development-that-get-ignored.html
Experiences seem to be mixed. Some have had hits, but more often than not, people aren't getting the downloads that they were anticipating and languish in the "I built it and no one came" state.

It's definitely a different environment now than when both the AppStore and Android Market first opened, and downloads are tougher to come by these days. In the early days, it seemed like you could publish anything and get a nice number of downloads from an app-starved userbase, but both stores are so crowded these days that I've significantly adjusted and refined my approach from back then.

Here are 5 things that I spend a lot of time on that I've seen many indie app developers neglect:

1. Discoverability

This is the most important thing I think about when working on a new app. If no one downloads my app, there's no point in writing it, so I want to do everything I can to get my app in front of my target audience. This was a tough hurdle for me at first having to remove my Engineer hat and putting on my Entrepreneur hat and focus so much on this when the comfortable thing would be to go back to coding a feature that I think is cool but that no one may end up using.

If you look at most of the apps out there, there's only a handful that are truly innovative, most just aren't that interesting from a technical perspective. And I've seen some apps with very impressive technology that just sit there and get ignored. It's fun to write a technically innovative app just for sake of innovation every so often, but it doesn't always pay the bills.

The funny thing about App Discoverability is how much it changes over time and what a moving target it is. I spend a lot of time studying successful and unsuccessful apps to see how people find them, but I'm reluctant to post my findings here since in a few months things will be completely different. I use my less popular apps as trial balloons to experiment with different techniques to gauge what's currently working or not.

App Discoverability is the thing that keeps me up at night these days. When I was first starting out I was deathly worried about that critical bug that crashes and loses someone's data or worried about scaling issues if an app is a hit and take down my servers. But these days I'm pretty confident in my abilities to not lose someone's data, and I look at scaling problems as a good problem to have and means I'm on the right track with a concept. So my biggest worry now is wasting time on something that no one uses.

2. First Time Experience

If I've done a good job with Discoverability, my second area to focus on is the First Time Experience. Now that I've gotten a user to find the app and (hopefully) download it, I want to make the First Time use case is absurdly smooth. I see a lot of people spend all their time on the everyday/repeat use case and completely ignore the first-time user, and the newbie user never gets converted into a repeat user.

One aspect of this is an Intro screen upon initial launch or possibly a Tutorial or Help screens, but that's not everything. The Power Users that use my apps every day want everything easily accessible, but the Newbie user would get overwhelmed by all the options and have a bad First Time Experience. It's a tricky balance, and while I'm developing in app I often fall into the trap of optimizing for the experience as an expert user since I'm so familiar with the app myself and initial the person that's just trying to figure out what the app does.

The goal I'm trying to achieve here is simply to keep the user from uninstalling the app and to get them to launch it a second time.

3. Virality

I get a lot of emails from happy users telling me that they tell all their friends about an app, which I love to see, but it also means I could have done a better job of getting them to get their friends to join by including viral elements within the app.

Here I'm talking about things like Facebook integration, sharing things via email or text messaging. If I'm trying to decide between two features to implement and one feature enhances the solo experience while the other helps make the app more social or viral, I try to tackle the viral feature first and the solo feature can wait for a future release.

If the app doesn't include an easy way for people to get others interested then maybe I need to completely redo my approach or scrap the idea entirely.

4. Return Experience

The questions I'm trying to answer here is: "Why should I come back to this app again?" and "Would I still use this app after 6 months?"

Even though I tend to advocate "throwaway app development", that is to code something quickly, release it out there, then refactor and clean things up only if/when the app is successful, I'm not a fan of "throwaway apps", apps that you install for a few uses and then uninstall.

I prefer to work on apps that provide lots of repeat value for the user. After hopefully cracking the good First Time Experience problem in a particular app, I like to look at the app experience from the perspective of a daily user after having used the app for 6 months.

Actually, looking at my Analytics, I only have one app that has true daily users, which is my Prayer App where people really use it every day. Some of my popular apps like my Wine App or Movie App are more "weekend apps" where the app usage spikes hard on the weekends. Some of my apps in the pipeline fall under what I call "weekday apps" targeting Commuters or IT departments of medium-sized companies.

5. Launch Plan

The final thing that I often see ignored is getting everything ready for Launch. I've fallen into this trap myself. For my first app, I was coding up the last minute and then slapped things in the AppStore quickly together at 3am to get it submitted and I made a lot of mistakes.

Now what I do is start on the App draft (for either the AppStore and Android Market) as soon as I start development. What I'm trying to do is maximize the amount of time I spend thinking about things like what to name the app, picking the right keywords, making the screenshots. I iterate A LOT on an app description (especially the first paragraph, which is usually all that gets shown initially), so I want to spend as much time as possible getting that right. I hate losing people who make it past the Discovery stage, but never reach the Download step.

There's a bunch of things to prep for an app launch that often get overlooked and it's easy to forget when things are getting close to release. I'm talking about things like "what day of the week to launch", or should the paid/free versions have a staggered launch or maybe just go with In-App Purchase off the bat. Web SEO also should have started well in advance of launch and the AppStore SEO strategy should be ready from the beginning, not added later.

Another example, is for some of my apps, I'll have spent the previous few months participating on forums where my target customer hangs out getting to understand their pain points and effectively building the app together through our discussions. In that case, I make sure to comp the folks that helped me out with App Store promo codes or just Paypal (since Android doesn't have a promo code/gift option) when the app launches to get the app in their hands ASAP. They'll either become evangelists or give me honest feedback and tell me I dropped the ball.

Damn, this post wasn't mean to be this long, but I always end up rambling when I talk about apps. I wanted to get this thought out of my head while I had a chance. Hopefully I brought up some interesting ideas to think about when you work on your next app.]]> Seni Sangrujee http://wombatmobile.com/blog/5-keys-to-android-iphone-app-development-that-get-ignored.html#comments Fri, 08 Jul 2011 18:28:30 GMT http://wombatmobile.com/blog/5-keys-to-android-iphone-app-development-that-get-ignored.html <![CDATA[Deciding on an Idea]]> http://wombatmobile.com/blog/deciding-on-an-idea.html "Which Idea to Work On?"

I went to a hackathon over the weekend and must have had this conversation with 5 different people. I'm not talking about the idea to work on for the hackathon itself, but the idea to work on for a startup/bootstrapped biz/side project beyond the hackathon.

I consider hackathon ideas to be completely different animals from startup ideas. For a hackathon demo, the idea really depends on your goal, whether you're trying to win a prize, collaborate on a throwaway project as a way of evaluating potential cofounders, or just trying to have fun. Personally I like to go to hackathons for the mental exercise of a coding sprint in an area tangentially related to where I spend most of my days, or to recharge and get motivated again by hacking with a community, or sometimes I go just to catch up with old friends.

But during the event, while taking a break from coding, the topic often turned to startup ideas. The pattern I keep noticing is that people have so many ideas that they're unwilling to commit to one of them and end up accomplishing nothing. I encounter this a lot, not just at hackathons, but at meetups or grabbing a beer or coffee with ex-coworkers or entrepreneurial friends.

I admit, I'm just like everyone else in Silicon Valley, with a million ideas that pop into my head everyday. I've kept this massive text file called ideas.txt just to record them for over a decade and sometimes run to my laptop in the middle of the night when I can't sleep and my mind is racing about my latest, greatest idea.

Back to being torn between too many ideas, it pisses me off to see this happen over and over again. In my head I'm thinking: "Dude, you're twice the coder that I am, why aren't you kicking ass out there with that idea you're obviously passionate about. I remember when we had coffee when the original iPhone launched, and we were like, "This is a big deal and most people don't even realize it yet. Huge opportunity for early players. Same thing when Facebook apps launched." Some of these guys I've known way back from the dotcom days when we were still going in circles back then.

For some folks I get the feeling that they need some sort of validation that it's a good idea either from investors or peers. I haven't found this to be the best gauge living in the echo chamber of Silicon Valley. There's a tendency here for ideas that cater toward the early adopter, highly-technical, typical Silicon Valley person, where I like to target a broader, general audience.

Other people seem to be reluctant to put something out there out of fear that it will fail. If an idea only exists in the mind it still has unlimited upside.

I used to have this problem of inaction too, and ended up going nowhere by spinning my wheels trying to decide which idea I should focus on. Here's how I got past that…

Let the Marketplace Decide

What I do is take the top idea on my list, the idea that keeps me up at night, the one that keeps coming back to me even after I get distracted by other transient ideas. I go through all the User Stories in my head of how someone would use the app or service and pick the most compelling use case.

I take that single use case and make a Minimum Viable Product out of it. And release it. That's it.

After the app/website is released, a few different scenarios usually emerge:
1. The best case is that users love it. When that happens I usually get a bunch of emails from users asking me to add features. The funny thing is that the features that are requested often aren't the same ones that I had pictured for my app in the first place. So they've now saved me the time I would have wasted implementing those features that no one wanted. One thing I really hate is wasted effort. I remember working at a lot of startups in the 90s where were would spend an insane number of man-hours on a feature and then find out that no one ended up using it.

(In this case, for an app with good momentum, what I then do is take different actions at preset milestones (1,000 downloads, 5k, 25k, 100k, etc). That's a long topic and good subject for another post)

2. Another scenario is I get a crapload of bug reports. This isn't surprising to me as most initial releases are full of bugs. I actually look at this as good news because if someone sends me an email that something is broken that means that they actually care enough about the app to spend the time contacting me and want to see it improved. This means the idea has potential.

3. Finally, there's the case when I get no emails.
a) If I get no emails and there are sizable downloads, I take a hard look at the app and see if I botched the critical "First Experience" or if it's just not that compelling an idea/market.
b) If the app isn't getting any downloads at all, I analyze my discoverability techniques and see if the competitors for this app are getting all the downloads or if users just aren't interested in this area at all.

But during this whole time, after the initial release and while I'm studying how people are using the MVP, I've moved on to implement the next idea on my list.

I'm mostly talking about mobile apps here, where the appstores are set up for and almost encourage this kind of experimentation. As of Summer 2011, it's still a hit-based environment and the various platforms are still touting the number of apps in their stores. Obviously, cloud or hardware or enterprise ideas get a different approach.

What I'm Looking For

The main reason I take this approach is to see if I'm even in the right ballpark with an idea, or if I need to recalibrate the concept and pivot, or cut my losses.

The initial MVP release I'm talking about is not just a simple, non-functional Landing Page disguised as an app, it's a fully-functional, thought-out app, just streamlined to hone in on the most compelling use case, the Raison d'être for the app even down the road after many added features and updates.

This works especially well in the mobile space where a bloated app with too many features can be too confusing and makes for a terrible First Experience. This way the first batch of users (say the first 500 - 2,000 users) can start with a simple app and grow with the app as the feature set gets fleshed out. Many of those users might have been turned off getting bombarded with a massive feature set at the outset.

Another thing I'm looking for is to connect with early adopters/passionate users in a particular niche. Often after an initial release, I'll get bombarded with emails from people even more passionate about an idea than I am, and that's when I know I'm onto something interesting. These folks end up driving the direction of the app better than I could do by myself.

I live in Silicon Valley and most of the people I know are engineers or in technology, but my target audience is completely different for most of my ideas. I don't have an easy way to get out there and start a dialog with my customers, so this way they can find me and we can build this together.

WHAT DO YOU REALLY HAVE TO LOSE?

As for feeling embarrassed launching something and failing, it doesn't bother me. What I often find when I launch something that never gets traction is that there are still a few people that really love the app and kind of adopt it as their personal playground. They never contact me or need any support or use up much bandwidth, but continue to use the app every day.

What I DO find embarrassing is wasting investor money on an unproven idea like we did with a lot of startups in the dotcom era. I remember some of the sites we build that were way overengineered and we ended up with fewer users than employees.

So the main thing you have to lose is the developer fee, $25 for the Android Market or $100 annually for the App Store. For me the most valuable thing is time, so those fees are minimal compared to the potential cost of chasing an unwinnable idea.]]> Seni Sangrujee http://wombatmobile.com/blog/deciding-on-an-idea.html#comments Wed, 29 Jun 2011 22:09:33 GMT http://wombatmobile.com/blog/deciding-on-an-idea.html <![CDATA[Handcuffed by Honeycomb]]> http://wombatmobile.com/blog/handcuffed-by-honeycomb.html
For a long time it was easy to ignore Honeycomb since the emulator was unusable. It was just too slow to do any serious development on it. But after Google gave away Galaxy Tab 10.1 devices to us at Google I/O, that excuse isn't valid anymore.

But I think I've been suffering from Paralysis by Analysis trying to figure out what to do, and it's been delaying updates of my apps, so I've got to make a decision.

One APK or Two

For a long time I've been agonizing over going with one .apk for both phone and tablet versions or separate .apks for each device. I'd prefer to go with just one version like an iPhone/iPad Universal app, but it's such a big change to my existing codebase, I'm uneasy about subjectin all my users to this transition. My apps are pretty stable now and I have a fairly large userbase that isn't asking for Honeycomb compatibility, so I don't want to end up with a bunch of unhappy users for something they didn't ask for.

I've also been looking at making a separate tablet version of my apps similar to iPad HD versions of apps in the iOS AppStore. But I'm not thrilled at making my existing users pay for a tablet version when they already bought the phone version. If the Android Market had Promo Codes like the AppStore does I could gift the Tablet version to all my existing paid users. I'd love to reward the users that supported me, especially those who've been with me from the beginning.

Decision

So after spending months trying to figure this out, I've decided to keep all my existing phone apps on Gingerbread (2.3) and wait for Ice Cream Sandwich due at the end of the year and re-evaluate things.

For new apps, I'm going to go with a combined phone/tablet app in one .apk. I wish I had come to a different conclusion, but I'm picturing a support nightmare for something that will only benefit a few users.]]> Seni Sangrujee http://wombatmobile.com/blog/handcuffed-by-honeycomb.html#comments Wed, 29 Jun 2011 22:08:14 GMT http://wombatmobile.com/blog/handcuffed-by-honeycomb.html <![CDATA[The Customer as Product Manager]]> http://wombatmobile.com/blog/the-customer-as-product-manager.html
But if an app is going to be a hit, I usually have an idea well before it gets to 10,000 downloads because I'll get a lot of emails from users saying "I love this app, could you add feature X or feature Y?"

Sometimes I'll get into a long email discussion with a user about cool things to add to an app, and it soon becomes clear that they're even more excited about this app than I am.

It amazed me when I first found out that some people spend more time using an app than it took me to write it. I was shocked when I saw that users with 2,000 movies in their collection bothered to enter them all in my Movie Collection App or someone with 600 wines in their cellar spent the time putting them all in my Wine Cellar App. Or the number of people that log onto Prayers to Share every night religiously.

These early adopters that reach out to me are so critical to how the product will turn out because they've embraced the concept and taken it in ways I didn't anticipate.

Lean Startup

At companies I've worked for in the past, I'd usually work closely with a kickass PM (Product Manager) or Client, and between the two of us, we'd determine how a product would evolve based upon input from sources like upper management, customer support, founders' longterm vision, users, and immediate fires to fight.

But in the App World of 2011, it's a much leaner process, so these Early Adopters become virtual Product Managers to help me decide what goes into an app. So when I get a random email with a feature suggestion, I'll bounce the idea off this group of Core Users to see what they think of the idea.]]> Seni Sangrujee http://wombatmobile.com/blog/the-customer-as-product-manager.html#comments Sun, 13 Feb 2011 21:27:42 GMT http://wombatmobile.com/blog/the-customer-as-product-manager.html <![CDATA[Saying No to the Customer]]> http://wombatmobile.com/blog/saying-no-to-the-customer.html
When I first launch an app, it's usually just an MVP (Minimum Viable Product) and essentially an experiment to see if there's a audience out there for a particular idea. In the early days, the feature suggestions from early adopters are key and help me flesh out the idea, round out the product, and make a Go/No-Go Decision on whether to pursue the app further.

But for some of my apps that have gotten moderate traction (Prayers to Share with 93,000 downloads on Android/14,000 downloads on iPhone, Movie Collection with 85,000 downloads on Android, Music Collection with 94,000 downloads on Android), it's no longer scalable to implement even a fraction of the features requested.

This is painful to me because I appreciate these emails so much, the fact the someone cares enough about one of my apps to take the time to write and that they've thought about ways to make it better. The Customer Service part of me wants to make users happy, and the Engineer part of me is intrigued by how to implement this new feature, but I strive to avoid bloated apps, especially on mobile where simpler is always better.

Should It Stay or Should It Go?

So the question is, which features to implement out of the bunch that were submitted? For several of my apps, I'm not actually a user since I originally wrote it because someone asked me to write it for them.

What I often end up doing is imagining a quintessential user for a particular app sort of like the political targeting of Soccer Moms or Nascar Dads. This user is usually an amalgamation of the characteristics of several people I know. And the funny thing is that this user is never a power user, which kills a lot of the feature suggestions that will only be used by 2% of the people using the app.

But I do make an exception for a few of my apps. Sometimes I get a handful of users that are so passionate about an app that they effectively take over the direction of the app going forward. But that's the topic of my next post, The Customer As Product Manager.]]> Seni Sangrujee http://wombatmobile.com/blog/saying-no-to-the-customer.html#comments Sun, 13 Feb 2011 20:41:15 GMT http://wombatmobile.com/blog/saying-no-to-the-customer.html <![CDATA[Where Do You Get Ideas For Apps?]]> http://wombatmobile.com/blog/where-do-you-get-ideas-for-apps.html [I get asked a lot of questions about what life is like as an indie app developer, so I've decided to write a series of posts on topics that frequently come up when having a beer or coffee with friends who wonder what it's like behind the scenes. Filed under openkimono.]

One question I get asked a lot is "How do you come up with ideas for apps?" Often I get asked this from a someone who is an Execution Master and brilliant coder who wants to make an app but keeps telling me, "I don't have any good ideas."

I've found ideas come from a lot of sources and there's inspiration everywhere, but here are four sources of ideas that come up often.

My Own Ideas (Overrated)

I have this massive text file called ideas.txt that I've been keeping around forever where I jot down any idea that I find interesting. Sometimes an idea will strike me in the shower, and I'll end up running to my laptop dripping water across the house. Or I'll come up come up with something at 3am and stumble to the office in the dark to write everything down before it escapes my head. The funny thing is, when I read back what I wrote the next morning, often it's never as good an idea as it was the night before.

The problem with a lot of these ideas is that a lot of them are pretty elaborate and not easy to execute with even a simple MVP (minimum viable product). Sometimes it's obvious that there's no market for them. Or they're only viable with key partnerships or need a critical mass of users before they're useful. Others are probably a year or two away from being interesting to people. The current state of mobile reminds me a lot of the early days of the web where sometimes it's best not to get too ambitious. I've been making mobile apps for 6 years, so I've been immersed in this for a while, but when I get emails from customers telling me that my app is the first app they've ever used/bought, it reminds me to keep things simple.

Occasionally there will be an idea that will haunt me, though, that I can't get out of my mind. These are the ones that I try to ignore and postpone until later, but they keep coming back until I break down and build out an MVP. The sad thing is that even after I've built one of these, they're usually not as successful as my other apps. But they're worth doing even as a creative exercise because they're the most fun and rewarding to build.

Lurking in User Forums

I don't do this anymore, but when the iPhone and Android first came out, I would lurk in AT&T, Verizon, and phone handset forums looking for people who would post something like "I wish someone would write an app that does ________." Then I would crank hard, and an app filling that need would magically appear in the Appstore or Market a few weeks later. This was actually pretty successful, but that was when the appstores were less crowded.

Requests from Existing Customers

This is the source for ideas behind my most successful apps. I have a fair amount of users of my apps out there (currently 460,000 downloads with a nice percentage of active users). I get a few emails a week that basically say, "I love your _______ app, could you make one that does ______?"

I love these emails because:
1) If I build this app, I know I have at least one customer.
2) This is a person that I know that actually uses apps and probably paid for one of mine already. They have a need for an app, have already looked for one that does what they need in the appstore/market, and either didn't find any or found the existing options lacking.
3) Usually these are fairly simple apps with a well-defined usecase. I tend to overdesign apps and try to cram too many features in there, but usually these app requests are just a sentence or two long.

App Requests from Friends and Family

This one is tricky. When friends and family find out I make apps, sometimes their response is, "You should make an app that does ______." This reminds me of the early days of the Web again when back in 1996 people would always approach me with an idea for a new website.

It can get tricky when the person doesn't have a smartphone and has never used an app and isn't aware of the 10 other apps already out there that do the same thing. I've done this a few times, and this is a path with lots of obstacles, so tread with caution.]]> Seni Sangrujee http://wombatmobile.com/blog/where-do-you-get-ideas-for-apps.html#comments Tue, 01 Feb 2011 23:50:28 GMT http://wombatmobile.com/blog/where-do-you-get-ideas-for-apps.html <![CDATA[Idea Person vs. Execution Master]]> http://wombatmobile.com/blog/idea-person-vs-execution-master.html
Often the conversation turns introspective as we notice patterns among ourselves. Many of us fall into entrepreneur archetypes that we call the Idea Person or the Execution Master.

Most people are familiar with the Idea Person. This is the person with a million ideas for a startup running through their heads at any given time. Every time you run into them they're convinced their latest idea is the big hit. Their biggest problem seems to be picking one idea and focusing on it without getting distracted by the Next Big Thing.

On the other hand, the Execution Master is the 10x Productive Engineer with an entrepreneurial bent. On a team, they'll take a rough concept and have a prototype or MVP ready before you've even fully fleshed out the idea. I sometimes think of them as Execution Monsters because of the inhuman rate at which they build things compared to their peers as if they're operating at a different clock speed.

"I Don't Have Any Good Ideas"

But the weird thing is that often the next time I run into an Execution Master working solo, they still haven't built anything. In my head I'm thinking, "You're 10 times the programmer that I am, but my side project apps are up to 450,000 downloads, and you're still talking about making your first app like you've been for the past year. A common theme is that they don't have any good ideas, although I suspect that it might be that they don't have confidence in the ideas that they have.

If an Idea Person and an Execution Master teams up, they can often crush it since their skillsets are so complementary, but I've noticed that it's surprisingly hard to try matchmaking and pairing up an Idea Person and Execution Master. That's a topic for another post, though.

Sometimes you'll find a person who is both an Idea Person and an Execution Master, and, in that case it's often best to just get the frak out of the way and occasionally bring them coffee.

Other Types

Another entrepreneur archetype is the Chameleon, who will take on the role of Idea Person or Execution Master depending on those around him/her. Sometimes they'll take on a particular role to blend in with the others or will take the opposite role to fulfill the need on a team.

Yet another is the Poseur or Wantrepreneur, who is more concerned about being part of the startup scene than actually starting a company. No one talks about Wantrepreneurs because, deep down, most of us are afraid to admit that we're neither an Idea Person nor an Execution Master and, sadly, fall into this category.]]> Seni Sangrujee http://wombatmobile.com/blog/idea-person-vs-execution-master.html#comments Mon, 31 Jan 2011 18:59:01 GMT http://wombatmobile.com/blog/idea-person-vs-execution-master.html <![CDATA[How I Price Apps]]> http://wombatmobile.com/blog/how-i-price-apps.html [I get asked a lot of questions about what life is like as an indie app developer, so I've decided to write a series of posts on topics that frequently come up when having a beer or coffee with friends who wonder what it's like behind the scenes. Filed under openkimono.]

I often run into people who are thinking of making an app or are in the process of developing their first app ask me how I determine what price to sell an app. I've experimented with a lot of different pricing strategies over the last few years, but these days I stick with the same formula.

It's probably not for everyone, but it works for me. The reason I like this approach is that I used to waste a lot of brain cycles trying different prices and measuring the effects. Now I no longer spend time thinking about this and just focus on new ideas or coding.

Android Pricing

I'm kind of the exception in that my Android apps make more money than my iPhone apps, so this is where my focus is.

I usually release a paid, full version of an app and a free, ad-supported version around the same time (often the paid version on a Friday/Saturday and the free version the following weekend).

The paid version starts out at $0.99. The intent is to get as many downloads as possible and get feedback from initial customers. The market ranking is also probably affected by number of downloads/active installs.

When the paid app hits 500 downloads, I've usually gotten a lot of emails on what features to add and bugs to fix, and have made several updates. By then, it's a much more polished product, so I raise the price to $1.99. Some apps never reach this point, so just stay at $0.99. I can usually tell fairly quickly whether an app is going to be successful based on how many emails I get from excited initial users asking me to add XX or YY feature.

After the paid version hits 1,000 downloads, I'll raise the price again to $2.99. When I first started doing this, I was fully prepared to lower the price back to $1.99 quickly if sales dropped, but that was never the case, so I don't even consider it anymore.

iPhone Pricing

For my iPhone apps, it's a little different because on the iPhone side you can change an app from Free to Paid quickly. (Don't try this on Android, once you make an app free, you'll be stuck and won't be able to change it back to paid.) There's also the issue of the Appstore approval time, so there's more effort in experimenting.

I haven't done any apps with In-App Purchases or Subscriptions because, as I said, the Android apps pull in the revenue, so get all the attention.

For iPhone apps I've tried some different strategies, but what I do now is release a free app to evaluate the market. Sometimes I'll put in ads right away, other times I'll put ads in an early update. I'll usually alternate between using iAd and Google's Adsense for Mobile Beta. I've had more success there than with AdMob, Greystripe, Mobclix, and others. If the eCPMS are good for a particular app, I'll leave the app as free. If the niche for this app turn out to be bad for ads, I'll switch the app to the $0.99=>$1.99=>$2.99 cycle.

Going Forward/On the Horizon

This is what I've done with Android apps up till now, and it's worked for my personal, consumer-targeted apps. Unfortunately the current state of the Android Market is like the iPhone Appstore circa 2008. In-App Purchases and In-App Subscriptions changed everything in that environment. If the rumors are true and the Android Market gets either of these in 2011, there's a better approach out there.

The current app I'm working on, Field Teams, is also a different sort of animal since it's not a consumer play. It's free and has no ads. For most companies, the free service is all you need. The Pro version is in the works, so…stay tuned.]]> Seni Sangrujee http://wombatmobile.com/blog/how-i-price-apps.html#comments Thu, 27 Jan 2011 19:35:30 GMT http://wombatmobile.com/blog/how-i-price-apps.html <![CDATA[First Look at the BlackBerry PlayBook]]> http://wombatmobile.com/blog/first-look-at-the-blackberry-playbook.html
Here are my notes and initial impressions.

Takeaways from the Event

* 35 million+ App World users
* 2 million+ apps downloaded a day
* 30 million+ BlackBerry Messenger users
* Development options: Adobe AIR first, next is HTML5 (WebWorks), later Native C/C++ SDK for QNX OS and Java
* Background notifications
* Able to add native C++ extensions to AIR apps
* Currently 3 dev options: AIR Mobile, Flashbuilder Burrito, Flash Professional
* Launch Q1 2011
* App World Publisher registration fee currently waived
* 4 touchpoints detected
* bezel is touch-sensitive
* Basic app approval process not extensive, checking for crashes, branding issues (like BlackBerry in App name, etc.)

BlackBerry PlayBook Concerns

1. Many developers I talked to expressed skepticism about the Q1 release based on what's been shown. Normally, I would doubt the Q1 ship date, but it looks like they're trying to beat the rumored April iPad2 release, so assuming a release in March sticks, I'm more worried about a rushed, incomplete product.

2. A lot of developers in the room had trouble getting the dev environment up and running, and these weren't newbies. If I worked for RIM or Adobe, I would ask some random engineers around the company (not on the team) to try following their instructions to get setup and see what troubles they run into. It looks very early, so this is understandable, but this made me be inclined to postpone development and check back later when things have been smoothed out.

3. I think it's great that they're providing so many development options (AIR, HTML5/WebWorks, Native C++, and Java), but this makes things trickier as a developer without a preference.

On other platforms when I've seen a choice like this (ex: Java vs. C++ on Nokia Series 60, or Java vs. Python on Google App Engine), there's a clear optimal programming language option to go with. One language usually is the most up-to-date, most stable, has the most features and support, best sample code, and best community built around it. If you're not developing on the flagship language choice, you'll be banging your head against the wall with a lagging SDK. Companies generally won't say which is the "most favored language", but if you spend some time on each one, it becomes clear. At this point, even though AIR is the first development option for the PlayBook, it's not clear if it will be the optimal development choice in the long run.

4. My biggest concern is broader and is about BlackBerry development in general. We've started development on a BlackBerry version of Field Teams in Java. It's not the greatest development environment and is clearly old tech. I haven't seen any RIM announcements about BlackBerry phones based on QNX, but it appears as if QNX is the OS of the future for both their tablets and phones. So the question for us is how much effort to put into current BlackBerry phone development if the existing phone platform is about to become obsolete. It'll also take some time for the transition to occur, which makes for an uncomfortable waiting period and difficulty defining the product roadmap.]]> Seni Sangrujee http://wombatmobile.com/blog/first-look-at-the-blackberry-playbook.html#comments Fri, 17 Dec 2010 17:58:21 GMT http://wombatmobile.com/blog/first-look-at-the-blackberry-playbook.html <![CDATA[List of App Stores]]> http://wombatmobile.com/blog/list-of-app-stores.html
It's still way behind the iPhone App Store, but one thing I've noticed with Android is that things move quickly once something has been deemed a priority.

I've written some popular Android apps as personal projects that are highly ranked, so I get deluged with emails from app stores I've never heard of before. So I decided to write up a list of all the app stores on my radar as of December 2010 (mobile as well as others, in no particular order). I expect even more to emerge 2011, so this should provide an interesting snapshot to look back on.

I've only submitted apps to a subset of these, but I've included my thoughts on the ones I've had experience with.

1. iPhone App Store
http://www.apple.com/iphone/apps-for-iphone/
There's not much to say here that hasn't already been said. It's still the best by far. My only complaint is the developer/publisher site of iTunes could be easier to use and provide better sales/download stats, but there are other providers that are picking up the slack. The user side is 1000x more important anyway, so as long as users are happy, I'm happy.

2. Android Market
http://www.android.com/market/
The recent changes mentioned above are great, but it's still a distant second. The biggest problems right now are the lack of a website interface for the Market and the fact that users are still having problems getting stuck in the middle of downloading/purchasing apps. Other features I'd like to see are In-app purchase and the ability to gift/comp apps to people.

3. Amazon
We're not supposed to talk about this. Aargh!

4. Windows Phone 7 AppHub
http://create.msdn.com
I ported one of my most popular Android/iPhone apps to WP7 and submitted it a while ago. It's still awaiting approval, but it was a pretty bad experience so far just dealing with the submission/rejection/resubmission process.

5. GetJar
http://www.getjar.com/
I submitted a couple of my most popular free apps to GetJar when they first opened up to Android apps. At the time one of these apps was getting ~500 downloads/day in the Android Market but was only getting 1-2 downloads/day on GetJar. That was quite some time ago, though, I should revisit them again soon. They seem to have kicked it up a notch since then. I expect good things from them in 2011.

6. Verizon VCast
http://products.verizonwireless.com/
The VCast store was tempting because of carrier billing, and I could just submit an existing Android app. Unfortunately, my app was rejected. Most of my apps have a community feature where people can share things like wine or movie reviews they've written. I have a way for users to report abuse, but the rejection message said something about terms of abuse/content policy. There was way too much legalese involved, and after hearing stories of minimal downloads through VCast from other developers, I gave up and abandoned my submission.

7. BlackBerry App World
http://appworld.blackberry.com/webstore/
Haven't used it, but there's a strong chance I'll submit a PlayBook AIR app soon to evaluate the platform.

8. Motorola SHOP4APPS
http://developer.motorola.com/shop4apps/
Only for China and Latin America. Pass.

9. Nokia Ovi Store
http://store.ovi.com/
I signed up for the Ovi Store when the reduced the registration fee to 1 Euro a while ago, but still haven't submitted an app. Nokia is a weird case because I usually say if there are a lot of users, I'll at least publish one app to evaluate the market for myself. Even though I know someone making money in the Ovi Store, I can't put the effort into submitting an app. I think it comes down to having no confidence in Nokia going forward. I used to be a Series 60 developer pre-iPhone and Android, and have been burned before betting on Nokia. Fool me once…

10. Palm Pre App Catalog
http://www.palm.com/us/products/software/mobile-applications.html
I was very tempted to submit a Pre app when they launched because I think WebOS is great from a developer perspective, but never got around to it and it looks like it might have been a good move. I have a friend making respectable money writing Palm apps, but he just bought an Android phone, so I guess that's all I need to know.

11. Chrome Web Store
https://chrome.google.com/webstore

12. bada
http://www.samsungapps.com/
I ported two of my most popular apps to bada, but never ended up submitting them, the process was too messed up. It's not available in the US, so I decided it wasn't worth any more effort.

xx. Cisco Cius Tablet (doesn't count as one, but I'm following closely)
http://developer.cisco.com/web/cius
It looks like Cius is just going to use the Android Market.

13. Barnes & Noble Nook
http://img1.imagesbn.com/pImages/nook/developer/pdf/NOOKdeveloper_FAQs.pdf

How will Barnes & Noble sell my application once I submit them?

Barnes & Noble will make applications available through our eBookstore channels taking advantage of our significant multi-channel merchandising and promotional opportunities.

14. Sony Ericsson Playnow Arena App Store
https://submit.sonyericsson.com/developer/login/

15. Intel AppUp Netbook Apps
http://www.appup.com

16. Steam Store
http://store.steampowered.com/

17. AppsLib (Archos Tablets)
http://www.appslib.com/

18. Handango
http://www.handango.com

19. LG Application Store
http://www.lgapplication.com/web.gateway.dev

20. Bodega Mac apps
http://www.appbodega.com/

21. PocketGear
http://www.pocketgear.com/en/usd/index.html

22. Vodaphone
https://widget.vodafone.com/dev/

23. Opera Widgets
http://widgets.opera.com/

24. Handster
http://www.handster.com/

25. Ondeego AppCentral
https://secure.ondeego.com:8443/appcentral/indexStep2.jsp

26. Orange Application Shop
http://www.orangepartner.com/site/enuk/mobile/application_shop/p_application_shop.jsp

27. AndSpot
http://www.andspot.com/

28. AndAppStore
http://andappstore.com/AndroidApplications/

29. TELUS Application Store
http://appstore.telusmobility.com/

30. SlideME
http://slideme.org/

31. Windows Phone (6.5)
http://marketplace.windowsphone.com/Default.aspx

32. esdn - mobile fair play
http://www.esdn.ws/application-developers

33. Appublish
http://beta.appublish.com/sign-up/

34. Pdassi Android App Shop
http://android.pdassi.de/

35. AndroidPIT
http://www.androidpit.com/

36. Souapp
http://www.souapp.com/]]> Seni Sangrujee http://wombatmobile.com/blog/list-of-app-stores.html#comments Wed, 15 Dec 2010 23:24:14 GMT http://wombatmobile.com/blog/list-of-app-stores.html <![CDATA[Static Blog Generator (What's Old Is New)]]> http://wombatmobile.com/blog/static-blog-generator.html
There's a trend going on to move toward using Static Blog Engines to generate blogs consisting of pure html pages which I think is great. Comments can now be handled offsite using services like DISQUS or Echo (note to self: I need to add here soon). Searching your blog can be offloaded to Google Site Search.

I've been using various blog engines in the past including Movable Type, Blojsom, WordPress, and even a home-brewed solution, but after all these years it's refreshing to have a pure html blog. Some of those solutions had options to generate html, but they seemed lacking.

Benefits of Static Blog Generation

There are several reason I like this idea, some of which may only by important to me:
1. I love the speed when visiting a pure html blog. Sure you can use WP-Cache, WP Super Cache, and WP-SuperCache-Plus to make a Wordpress blog fly, but for the clean, simple blogs I lean toward, a database seems like overkill.
2. I hate installing patches and keeping up with security updates.
3. I'd love to write, edit, and publish using my own editor and a command line, where I spend most of my day anyway.
4. Fewer worries about overloading the server.
5. Focus on writing not site administration.

This post, Blogging Like a Hacker, sums up this feeling the best.

Static Blog Options

There are a lot of choices out there in many languages. This isn't a tough app to write and minimalism is often better, so many people have made their own and put them out there.

Here are some I looked at:

Unix Shell Scripts
NanoBlogger
http://nanoblogger.sourceforge.net/

Utterson
https://github.com/stef/utterson

Python
Pelican
http://blog.notmyidea.org/pelican-a-simple-static-blog-generator-in-python.html

Ruby
Jekyll
http://jekyllrb.com/

webgen
http://webgen.rubyforge.org/

StaticMatic
http://staticmatic.rubyforge.org/

nanoc
http://nanoc.stoneship.org/

Static
http://static.newqdev.com/

Webby
http://webby.rubyforge.org/

Rog
http://rog.rubyforge.org/

Rassmalog
http://rubyforge.org/projects/rassmalog/

C#
Yet Another Static Blog Generator
http://geekswithblogs.net/prabhpreet/archive/2010/05/01/yet-another-static-blog-generator.aspx

Windows App
WebMerge
http://web-procreate.com/wm-about.htm

Perl
BlazeBlogger
http://blaze.blackened.cz/

Using Wget to Create a Static Blog

Out of the options above, NanoBlogger came the closest to what I was looking for. But there's a bit of a learning curve involved, and I'm not sure others here would want to write blog posts that way.

So my solution was to run an old-school database-backed blog (a home-brewed blog engine I wrote years ago) on our staging server and create a script to use wget -r to recursively fetch the site into static html files and publish them to the production server. Interestingly, I first tried using curl which is included in MacOs, but it doesn't seem to have a recursive option.]]> Seni Sangrujee http://wombatmobile.com/blog/static-blog-generator.html#comments Sat, 11 Dec 2010 17:41:18 GMT http://wombatmobile.com/blog/static-blog-generator.html