10 Rules For Web Startups

Came across this post today, and I couldn't agree more.

Can't Live Without It

I've been using the Alpha version of GT Zen for about a month now, but for the last 5 days I've been unable to use it... and I'm really excited!

You may be wonderi why a software developer would be excited that he can't use his own product.

Is it because the software is horrible?

No.

Is it because the software is so buggy that he just can't stand to work with it anymore?

Nope.

Is it because the software has done such a great job helping him to organize his life that he feels totally lost without it.

Hell Yeah!

On Monday I signed up with the hosting provider that I'll be using for the production system, and the first thing I did was migrate my database over. Since, then I've had some trouble getting the site up on there servers, so I haven't been able to access my actions list. It's now Friday, and I basically feel like I'm lost in the woods. I'm dying without my awesome context interface, and the feeling of having my whole life in one place. So far this is the best validation that I might really have come up with something that people will not only use but will rely on.

Slash And Burn

For the past several months, everything I've read about starting a software/web business has said the same basic thing: start small. Implement the most basic features, and fight with all your strength against feature bloat.

Of course, like any good monkey, I've agreed. I've paid great lipservice to the idea and constantly patted myself on the back for building software that is "bloat-free". Fortunately, today everything clicked. I realized that I've been full of crap. While my mouth has been saying "lightweight", "minimalist", "flexible", I've spent 3+ months building a single page website.

The Talk

Like most people, my first true appreciation of the damage that feature bloat can do was when I installed MS Office 97 and met Clippy the not so helpful assistant. I can only imagine how much time and money Microsoft spent on this totally unneeded feature. I vowed never to do this myself.

The second time that I can recall really focusing on the idea of simplicity in software was when I learned about YAGNI. YAGNI is an abbreviation for "You Aren't Gonna Need It." This is a programming principle that says, "Don't write feature that you think you might need some day, because you're just wasting your time." There are enough things that you do need today, so write tomorrow's code tomorrow.

More recently, I've been fascinated by the company 37 Signals. Their approach is entirely about implementing the minimum features needed to be useful and nothing more. It's an approach that's made them incredibly successful in a very short period of time. Luckily for me, they're also software development evangelists, and are screaming their efficiency secrets from the rooftops. It was their Basecamp & Backpack products that inspired me to head down this path in the first place.

Yesterday was the turning point. Brian Plexico over at microisv.com posted a link to this podcast which is an interview with Derek Sivers, the founder of CDBaby.com. CD Baby is an online distributor of independent music with over $25 million in sales. In this interview, Sivers makes a couple of points that really hit home.

First, he said that he built his site to sell the CDs of 12 bands that had asked for his help. The important lesson here is that he didn't set out to build an global superstore the likes of Amazon. In fact, even Amazon didn't set out to build Amazon. I remember when Amazon first started. I heard about this really cool website that sold books. That's all it did. Ten years later they may be the cornerstone retailer of the Internet, but they started out by picking one product and selling it. They started small and focused, just like CD Baby. All of the other growth came naturally from the single starting point.

The next great point that Sivers made was in response to a question about the Dot Com boom. With a site that went live just before the bubble started growing, Sivers was asked what he did to avoid falling into the Dot Com traps. His answer was astonishingly simple. He sipmly remained focused on being a record store. When venture capalists came knocking with ideas to grow the business, he sent them packing. "We're just a record store," he said. When someone suggested that they sponsor their own independent music tour, he replied, "We're just a record store." The principle at work here is "KISS" or Keep It Simple Stupid. If you try to move in all directions at once, you'll never go anywhere.

Finally, this morning, the camel's back broke. I was reading this blog post and came across a quote that struck me like lightning.

It's very easy to get stuck at this point, with a half-developed product that will never see the light of day. Because nowyou have to stop thinking like a programmer and start thinking like a business owner. Keep cutting features, for a start. Remember, every feature has to be documented and tested and supported.

