So what’s the deal with Order N?

They’re still around, successful, and offering custom development services for the Mac and iOS platforms. However, I sold my shares in the company back in October and I’m no longer part of Order N.

What do you do now?

Mainly sit around in my underwear, playing solitaire.

…uh, anything else?

Sometimes I pet my cats, Luna and Pasha.

Alright, I guess we’re done here.

Wait, before you go, let me tell you about my new company.

You could’ve mentioned that earlier.

And miss out on all the interesting tidbits about Mac indie life?

Anyway, so you have a new company?

Yep, still shiny and everything.

…

…

…anything you want to say about it?

Yeah, it’s going to be awesome, sweet, sick, and possibly jivetastic, if that’s still a word.

I’m not sure that was ever a word. What’s the company going to do?

Be awesome. Gonna have our own tree fort and everything. See:

It’s like Panic’s Founder’s Room, only cooler. I’m also working on the official company super secret handshake, but I can’t think of anything after “patty cake, patty cake, baker’s man.”

Wow, there’s so many things wrong with that, I don’t know where to begin. But I see the company name appears to “Fortunate Bear.” Where does the name come from?

Insomnia induced delirium, and possibly the sheer jivetasticness of myself.

Really?

No, I just randomly matched up adjectives and nouns until I found one I liked the sound of, and my wife wouldn’t divorce me over.

Is Fortunate Bear going to be a software company or what?

Oh, right, software. Yes, software will be involved in the process. I’m not much for playing solitaire with real cards. It’s the reason why the iPad is so magical.

Is the whole FAQ going to be this way? Because there’s a netiquette FAQ I could be hosting.

Alright, fine. Fortunate Bear is a software company focused on creating Mac and iOS apps to sell under the Fortunate Bear brand. I am the sole owner.

What about contracting/freelancing?

I might have to do some in the early years of Fortunate Bear, but it will be kept a bear minimum (see what I did there?) and phased out as soon as possible. I am not currently available for contracting. I’m focusing on building my own products.

What can you tell me about the products you’re working on?

I’m working on a Mac app for window management. It’s like Exposé except it doesn’t suck. I’ll be announcing a beta for it soon.

What about Hearts Attack?

I bought the source and rights for Hearts Attack from Order N. I’m renaming it, adding a few features, and changing the way it will generate money. I’m hoping to release it soon, but not until I get my Mac app out.

How can I get more information about Fortunate Bear and its products?

This blog will continue to be the main place I write and make announcements. However, I have a placeholder site for Fortunate Bear. You can sign up for the company newsletter to get announcements about products as well as tips and tricks after the products are released. There’s also an official Fortunate Bear Twitter account you can follow.

Anything else you want to add?

It’s gonna be jivetastic.

Please shut up.

Way back in 2008 the original iPhone SDK came out, and I, like a lot of people, was excited about developing apps for the iPhone. My company is primarily a software development services company so I was mainly interested in learning the SDK so we could pick up iPhone contracts in addition to Mac ones. It also happens to be the case that my favorite card game is hearts, so I decided a good way to learn the iPhone SDK was to write my own hearts game.

After a couple of weeks I had the basic functionality implemented, and noticed I was playing it a lot. I realized then that I could probably make this into a product. Furthermore, releasing an iPhone app through the App Store seemed like a good way for us as a company to begin making the transition from a services based company to a product based one.

If I was going to release Hearts Attack as a published app, I knew the UI and presentation had to be greatly improved. I went through a lot of mockups for the main playing view, including one where everyone’s cards — all 52 of them — were always visible somewhere on the table (a truly horrible idea). Unfortunately I don’t seem to have most of the mockups around anymore, but I found a couple which you can see below. (See the product page for the end result.)

The biggest challenge I had was fitting everything on the screen and it still being legible and usable. By trial and error I figured out how small I could make the cards and still make them tappable, as well as their optimal position to make them accessible with one hand.

I began thinking about what would make Hearts Attack unique or different from its competitors. Back then there were literally just two iPhone hearts games in the App Store, and I felt pretty confident that what I had was already better than them, but I wanted to be sure. I decided on: oddball talking computer opponents, a tutorial that gave not only card suggestions but the rationale behind the choice (a pet peeve of mine), and multiple undo support for mis-taps and tactical errors.

The last step was to get professionals to do the sound and graphics. I ended up hiring a sound designer, a graphics designer, and a character illustrator. The sound design went smoothly, but getting the graphics done was a lot more involved than I anticipated, which is another story for another day. Jordan of OneToad Design created the app icon, playing backgrounds, and the special card backgrounds for the queen of spades and jack of diamonds. Lara Kehler did the character illustrations, which turned out great.

Unfortunately, Hearts Attack went on hiatus in early 2009. I was working full time on an iPhone contract, and simply didn’t have a lot of time to put into Hearts. Secondly, I had lost all desire in finishing it. It was becoming increasingly apparent that iPhone users didn’t want to pay more than $0.99 for anything, despite all the whining I did about it. I convinced myself it wasn’t worth releasing Hearts because it would never make back the money it cost us to make. Hearts stayed dormant for an entire year.

