Category Archives: Success Factors

General writings on building a successful business.

Guessing Ones Way To Success

Posted on by

In 1997 I was graduating college and looking for real world experience writing code. I had majored in business, not computer science, and realized my folly way too late. A friend of mine was working for a publisher of Newton software titles and was getting all excited about this little device called a PalmPilot. What the heck, I said, and dove in.

Soon thereafter, 1999 if I am reading correctly, a little company here in Portland formed named Panic [1]. Panic came about to develop some really killer Mac software. I don’t know much about their story, only bits and pieces that I’ve read over the years and even though we are in the same town I have never met them, but that is all besides the point. Panic bet Apple, I bet Palm. At the time it felt like a smart bet. But here we are 13 years later and Apple has become one of the largest companies in the world and Palm is gone.

The point is luck plays such a huge part in all this. It could have easily been us Palm aficionados hearing earnings calls a day and a half ago and realizing we made an incredible bet. Instead, the platform we bought into 15 years ago faltered, sold and failed. The platform Panic bought into exploded.

So I was telling my story to someone today, talking about the decisions we made and the platforms we chose, and she asked me, what advice or input could I have had that would have helped me correct course? And I told her none. The bet we made, the bet on Palm, the bet on education, was the right bet at the time. There was no way to foresee the stupidity of Palm’s management, the dumb decisions and missed opportunities.

We all make these decisions, a platform to bet on or a technology to buy into. And it’s nearly impossible to correct if the decision proves wrong. So to all of you that guessed right about Apple long before the iPhone and iPad turned the company into a juggernaut, congratulations! You more than deserve the success you are experiencing now.

Please, though, leave a little for the rest of us.

—

[1] If you love a great story, you’ve got to read the story of Audion, a Panic Mac app. Not only is it amazingly well written and entertaining, but it just makes me cringe to think how close to history these guys got! (Don’t go yet, though. Finish my post first.)

Once We Have Attention Then We Only Have Trust

Posted on by

All of this discussion about trust really started with me thinking about the role of trust in building a business. Building Infinity Softworks has been all about building a relationship with my customer. At the center of that relationship is trust. Trust, then, is the only true currency we each have. That’s the bottom line, isn’t it? And when the trust is gone, so is the relationship.

That’s where SOPA and PIPA failed. The entertainment industry lost our trust. The government lost our trust. This is the fundamental problem facing Google, where it has bastardized search results to ensure that Google+ is at the top. This is why no one really trusts Facebook. The company builds itself on privacy but every time money is at stake Facebook is more than willing to throw privacy out the door.

In the early days of building a company we have a choice: we can ask for money today or ask for money tomorrow. If you ask for money today then we are each attempting to make money before we have built a trusting relationship with the customer. If we wait and make money tomorrow then we have built a relationship with the customer before asking her to pay. Once we have trust, the relationship between the company and customer is much stronger and worth a lot more money.

Unless I am referred [1], I have no knowledge of who you are and no interaction to trust you.

In the old days there was little choice. We walked into retail stores and asked a clerk or shelled out $50-200 because we had no options. But now the App Store has 500,000 titles and the Internet has 450 million web sites. We have option overload. Now we need different methods of building trust: free versions, freemium business models, trials. Without those we drop the price to $.99 and hope it is too low for anyone to care, even though they do. Funding, too, has become a currency of trust. If I have it then someone must have decided this was a good product and worth trying.

This mentality isn’t just invading the tech world, though, it is invading everywhere. Companies that don’t make the transition, from automatic trust to earning trust, are all going to die.

—

[1] In this case the trust is inferred and built off of the relationship between the referee and referrer. This is why my dad trusts my opinion about technology but doesn’t trust my opinion about coffee, since I don’t drink it.

Applauding Decision

Posted on by

Designing “Mute”

I didn’t comment on the latest Apple-du-jour controversy, this one surrounding the mute switch on the iPhone. (I always wonder if it had been a BlackBerry whether anyone would have paid attention.) Frankly, Marco Arment said exactly what I would have said. Good design means trade-offs and settings mean indecision. Sometimes that indecision is appropriate but we can’t, as developers, punt on every trade-off.

When I write software there are millions of small and large trade-offs. Everything from where to put a button to whether to include a feature. I hate trade-offs like the mute switch because I hate “except” features. You know: it mutes except… I think it is hard for customers to remember the except clause and know when to apply it. And it’s even worse when you add an “if” statement. IF the setting is A then the mute mutes everything and if the setting is B then it is mutes everything except. That just doesn’t work. So as a designer and developer, I must make the decision. Did Apple make the right one? As Marco points out in this week’s podcast, it hasn’t been an issue for 4.5 years so they must have.

Speaking of Marco’s podcast this week, he also commented about leaving out features that just don’t fit into the product correctly. I’ve done the same thing with powerOne. The most requested feature is folders for organizing templates. But every time I revisit the feature I can’t figure out a logical way to make it work successfully. Sure, I can slap folder support in but it doesn’t feel right to me. I’ve implemented a handful of variations and still don’t like it. So I don’t include it until it feels natural and the logical way for powerOne to organize its calculations.

Bottom line: every decision made when designing software is a trade-off. Making the right ones is the hard part. And that’s why we get paid the big bucks!

The Single Box Theory of Software Design

Posted on by

I would like to propose a new software design principle I would like to call The Single Box Theory. My Theory is as follows: the closer your software can get to using a single box the more likely it is that customers will adopt it.

Google Search has a single box and is brain-dead simple to use:

Twitter is the same way:

The closer our designs gets to a single box, the easier the product is to use, the less explanation it needs, the more magic the app appears to have.

I’m not saying this is easy. Email has three boxes — to, subject and body — and most people believe this is as good as it could possibly get.

But is it? Here is Facebook’s Messages interface. It has only two boxes:

I find it weird to think that two boxes is that much simpler than three boxes but it is. One less box to fill in means one less decision to make, one less minute to complete. It means the customer is way more likely to use it.

The problem with multiple boxes is that only the most anal retentive among us will be willing to fill them in. I don’t want to spend my days figuring out which boxes to fill in with what data. I just want it to be done. How many people fill out all the appropriate iTunes info?

Or fill in all the contact info every field the Address book asks for?

I believe most people’s Address Books, for instance, have half completed data and information in it. Very few people really want to take the time to make sure it is all entered and it is all accurate.

But structured data requires multiple boxes, right? After all, I need to tell the service what goes where so it knows how to catalog the information, make it sortable and searchable, transform it into reports so I know how I am doing. Here is a screen shot from Highrise:

How could a product like this get away with fewer boxes? I won’t say it is easy. I will say it is necessary to make a product more usable, though, and to get more people to adopt it and stick with it.

As developers we need to work a little harder, think a little longer, about how to reduce the number of boxes. It is possible. Take a calendaring application. Traditionally it has lots of boxes: event, location, date, time, from, to, etc:

All of this seems necessary but it isn’t. Think hard about the 90% rule: what will people need 90% of the time and satisfy that need while also making it easy for the anal retentive among us to get access to the rest. Even something as reliant on structured data as a calendar app can accomplish this:

It is amazing how many boxes we can eliminate when we put our minds (and programming muscle) into it.