I finally got it. Features cost money. It's not just the time that it takes to write them, it's the time it takes to document them, support them, test them. These costs go on forever, so if you don't need the feature right now don't add it. It's so simple.

The Walk

With that said, I've made a decision. I'm releasing my product on Monday. I'm going to spend the weekend working like an editor attacking a Costner film. My goal is to turn Wyatt Earp (three and a half hours of crap) into Tombstone (two hours of genius). Come Monday, I'll have a really great Next Actions list.

After that I'll grow slowly. (<-- famous last words)

Swanson's Rules

Check out Bill Swanson's Rules of Management at Reforming Project Management. If you ask nicely (or fill our their web form), Raytheon will send you a copy of the rules. I've also created an MS Word version that prints nicely onto 7 3" x 5" notecards.

Features, Features, Features

Multiple Choice Quiz

Which of the following statements is true:
A) One of the exciting things about writing software is all the cool features that you get to add.
B) One of the most dangerous things about writing software is all the cool features that you get to add.
C) All of the above.

As anyone whose ever fallen six months behind on a two week project knows, the answer is "C".
The Tightrope
As I work to get the first testable release of GT-Zen out the door, I find myself walking a very narrow tightrope. On one side is the dull and unprofitable world of boring software. Software without any cool features simply isn't interesting. People won't pay to be bored, so I've got to make sure that the package has some treats to draw users in. On the other side is the chasm of endless features. Between skype integration, outbound text messaging, drag-and-drop in basket sorting, I could be programming to the end of time and never sell a damn thing. I'm sure that I'd have a great time doing it, but having a great time doesn't put food on the table.

The Balancing Act
So how do I stay on the tightrope. I use my feet, my eyes, and my gut. First I keep moving. Every day I make sure that I'm stepping forward through the program. If I find myself stepping to the side, then I better correct quickly, because stepping off the tightrope is a mistake you make only once.

How do I know that I'm moving forward and not to the side? I use my eyes. I focus on my target and refuse to be distracted. Every time someone says "Wouldn't it be cool if...", I refuse to turn my head. I hear them, and I mentally file the idea away, but I don't let myself become instantly distracted. I know that if my eyes turn to the side, then my feet will surely follow.

How do I know where the target is? That's the magic of the gut. Some people may use their brains here, but I can't work that way. If I'm going to be successful in this endeavor, then I need to trust that I can quickly and confidently decide what direction I need to be taking and stick to it. I use words like simple & focused to describe my target software, but those terms are really fuzzy and won't lead two people to the same place. When deciding where my next target is, I just make a decision and stick with it.

Right or wrong, I have to trust myself and I have to go for it. So that's how I'm navigating this tightrope and here's to hoping that I don't fall off.

Quick Wins

Here's a great post on the idea of Quck Wins. A quick win is a small thing you can do to get immediate positive results.

I'm a strong believer in this principle, and it drives my development cycles.

Another Milestone

Today is the first day that my product is out on a publicly available web server!

It's only about 25% feature complete, but my very small testing group can now start giving me useful feedback.

I can't wait to hear what people think. If you're interested in becoming part of the pre-release testing and having a major voice in the development process, leave a comment here.

43Folders Shout Out

Here's a major shout out to the 43Folders Google Group!

I just posted a question that was basically a summary of my last post, and I've already gotten some awesome feedback!

In fact, I may have even found myself a business partner.

Rock on.

Auto Next Action

One of the features that I'm considering implementing is a way to move the Actions on your project list directly to the Next Actions list as soon as any other actions that they rely on are completed. Here's the summary of what I'm thinking about doing:

• On the site, you will be able to setup a number of "Actions".
• You have the option to put an action into a project.
• If you don't put the action into a project, then it goes on the Next Actions List
• If you do put the action into a project, then you can check a box to mark it as a next action and it'll show up on the Next Actions List
  

The feature I'm considering implementing would allow you to tie actions together by setting a "Relies On" field. When you complete an action, and another action relies on it, then the other action automatically goes to the Next Action List.