A couple of months ago, I decided to pick Hearts Attack back up again. I had the time and, as someone pointed out to me, it would never make money if I didn’t release it. I was tempted to update the app to the latest SDK (I started Hearts back before you could even use nibs on the iPhone) and add some features. I decided against this, because I really just wanted to ship it. I did have to update it to the 2.2.1 SDK because the current Xcode tools no longer ship with the 2.0 SDK.

Instead I focused on fixing the bugs and adding polish. Fortunately for me my wife happens to be a professional software tester with iPhone experience, so I got lots of good bugs to fix. I also prepared a press release, created a website, and otherwise got ready for the release. After I felt the app was stable enough, I submitted it to Apple on Friday. It was approved on Monday.

At this point, I’m still not convinced I’ll ever make back the money we spent on sound and graphic designers. A hearts card game simply is never going to be a big seller, and price point isn’t high enough to make up for that. Right now, I’m tending to think pessimistically about sales, but I’m going to do what I can to drum up sales and see how things go.

It’s a “wait and see” situation as to if we develop any more iPhone applications to sell ourselves. Of course, regardless of how well Hearts Attack does, we’d be happy to develop your iPhone app for you.

The old design simply wasn’t meeting our needs. Specifically:

• It didn’t communicate clearly what exactly we do here.
• It had a search box which, as far as I can tell, didn’t, and has never, worked.
• It had several pages describing services we don’t perform, at least not when a cop is around. Some of these pages just had boilerplate text in them. e.g. “Item 1″, “Item 2″, etc
• The visual design was really old and unprofessional. The new is at least not old.
• The old feedback form demanded a lot of extraneous information like title, company, telephone number, home address, when you shower, etc.
• It had a copyright date at the bottom of 2002, which caused people to ask: “Are you guys still in business?” This was apparently a barrier to them sending us money.

Fortunately, we mainly rely on word of mouth to get clients, but a bad website certainly doesn’t help our business. We could be missing out on clients who find our website, but don’t contact us for any of the reasons listed above.

I’ve recently had some time between contracts, which I used to think about how a software contractor’s website should be structured and what kind of information it should present. Also, I slept in late a lot. I came to some conclusions:

• It should immediately obvious to a visitor what the company does, no matter what page they land on.
• It should have a portfolio so the visitor can see what kind of work we have done in the past, and see if that matches up with what they want done at the quality level they want.
• A brief description of services that we do provide, explained in layman’s terms.
• It should be obvious and easy to get in touch with us. The form for submitting a message should have as few requirements as possible.
• It should contain a brief overview of the company, and the people in it. It should put a human face to the company.
• Noon really is not a bad time to wake up.

I also decided to add a page for products, mainly for future use.

Overall the project was a fun — and hopefully financially rewarding — exercise. It was interesting to think about what would induce a visitor to stick around on our site, and then actually contact us. I’m not sure if I got it completely right, but it’s at least a step in the right direction.

The Parable of Little Timmy

Little Timmy was a developer at BigCoSoft, but he dreamed of working for himself one day with a product of his very own. When the iPhone SDK came out, he set aside all his free time and slaved over a new iPhone application for months.

When it came to pricing his software, he decided to sell it for the lowest possible price, $0.99, because that’s what everyone else was doing and besides he’d make it all up in volume, whatever that meant. Plus, he already had 12 year old boys yelling at him because the software wasn’t free, and he’d hate to upset anyone.

Unfortunately Little Timmy couldn’t live on $4,000 a year, so he died. BigCoSoft cremated his body in their furnace so they could save $14.67 on their heating bill.

The End.

I realize that some of my readers are engineers, and prefer cold hard facts. So for you my friend, some math problems:

Question 1:	Assume Little Timmy could live off of $50,000/year, before taxes (Note: this means you have to assume Timmy doesn’t live in California, New York, or any big city, but in a farmer’s wheat field in some desolate corner of Iowa.) How many copies of his product would Little Timmy need to sell to eat?
Answer:	Since Little Timmy only priced his software at $0.99 and Apple takes 30%, Timmy only makes about $0.70 per copy. He would need to sell 71,428 copies a year or 196 copies a day.

Question 2:	How many copies a day should Timmy expect to sell, after the initial launch?
Answer:	16

Question 3:	Isn’t Little Timmy just about the biggest moron you’ve ever heard of?
Answer:	haha! Yes!

So now that we’ve finished mocking poor Timmy’s corpse, we should talk about how to price your application before you become firewood.

The Problem

The problem that you’re likely to have, like most developers, is setting a price that you can live on. The temptation will be to price your app too low, such that developing the application isn’t sustainable. You might have the best of intentions, but in the end you’ll cause the premature death of your business before it even gets a chance.

So why might you be tempted to price your iPhone application so low?

Reason #1: Initial store prices

A lot of people were looking at the apps announced at WWDC to see what they would be priced at. In particular Sega’s Super Monkey Ball, priced at $9.99, seemed to receive the most attention. Developers releasing around the App Store launch seemed to use Super Monkey Ball as a barometer as to how to price their app. Unfortunately, most of them seemed to think they needed to beat Sega’s price.

