By Frank Addante
(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?")
By Frank Addante
Development resources are in high demand. As more venture capital pours into startup companies, it is becoming harder and harder, for small and big companies alike, to find good development talent. Development costs go up, loyalty goes down and companies spend more time recruiting and interviewing, thereby diverting from their core focus. Recently, a lot of people have been asking for my advice on how to deal with this growing challenge.
The bottom line is that it is hard to find good engineers. There are a lot of people out there who can "write code", but very few good engineers. Here's the good news -- you only really need a few really good engineers. Beyond your initial core team, in my experience, you'll see diminishing returns as your development team expands. Further, your core group of really good engineers will set the tone and example for everyone else and will likely always represent 80% of the value delivered by your development team.
My next five posts will be focused on 5 tips that I put together for dealing with the tech resource challenge:
1. Scrappy versus Steady
2. Under Process, Over Deliver
3. Virtual Location, Location, Location
4. Build a SWAT team
5. Outsourcing
1. Scrappy versus Steady
(Part 1 of a 5 part series: "So, you need to develop a product?")
During the beginning stages of development, I personally think the most important thing is to have a small team of "Scrappy" developers. Scrappy developers move fast and have the agility needed to accommodate quickly changing product requirements. Personally, I think the best products are designed, architected and built all at the same time. (As opposed to the traditional methods of spec'ing out a product in advance with well-defined documentation and then handing that off to a development team.)
As your company, development team and product grow, the process will likely need to become more formal. That's when you'll need to introduce "Steady" engineers to add some balance. Steady engineers tend to move slower, but at a more consistent pace, and are more focused on quality.
Scrappy engineers have great vision, they tend to be their own product managers and they do a great job creating very appealing, innovative products. However, they are easily distracted, become unfocused and very rarely document anything (can become a problem if you lose them or as you grow your development team). Scrappy engineers may also be more likely to sacrifice quality for innovation.
Steady engineers bring focus, quality and process. However, they often times are more impressed with the methods than the results. They will slow down the development cycle and you'll get less features, less often, but the product will be of higher quality. Steady engineers are likely to sacrifice innovation for quality.
Bringing in Steady engineers too early could result in a less competitive product, bringing them in too late could result in instability.
Personally, in the beginning stages (pre-version 1 through v2), I like to have 100% of my team comprised of Scrappy engineers. As the product reaches maturity, I like to have a balance of 70% Scrappy and 30% Steady. Scrappy engineers are harder to find and keep motivated than Steady engineers, so achieving this ratio is definitely a challenge.
How do you identify a Scrappy engineer? Well, first and foremost, it is not by their resume. Their resumes likely show them bouncing around from job to job and they probably aren't very well-written. Some of my best engineers have had the worst resumes (or sometimes no resume at all). I've hired some of my best people straight out of college, taxi cab drivers and have even stolen coffee makers from Starbucks. Some of these people grew to be my most talented and influential engineers. (Yes, I did say taxi-driver and Starbucks coffee maker, and yes, those are real stories. I found them by noticing the books that they had around for reading during their downtime at work; books on C++, Perl, PHP, etc.) I found my Scrappy engineers by judging them on passion, pride, creative personality and most importantly those who had an extreme desire to learn. Experience was one of the last things on my list.
Whether it be a search engine (like Starting Point, Startup 1.0) or an enterprise software product (like StrongMail, Startup 5.0), I have always employed this principle and it has never failed me.
Some have argued that my Scrappy principle only works for small, startup companies. I've personally seen big companies such as Ticketmaster and MySpace do a great job building an extremely talented team of highly motivated, Scrappy engineers. I asked the President and COO of Ticketmaster (formerly CTO) how he is able to attract and keep such a Scrappy, motivated team at such a large company. He simply said that he makes sure that they always have "interesting problems to solve."
So, find Scrappy engineers, hire them, motivate them, keep them happy and keep them challenged. They will be one of your most valuable assets.
Next... Under Process, Over Deliver (Part 2 of a 5 part series: "So, you need to develop a product?")
