process

2. Under Process, Over Deliver

January 31st, 2007   |   by fbadmin

(Part 2 of a 5 part series: “So, you need to develop a product?“)

I’ve learned that more process doesn’t necessarily equal higher quality and it definitely doesn’t result in increased productivity. The level of “process” required also depends heavily on the product, industry, maturity of a company and the size of a development team. For example, a dot.com should require less process than an enterprise software product. A dot.com is centrally hosted and can be changed anytime. On the contrary, enterprise software needs to be fully tested before a release because it typically affects a customer’s business process. (Consumers are certainly more resilient to bugs than businesses.)

I’ve seen a lot of companies try to apply a “one-size-fits-all” development process to a wide variety of products. I don’t believe a one-size-fits-all process exists. It is important to look at the type of product that you are building and apply the appropriate level of process to it, and adapt it over time as your business evolves. Particularly for consumer web sites, things don’t have to be perfect all of the time. Try to find a good balance between moving fast and producing quality. We have all seen small, scrappy startups outpace venture-backed or established companies. I believe it is because they make speed their mindset and process takes a back seat.

At Starting Point (Startup 1.0), we didn’t have a QA team. We had millions of users visiting our site on a daily basis. We considered our users to be our QA team. We would quickly build a prototype of a feature, launch it on the site and instantly get feedback and make changes. This helped us develop better features, and it also created an extreme sense of urgency for our engineers. Once it was out there, there was no turning back and the priorities instantly became clear. There was never a question as to what we should be working on because our users made it very clear to us. Further, there were also a lot of half-baked features that we would introduce that wouldn’t gain any traction. We killed them right away and ultimately didn’t waste time on things that we normally would have if we had fully baked it before launch.

Sure, some of the features broke often. It required us to always be on our toes. But, we were always gaining 10X more users because of our innovation and losing a very small percentage because of quality. As long as our new user rate far outweighed our lost user rate, we were satisfied. We outpaced many of our competitors (including some that raised 10’s of millions of dollars in venture capital, while we had raised $0) and our search site ultimately became the 7th most popular site on the Internet.

Don’t let the methods get in the way of results…

Next… Virtual Location, Location, Location (Part 3 of a 5 part series: “So, you need to develop a product?“)