Here’s the thing: engaging Sega in a price war is a sure fire loss. They’re a bigger company with deep pockets and will always be able to undercut you in price. They don’t need make much, if any, profit on their iPhone game, since they have a lot of other products. You, on the other hand, need to make a profit on your iPhone app, and a big enough one to live off of.

Reason #2: Customer expectations

Sega’s initial pricing, and the subsequent following suit of just about everyone else, set customer expectations for iPhone app prices. Developers entering the market in the following months felt compelled to follow the example of the first developers. These feelings were only reinforced by just about every “customer survey” done by TUAW and other bloggers, in which potential “customers” said they wouldn’t ever pay more than $5 for an iPhone application, although they really didn’t understand why those greedy developers felt they needed to charge anything. After all, they could make it up volume.

Unfortunately the blame for setting customer expectations falls squarely on developers. Developers get to set the price, and thus the expectations. By setting the price expectations so low, you are lying to your customers. You are saying “I can sustain development of this app for this price,” when in fact, you can’t. It’s dishonest, and it will kill your business.

Reason #3: Gaming the system

By far the biggest reason why developers price their apps so low is to game the App Store. Applications are sorted by how many copies they have sold. It doesn’t take a rocket scientist to figure out that the lower the price, the more copies an app will sell. The top 100 applications sell tons of copies, while applications outside that top 100 seem to wither away unnoticed. So in order to get more exposure, developers price their applications as low as they can.

The problem is that this scheme only supports 100 applications. Everyone else is hosed. Unless you can get and stay in the top 100, then lowering your price was for nothing.

It is likely that Apple will fix this hole. They want to make money too. For a $0.99 app, Apple is only making $0.30 per copy, which has to cover bandwidth, transaction fees, and advertising. I’m not suggesting Apple isn’t making money off $0.99 apps, but I am saying they’d probably prefer to be selling $9.99 apps.

Reason #4: Short term vision

The App Store is quite young and with all the hype and exposure a few of the first developers struck it rich. This isn’t unexpected for some of the pioneers, but the problem has became that many developers enter the iPhone app market thinking that they too can become fabulously wealthy, just as soon as they release their flashlight app that also doubles as tip calculator.

The problem here is that developers become focused on making money now, instead of nurturing and building up a loyal customer base over the long term. They price their app low so they sell a lot of copies now, but don’t consider how they’re going to make money next year. What is the upgrade price that you charge for a $0.99 app? If it’s $0.99 then you’re not building customer loyalty because that’s not a discount. If it’s free, then you’re totally screwed, because you’re not making any money.

The Solution: $9.99 is the new $0.99

The fix for pricing too low is really simple: raise your prices. Most $0.99 apps should become $9.99, $4.99 apps should become $14.99, and so on. With a $9.99 app, you’d make $7 per copy and at 16 copies per day, you’d make about $40,000/year. That’s not a great income, but that could potentially support one iPhone product being developed in some Iowan’s wheat field.

Without question there will be customer backlash when developers increase their prices. Nobody likes paying more for something. However, the sooner the righting of the ship happens, the better. Customers need to know that most applications can’t be built and supported for such a small amount of money.

On the other side of the equation, developers aren’t going to be eager to be the first to raise their prices. So many are convinced that they won’t sell anything if they raise their prices. Here are some of the potential concerns:

Myth #1: No one will find my app!

This goes back to developers gaming the system. If a developer raises their price, they will sell fewer copies and drop off the top 100, which means no potential customers will find them. There are two possible solutions to this problem.

The first is Apple could fix it so applications that are not on the top 100 are easier to find. It may take a while for Apple to implement this, but eventually Apple will because it’s in their best interest. When this happens it won’t matter what the price of the app is, people will be able to find it.

The second possible solution is to do advertising for the application. This will take some trail and error to figure out where to buy ads at or which adwords to buy, but it can definitely be made to work. Advertising is hard for $0.99 applications, because if you spend more than $0.70 per conversion, then you’ve lost money. In other words, if you charge more you can make sure more people see your app.

Myth #2: But those other people sell it for less!

Competing with another application solely on price is a sure fire way to go out of business. Your product should have a selling point other than the price, whether it be more features, better usability, a unique approach to the problem or all of the above.

There will always be students and hobbyists in the market who can sell a competing product for way less than you. They don’t need to make a living off the app, so they’re not trying to. This happens all the time in the Mac market. If you charge enough for your app that you can make living off it, then you can spend all your time improving it. With that extra time you should be able to make a superior product to your lower priced competitors.

People are willing to pay more for superior products. Unfortunately, with the App Store developers haven’t given them the opportunity to do so.

Myth #3: This is the price the market will bear

Another way to say this is: the price of application is what the market is willing to pay.
I don’t dispute this, but there is another side to this equation.

You also need to consider what the price of building and supporting the application is. If the cost of building the app is greater than what the market is willing to pay, then simply don’t build the app because it will be a failure. Building the application regardless is dishonest to the customer, because you’re in effect selling them what you know will be abandonware.