For example, I've got to setup a meeting in Los Angeles. My LA-MEETING project will have the following actions.

1. Find hotels in LA (NEXT-ACTION)
2. Reserve rooms (RELIES-ON: Find hotels in LA)
3. Book flights (NEXT-ACTION)
4. Send itineraries (RELIES-ON: Reserve rooms, Book flights)

When I finish item 1, item 2 will become a next action. When I finish items 2 & 3 then item 4 becomes a next action.

Development Priciples Podcast

This podcast by Jason Fried of 37signals is a must listen for any developer or entrepreneur. His insights into creating a truly flexible and efficent organization transcend the technical realm.

I surely will be relistening to his presentation throughout my development process. As an early user of Basecamp, his company, 37signals, is a major inspiration to me.

Eating Dog Food

Eating your own dogfood is a clever term used within the software industry to describe the process of using the software you're developing to help develop the software itself. For example, once Microsoft gets the next version of Windows to the point where it's basically usable, but not really finished, they start using the unfinished product internally. This provides a ready made group of testers to put the product through its paces.

In addition to being a testing milestone, the point at which you're ready to eat your own dog food is also very exciting point for the development team. It is the first time when the team has produced something that actually resembles the finished product.

I can't describe the width of the grin on my face last night when I realized that I was at that point. After weeks of looking at code and dummy test data, I'd finally built a product that I could start to use to GTD!

Of course, the site that I'm looking at on my development system probably won't even resemble the finished product, but I do have a working inbox. From this point on, I'm going to start capturing everything that I need to do within my development process in this inbox. Sure, I don't have areas for the rest of the GTD Flow Chart yet, but, hey, I've gotta start somewhere.

GTD Meets Web 2.0

Not too long ago I picked up the book Getting Things Done by David Allen and became hooked. After years of being a disoraganized slob who never knew what was coming next, I realized the error of my ways. Suddenly there was a beacon of light, a map through the organizational wilderness. Mr. Allen's book provided me with a simple system that promises to allow us to free our minds so we can achieve new heights.

Part of the allure of the system is its abstract nature. Purposefully, the book tells us what we need to do without saying exactly how we must do it. For instance, the book says that we need to keep a reminder list of the next things we need to do across all aspects of our lives, but it doesn't dictate that this list must be on Form 23297-A of the GTD system management portfolio. Likewise, it doesn't dictate some fancy technological gizmo to try to wedge our personal lifestyles into. The book basically asks us to find a system that works and stick with it.

The amazing result of this system is the potential for personal variation and the amazing collaboration that goes on between adherents to find the best solutions for each and every person. Sites like 43 Folders and numerous newsgroups and mailing lists have cropped up to help everyone learn from eachother.

Personally, as I've navigated through this trove of information and opinion, I've yet to find a system that works perfectly for me. PC based solutions won't work because I have two computers at home and several at work. I need to have all of my information available in one place, and synchronizing between all of these systems won't cut it. PDAs and paper based systems also have a major flaw for me. I have to carry them around. Between car keys, house keys, cell phone, wallet, cash, receipts, and all the various other junk that accumulates in my pockets throughout the day, I'm simply out of space. If I thought inbox clutter was bad, pocket clutter is worse!

Finally, I came to the conclusion that I needed to develop my own system, and that the web was the perfect place to host it. Gmail and del.icio.us convinced me that this was the right course of action. After seeing a truely high quality web based email service, everything else just seemed obsolete. These systems are simple, easy to use, and accessible from anywhere.

Once I decided to go ahead and build this system, I then decided that it would be silly to keep it to myself. Instead, I am going to develop a system that will be publicly available and designed with a broad audience involved.

My primary design goals are:

• Ease of use
• Simplicity
• Speed
• Fun! ('cause without fun, what's the point?)

I'll be using this blog to keep everyone updated on my progress and to solicit opinions on features and design ideas.