I also contend that, in general, developers don’t know what the market will bear because no one’s really pushed the price. Everyone is currently in a race to the bottom. The App Store is still in it’s infancy, so no one’s had time to tell if raising prices actually kills the application, or if it just means it takes longer for it to take off.

Myth #4: I can make it up in volume!

I’m astounded at the number of developers who believe that this is true. While it is true that some developers have made a lot of money this way, this isn’t sustainable or practical for most applications. In order to make up for the low price in quantity your product needs to have mass appeal. Furthermore, your potential customers have to be able to find your product, which means you have to be in the top 100 and have Apple feature your product in their advertisements. In other words, you’re betting a lot of this on luck, and the odds are stacked against you. You’d have better odds playing slots at a casino.

Judgement Day

The App Store can’t stay at the status quo. There are three possible outcomes:

1. The App Store becomes a market place solely for hobbyists and students, who can price their wares low because they don’t need to make a living off of them. In this scenario, indie developers aren’t in the market anymore and there is only the occasional BigCoSoft game port.

   Eventually this market would become littered with abandonware as hobbyists and students moved on to other projects that actually pay. The occasional BigCoSoft game would keep the iPhone as a second rate gaming platform.

2. The App Store becomes a market for one off apps and abandonware, where apps don’t progress beyond version 1.0 because there’s no money in it. Apps are simple and cheap to build, and developers rely on the initial sales spike to make all their money.

   The store would become so littered with dead apps that falling off the top 100 would be even more fatal. Eventually the store would die as developers ran out of simple app ideas that would generate a sales spike.

3. Developers begin pricing their products in a way that is sustainable. Developers who price too low eventually die off, unable to develop their products further. In this market, prices go up, which encourages indies and BigCoSoft to build and release many apps and games for the iPhone.

There will be an iPhone app bust. The current prices simply aren’t sustainable. Either developers will crash out of the market when they discover they can’t make a living off their current prices, or the gold rush developers will lose interest and leave when they realize they can’t make a quick buck off the store. The developers left standing will be the ones who set reasonable prices for their applications.

I’m willing to put my money where my mouth is. I currently have an iPhone app in development, and when it comes out, I will price it $9.99 or higher. I’ll let you know how it goes for me.

As far as pricing goes, the general consensus seems to be that iPhone applications can range from Free to $10. I got this mainly from just looking around on the App Store and checking out the prices. That said, Medialets has some interesting data about App Store pricing. The sweet spot seems to be $5, especially for games, with only big name companies being able to command a full $10. Since Apple takes 30% off the top, my app could potentially make anywhere between $0.70 and $7.00 per unit, but on average I should expect $3.50/unit.

Now that I have an estimated price that I could charge for my app, I need to know how many units of said app I could reasonably expect to sell in a year. Unfortunately, this is where the data gets really scarce.

I found (or have been sent) ten articles where people reveal actual sales numbers. Unfortunately, there is little context for the numbers, and sometimes they are for one day only. This makes it impossible to draw decent conclusions from the data, as I don’t know if the numbers are anomalous or not, or what part of the cycle they come from (right after release or after the app has been sitting out in the hot sun all day). The ten articles are:

• Part-time apps developers getting rich
• iPhone App Store’s Brutal Reality: Get Viral Or Don’t Quit Your Day Job
• Rebound Development: App Store Story Part 1
• Donkeys and Pickaxes
• Mouse House Sales Figures
• Sharing some stats – iphonesb | Google Groups
• Sales for week 1: 10/30 – 11/05 and Sales for week 2: 11/06 – 11/12
• Analyzing App Store sales data
• SuperSubnet Calculator sales stats
• OHai sales stats

The articles contain data for twelve different applications of varying popularity with varying levels of advertising. I’ve also been sent data privately for eight other applications. I’ve summarized the data in the table below:

Some statistics of “average sold per day” from this data: Min: 1, Max: 777, Median: 49, Mean: 114.

As I said earlier, it’s hard to know if these numbers are at all representative of what’s actually happening with most applications. Still, these are the only numbers I could find, so I’ll try to do something with them.

Looking at this data, there’s clearly a worst case scenario: only selling 1/day while only making $0.70/unit. That would mean I’d only make $255.50/year. Don’t sell the bike shop yet, Wilbur. The best case would be selling 777/day while having a $9.99 price point, which would earn me $1,985,235.00/year or just under $2 million a year. That’s not very realistic though.

If I assume an average price point, $4.99, with what the data says is the mean of sales per day, 114, then that means I would make $145,635.00/year. That said, 114 sounds high to me for a real average. The 777 figure in the calculation seems to push the mean higher than I should realistically expect. So if I assume the median, 49, at the average price point, $4.99, then I would make $62,597.50/year. Or the minimum of 1/day at $4.99, then it would be $1277.50/year.

I’ve summarized the possible units per day discussion in the following table:

Disclaimer: I’m using “mean,” “median,” etc in the mathematical sense, based on the whopping data set of twenty presented above. I’m not suggesting that these are the numbers you will actually see.

I have to admit, the number of units sold per day sounds high to me, even with the 60 a day figure, although 16 per day might be reasonable to expect. I can’t tell if the quantity of apps sold is simply the nature of the low price points for iPhone applications, or if it is a temporary anomaly caused by the newness and novelty of the App Store. All the numbers are from the first year of an application. I wonder about the sustainability of the rate, and at what point would I saturate the market. I strongly suspect the number of units sold per day is going to eventually come down, and the cost per unit will have to go up.

I’m unconvinced that having one or two iPhone applications as a sole source of revenue is sustainable. Earning $4,000/year seems like the most likely scenario (at least after the first year), and that’s simply not enough money to live off of.

Addendum: As a point of comparison, here’s some data on free applications:

As they say, there’s a huge price increase from free to $0.01.

P.S. What this article really needs is more data. If you’ve released sales numbers, please leave a comment with a link to it. If you’d like to contribute, but remain anonymous, send me an email (see Contact tab above) with the numbers.

Don’t all thank me at once.

My Story

The story of my rise to Cocoa fame (hey, no snickering in the back!), is both interesting and inspirational, especially if you don’t bother to check up on any of the “facts,” or know what the word “fame” means. So here goes.

First, I should point out there was no such thing as “Cocoa” when I was in school. It was all Toolbox, non-opaque structure, procedural, event polling, love. But since that’s what Mac programming was, that’s what I taught myself during college. I even wrote three tiny freeware products and released them. (Please don’t google for them, that’s exactly the sort of blackmail material I don’t need.)

Second, I got a lucky break. After I graduated from college, the Macromedia Texas office happened to be hiring. I managed to con them into taking me, undoubtedly dazzling them with my total lack of experience, huge ego, and inability to correctly pronounce the word “boil.”

Third, Macromedia fortunately turned out to be a large uncaring corporation that sufficiently pissed me off enough to curse them and leave. Then I went to work for myself as a Cocoa programmer.

The End.

hmm… maybe that isn’t as inspirational as I first thought.

Where ever you go, that’s where you are

OK, in all seriousness, there are things you can do to increase your chances of being a professional Cocoa programmer. The first thing to deal with is your location. There aren’t many (read: none) Cocoa jobs in Tennessee or most of the southeast. So you’re going to need to find your ticket out of Squaresville.

I did it by being hired by a large company, Macromedia, who paid for my move. They moved me to Dallas, which, being a large city, has more Cocoa opportunities and hail storms than Tennessee. One of the things that helped me get hired was that I had previous Mac programming experience, and that I had released some freeware. Real word experience, whether you made money off of it or not, goes a long way, especially if you just graduated from college.

However, I should point out I really didn’t get to be a Cocoa programmer at Macromedia/Adobe. Most of their apps are Carbon based (like me) and I don’t see that changing anytime soon. It will probably be a similar situation at most large companies with established products. At the time of my departure, the only shipping Cocoa app Macromedia had was the Extension Manager, because I rewrote it in Cocoa in my spare time.

Anyway, my point is you need to find a way to a city with more tech jobs, like San Francisco, New York, Boston, Raleigh, D.C., or, to a lesser extent, Dallas or Austin. It’s the only way to a Cocoa job and true happiness.

Don’t be a sucker

So I was actually lying about having to leave Tennessee to get a Cocoa job. Only suckers do that.

The best way to be a Cocoa programmer is to just be a Cocoa programmer. Work for yourself; create your own products. Of course, there is the whole problem of making money. It takes a while to establish a product (usually a few years) and sometimes weak people need to eat in that period.

When you’re self employed there are three ways to generate money while you work on a product: contracting, venture capital, and angel investing (i.e. your parents). Contracting is what we do, and what most small independent Mac companies do. The only problem is that if you’re right out of college you won’t have many connections (which is important, seeing 99% of our work is from referrals) and a lot of people don’t want to hire contractors with no experience.

To get venture capital you need to have a great idea that needs lots of people and money, and you need to be willing to give it up to the venture capitalists. I don’t know of any Mac companies that went after venture capital.

The big advantage of staying in Tennessee (other than it being Tennessee) is that it’s cheap. And that’s very important when you’re self employed.

Expanding my ignorance

I’ve kind of ignored one last option you have, mainly because I don’t have any experience with it. That is, to go to work for a small Mac company (such as Panic, Delicious Monster, or the Omni Group). I don’t know how often they need to expand, and how many new graduates they can absorb and train. But it is an option.

Working for a small Mac company has the same advantages of being self employed in that you can concentrate on the Mac, but probably has the disadvantage of not paying as much as a large company could, and having to live where the company is.

Anyway, you have a few options to becoming a Cocoa programmer. I’m very partial to working for yourself, but that’s partly because of my previous experience with working for large corporations. YMMV.

I knew it was dead back in 2003 when they laid off everyone (save a couple of people) on the core FreeHand team. They kept it alive for a while to do an updater with the few remaining people, then transitioned it off to India.

The somewhat odd thing was that the team knew FreeHand MX was going to be their last release. I remember a certain FreeHand engineer’s response to the question “why are you trying to cram so many features into this release?” as being “Because they’re not going to let us do another.” And to their credit, FreeHand MX was a return to their roots: vector based graphics program for print. At least from this observer’s perspective, it felt like FreeHand MX was the best FreeHand version in a while.

I’ve always had a soft spot for FreeHand, as I suspected most of my fellow Fireworks-ers did. After all, FreeHand and Fireworks were the only shipping products that were developed in the Texas office. Furthermore, Fireworks had been started by engineers from the FreeHand team.

Being so close in proximity, Fireworks and FreeHand often “borrowed” engineers from each other. When Fireworks was about to ship, we’d steal a couple of their engineers to help fix bugs. Conversely, FreeHand borrowed engineers from us, the Fireworks team, if they ever got behind. During the FreeHand MX cycle, I had the pleasure of spending about three months working on FreeHand, fixing bugs and bringing it up to par with the “MX” branding.

The most disappointing thing about FreeHand was Macromedia never let it live up to its full potential. After FreeHand fell behind Illustrator in market share, they pretty much ceded it. They had Dreamweaver and Flash, which were now their big money makers, and pretty much lost all interest in the print world. They kept trying to force FreeHand to be Flash, or to at least remake FreeHand for the web, instead of focusing on what FreeHand did best (print), and capturing that market.

Anyway, I digress. I’ve known for a few years that it was a dead product, but I’m still saddened to see that its official now.

P.S. Please note that FreeHand is the only product name with intercaps. i.e. Note that the F and H are capitalized in FreeHand, while in Dreamweaver and Fireworks, only the first letters are. This was a big pet peeve of the FreeHand team.

P.P.S As a technical aside, most versions of FreeHand (save the most recent ones) were written in a home grown language, that was humorously, and appropriately, called OOPS (Object Oriented Programming System). It was basically a preprocessor that generated C code that was then compiled to machine code.

At this point, I think we’ve got enough ideas, and we just need to pick one and move forward with it. The question is: which one?

I wrote up a process document on how to pick any idea (which is below), but I’m wondering if its the right way to do things. So I have a question to those of you have built your own product(s) (or are in the process of doing so): How did you decide what to build?

Did you simply build what you wanted to? Did you do research and find a product gap and fill it? Did you try to find the idea that you thought would generate the most money or the most users? Did an idea just hit you one day and you decided you had to make it?

My “process” for creating and picking an idea follows:

The purpose of this document is the establish a simple, lightweight process for coming up with and evaluating product ideas. The process should result in at least one idea that we can turn into a viable (read: profitable) product. The process is flexible and can be changed as circumstances change or as better ideas are introduced. The process evaluates ideas based on business factors, not engineering factors.

1. The first step in the product idea process is generating ideas (i.e. brainstorming). At this point in the process the ideas are vague and not well defined. The purpose of this stage is to generate as many ideas as possible, without evaluating them. The hope is that enough ideas are generated that a few of them are viable both engineering and business-wise.

Ideally, at the end of this step, we should have at least a few hundred ideas to choose from.

2. Second, after generating all those ideas, the next step is to whittle them down to a manageable number so we can do research on them. This will probably be between 10 and 20 ideas. By applying some simple criteria, we should be able to arrive at the top ideas we might be able to pursue. Ideally these criteria do not require research, but can be answered easily and quickly.

Criteria:

- What user problem/pain does this solve? If it doesn’t solve a problem, no one will buy it.

- How is the user going to pay for it? Or how does the product generate money? If a cool idea can’t generate money, its not worth it. A lot of Web 2.0 apps fall into this (like digg, YouTube, etc). They solve problems, but they don’t make money.

- What is the potential customer base? i.e. Is it consumer, professional, or developer level product? This will help rate the ideas – a consumer product is usually more valuable than a developer product since there’s potentially a larger customer base.

- Without architecting or engineering the product, is the product even technically feasible? If we’re trying to make cold fusion work, we should probably pass on that for now.

These criteria probably will not eliminate all but 10 or 20 ideas, but they should help us rank them and pick out the best 10 or 20 ideas. Some ideas might have to be fleshed out a bit more, but hopefully even vague ideas can be evaluated at this step in the process.

3. Next we need to research the top 10 or 20 ideas. This means fleshing them out a bit more so we can make more critical decisions about them. The research is targeted at finding out how much money the product might bring in, how likely we are to attract customers, and what building the product might cost.

What we need to know:

- How big is the potential customer base? This is an extension of what kind of product is it: consumer, professional or developer. Do a lot of people have the problem this idea is trying to solve, or is it a niche problem?

- What can we charge for the product? What is the competition charging? Not trying to determine final pricing here, but what is the range we could expect.

- How will we sustain income with the product? Upgrades, subscriptions, ads?

- Is there any competition? If so, who is the leader? What makes the leader, the leader? Can another product be sustained in this environment?

- What are the core/basic features in the product? We don’t need or want a feature spec here, just a general idea of what we’re providing. This should help with cost of building as well as what we can charge.

- What will set us apart from the competition? i.e. Do we think we can actually capture part of the market?

- What are the engineering costs in regards to time? i.e. how many engineers for how long? We don’t need a real number, just general estimates so we can compare it against the other ideas.

- What is the required infrastructure to make this work? This would obviously be bigger for web apps which need a large number of servers. Don’t forget about add ins to do try-before-you-buy or other demo schemes.

- What kind of marketing might we need to make the product a success? Mainly we want to know how expensive it will be to market the product.

- Are there legal or other expenses (like facilities or sales people or development software) that are required?

4. Finally, we need to evaluate the product ideas based on our research. Knowing how big our customer base is and how much we can charge will give us a ballpark of how much money the product could potentially bring in. The competitive analysis and feature ideas will give us an idea of how much of that money we might be able to get. The engineering cost estimates and required infrastructure costs will give us an estimate of the total cost to build the product.

So the basic “value” of the product idea is:

(Potential money in the market) * (Part of the market we get) – (Total costs of building product) = Profit

That’s real scientific stuff. Please don’t take it too seriously.

We’re not going to get hard and fast numbers out of this step, but it should give us a vague idea which idea is more valuable, business-wise, than the others. At the end of this step we should have at least one (if not more) idea that we can then take on to the product development process.

Once again, this is a light weight process that can (and probably will) change as we learn things. If you have ideas, suggestions, or comments about how to make this better, please let me know.

As you can tell, my process focuses on what product will bring in the most money. While money is good, I don’t want to build a product that I won’t enjoy working on.

What are your thoughts?

8am – Wake up, scratch self, turn over, fall back to sleep. No respectable software engineer gets up this early.

8:15am – MacBook Pro’s dancing in my head. Unless you’re my girlfriend, in which case, I only dream about you baby.

9am – Wake up and realize I do not own a MacBook Pro. My dreams crushed, I see no reason to remain conscious, so I scratch myself, turn over, and fall back to sleep.

9:30am – Apartment maintenance personnel decide that I have slept long enough and begin pile-driving two feet outside my bedroom window, where in the alley they have apparently decided to construct a large shopping center.

9:31am – Contemplate the needed trajectory of a rock that would injure, but not kill, said maintenance person. I might need my ice maker fixed at some point.

9:35am – Give up on plan to maim maintenance personnel because it would involve moving a part of my body, and, let’s me honest, who doesn’t want an large 24-hour supermarket directly outside their window?

10am – Unsure if I am yet awake, maintenance personnel begin mowing what’s left of the grass outside my bedroom with a bush-hog machine.

10:01am – Stagger the 10 feet from my bedroom to my “office.” Manage to stub my toe on no fewer than seven objects. As required by law, at least three are more dense than depleted Uranium.

10:02am – My now semi-awake brain discovers that the computer/printer combo doesn’t not provide this “food” that the Wizard needs, badly.

10:03am – Stagger over to the refrigerator. My agile feet know the path well, and manage to run into the same seven objects.

10:05am – Think about how good a breakfast with scrambled eggs, bacon, and blueberry pancakes would taste. Unfortunately, I am a bachelor so anything that cannot be made from hot-dogs and month old bread is out of the question.

10:06am – With hot-dog flavored “PopTart” in hand, return to the computer.

10:07am – Digg and Slashdot.

11:03am – Decide to actually “work.”

11:04am – Start pulling down code to work on with Perforce, the Fast Software Configuration Management System. The file set consists of three small text files, one resource file, and a large image file describing how the software system works, assuming they had actually built it that way.

12pm – Lunch, which is a hot dog, stale bread, or some combination thereof.

1pm – Perforce, the Fast Software Configuration Management System, actually completes the synchronize operation, leaving me with three small text files, twenty corrupted resource files, and someone’s half eaten pimento cheese sandwich.

1:01pm – Consult Digg and Slashdot, while contemplating why anyone uses Perforce.

2:00pm – Remember that people use Perforce because the alternatives are worse. For example, Visual SourceSafe is a service by Microsoft in which they send a salesman to your place of business to kick you in the seat of your pants repeatedly. In the Professional version of SourceSafe, the salesman also steals your credit card and purchases a site license for Microsoft Money.

2:01pm – Attempt to log into the client’s bug database, so I know what to work on. Discover that I do not have access to bugbase, which is on the internal network, because I did not file a business case for why I need it, three years in advance.

2:05pm – Call the client’s IT department, explain that I need network access from my Mac. To avoid getting the wrong software, keep mentioning that I am using a Mac during any awkward silences and anyplace in the conversation a normal person might say something like “hello.” Sensing my urgency, IT promptly sends me five copies of the Windows software.

2:10pm – Call IT department back to explain that need Mac software, to which I am promptly told “We do not support Windows 98.”

2:15pm – Finally reach the one Mac IT person, whom they apparently keep locked in a cage in the basement, and feed old PowerTalk documentation. He cannot send the software via email because of the 32 byte email attachment limit, but he is able to smuggle out a CD of the software, on the back of one of the many fruit bats in his cage.

2:30pm – Discover that VPN software does not reliably connect to client’s network, but does, in fact, waste a large amount of space on my hard drive and not uninstall.

2:31pm – Call IT department again to explain VPN software does not work. IT carefully explains that I must either rewire my apartment, reconfigure my router so that it is solely and permanently connected to their network, or move to California and/or India for VPN to ever work. They are not sure which. Smoke signals are suggested in the interim.

2:45pm – Randomly change settings in the VPN configuration until I can actually connect to the internal network. Discover that although I can connect, I have no security access to any servers on their network, including the bug database. Furthermore, IT has decided that, for reasons of productivity, anyone connected through VPN should not be able to access anything outside their network, such as, for example, the computer sitting right in front of me.

2:56pm – Call IT department to be granted access to the bug database. The IT person that I reach calmly explains that, yes, he can grant me those privileges, but won’t, because he strongly suspects that will allow me to do actual work.

3:03pm – Have my contact within the client company call IT and explain that its OK for me to do work because I do not work in IT.

3:30pm – Feel smug about getting to bill client for all the time IT wasted.

3:31pm – To celebrate victory over IT, Digg and Slashdot.

3:52pm – Examine the first bug I am supposed to fix, which is marked as “severe” and a “crasher.” It states: “When I press Command-Q, the application quits.” I spend the next hour on the phone explain why that is expected behavior. The phone call ends with the quote “Well, that’s stupid and Apple should change it.”

4:52pm – Digg and Slashdot.

5:23pm – Examine the next bug I am supposed to fix. Although it is simply a misspelled word that has been in the software for seven years, it has now become “urgent,” “must fix,” and, “severe.” Oddly enough, the bug was entered by a technical writer.

5:33pm – Open up Xcode, Apple’s integrated development environment, specially designed for the Mac user who has lost the will to live.

5:38pm – Change the resource string to fix the misspelling, which the previous engineer was unable to do, because, apparently, he could not locate the second button on his Macintosh mouse.

5:50pm – UI designer notices that I fixed the misspelling, and suggests other improvements to the wording, such as rewriting the host operating system from scratch to use more color gradients.

6:04pm – While muttering under my breath about out of control UI designers, Digg and Slashdot.

6:45pm – Examine the next bug, which is from a customer, requesting that we add support for XML file formats and the ability to shave an enraged badger. After serious consideration, I decide to defer the bug for next time.

7:02pm – Receive call from marketing demanding to know why XML files/badger-shaving feature was deferred. They cite numerous customer anecdotes in which they needed the portability of an XML file combined with the ability to shave an angry badger. Most cases involve alcohol, in which the badger had consumed prodigious amounts.

7:30pm – Look at code for the first time today.

7:47pm – Marketing calls back saying what the customer probably, really, honestly, truly needed was a way sober up the badger. They swear the badger is a nice guy, but only acts that way when he’s drunk. Plus he has a bad 5 o’clock shadow.

8pm – Receive call from potential client, asking if we could port his Word processor for Windows to the Mac for twenty nine cents and a large portion on his company’s stock, currently held in a gum-ball machine.

8:28pm – Starving, I crawl to the refrigerator, where I discover a veritable treasure trove of food, in the form of Cheerios, underneath the fridge.

9:02pm – Realizing I am spending too much time reading Digg and Slashdot, I go read Dilbert, Get Fuzzy, and Pearls before Swine.

9:18pm – Return to code and marvel at the fact the compiler has not openly mocked the code in iambic pentameter or simply refused to compile it out of principle.

10:07pm – Digg and Slashdot.

10:41pm – iChat with business parter in which we ridicule Xcode’s speed, code quality, and inability to shave an enraged badger who’s had a few too many drinks.

11:11pm – Notice that the auto-complete in Xcode is actually recommending other, more reputable companies I could be working for.

11:38pm – Digg.

12:06pm – Slashdot.

12:49am – Change egregious code “if ( foo ) doFoo();” to the much more sane “if ( foo ) { doFoo(); }”, on the initial thought that I get paid by the character.

1:22am – Discover the entire Xcode help file is one page that recommends using a better IDE, such as MPW.

1:30am – Change the completely erroneous “if ( foo ) { doFoo(); }” to the actually readable “if (foo) {doFoo();}”. Note the bytes saved by the removed whitespace on my accomplishments.

1:40am – In an attempt to find a snippet of code in my project, Xcode inadvertently finds life on Mars. Still unable to search an arbitrary directory in less than ten steps.

1:44am – Change “if (foo) {doFoo();}” to “if ( foo ) doFoo();”, and wonder what fool added the unnecessary braces and removed the spaces.

1:54am – Against doctor’s orders, read old copies of Inside Macintosh, Volume 1 until I fall asleep. He recommended a large mallet to the head, for the reason that it is less likely to cause severe brain trauma.

As you can see, the life of an independent software engineer is not for the faint of heart. No doubt you have more respect for me now than you have ever had before.