By Frank Addante
My team is sure to crack a smirk every time someone asks me what our timeline is. They smirk because they know exactly how I’m going to respond. I say, “we like to go fast, but we don’t hurry”.
A startup company’s strengths are centered in its abilities to move quickly and be agile. I believe that the success-rates of all of my companies is largely due to speed being ingrained in the company culture. Having said that, there is a very, very fine line between “going fast” and “hurry”.
At my current company, the Rubicon Project, our top priority is product development. The very first day that we opened our doors, we started developing. We didn’t wait for planning meetings, we didn’t discuss strategy, didn’t discuss architecture, didn’t talk to customers, didn’t look at similar or competitive products , didn’t write specs or requirements. We just started developing. Our goal was simple – get a product to market as quickly as possible so that we could get real market feedback.
You, like most people, might be thinking - how’s that work? How do you ensure you develop the right product? Well, it’s simple. First, acknowledge the fact that the first version of your product is almost NEVER the right product. It’s simply an exercise for prospective customers to tell you what they DON’T like about it. Second, we talk about the product every day. It is top of mind for everyone. We plan and develop in real time. Third, we acknowledge that we WILL waste time. What was waste in “redo” we gain in momentum and speed. Speed is contagious.
Having said that, while we make speed our mindset, we are careful never to hurry or move at a pace that we are not comfortable with. How do you know when you go from moving fast to hurrying? First, it’s when communication breaks down. It’s like running a long distance. You always want to be running at a pace where you can still speak. If you are running so fast that you are out of breath and can’t speak, your body is going to tire out and won’t be able to go the distance. Continuous communication is key. Second, it’s when you make careless mistakes. You will make mistakes, many of them in fact, but careless mistakes are a sign of hurrying. Third, and most importantly, it’s when you’re moving faster than the market.
Pace is something that is top of mind for me personally right now. My team’s ability to move fast and execute has astonished me and, as a result, gives me new found levels of confidence in the business. In less than three months, we have developed a “whiz bang” prototype of the product, have had about 30+ high quality meetings to solicit (positive, encouraging, constructive) market feedback from website publishers, have hired over 10 A++ people (all of which are firing on all cylinders), have planned a big upcoming event with an overwhelmingly positive response and have already started working with ad network partners. All of this in less than three months time and ahead of plan. It sounds like I am bragging, but that is not my intent. I’m trying to give you a real world scenario of balancing fast with hurry. The team has been exceeding my expectations, therefore, we are moving at a pace that’s faster than I had originally planned. That combined with the fact that the online advertising market is on fire these days and the problem is only intensifying, makes me anxious to accelerate our plan. Do we launch the product and the company sooner? Do we invest more capital into the business to grow it faster? Do we hire more people? How much insight should I give the board into the fact that things are moving faster than planned? (and risk elevating expectations) These are all questions I ask myself. My emotions tell me to go faster, logic and fear tell me to stay the course. My gut tells me to set some short term additional “accelerated validation” goals and measure ourselves against these accelerated goals in the next 30 days. If we can step up the pace (go fast) and it doesn’t break (hurry), then we’ll accelerate the plan.
Every team, every company and every market has a different pace. “Fast” and “hurry” are different for everyone, but you should always recognize that there is definitely a line. It’s a fine line, but there is one. Know what it is, always be aware of it. Use it to push you to move faster, but also let it humble your over-zealousness.
By Frank Addante
(Part 5 of a 5 part series: "So, you need to develop a product?")
Outsourcing has become a popular topic and practice these days. I have been outsourcing to India since before it became popular. Cost was definitely one of the driving factors, initially. However, these days, the cost benefits are quickly declining as prices in India continue to rise and productivity decreases due to factors such as declining loyalty and retraining. I am still a big fan of outsourcing. Why? Primarily for the intellectual capital and the flexibility.
I’m going to break this down into 8 areas, give a little background on each and give each area a rating (1-5, 5 being the highest). I will give each area a rating for today and a comparable rating to what it was 5 years ago. Since India still seems to be the most popular place to outsource, I will give my ratings based only on my experiences (directly and indirectly) on outsourcing to India:
Cost (Today = 2; 5 Years Ago = 4):
Costs in India have been rising as competition for resources grows. While still considerably less then the U.S., it is important to consider the efficiency (see below) of the engineers and working relationship while assessing the overall cost benefit. Personally, I go to India now for the intellectual capital as a primary benefit instead of cost. Recently, a number of companies I’m involved with have had good success, from a cost benefit perspective, outsourcing to other countries such as China, Vietnam, Latvia and the Phillipines.
Intellectual Capital (Today = 5; 5 Years Ago = 3):
Intellectual capital is my primary driver for outsourcing to India. I have been able to find extremely talented engineers in India. They tend to be much more disciplined and have developed a deeper expertise than many of the engineers here in the U.S. This is probably due to their extreme focus on education and the lure and competition of their quickly growing tech economy. If you want architecture done right and well documented code, or if you need to build something that is high capacity and highly scalable, India is an excellent place to go. However, this discipline and process comes at the cost of efficiency and speed.
Efficiency / Speed (Today = 3; 5 Years Ago = 2):
When I first started outsourcing, it was pretty inefficient. There were challenges with time zone differences, communication, language/translation, working styles, etc. This resulted in more hours being spent (overall) to get a job done. I’m not sure that there were any real cost savings given these inefficiencies. Today, things have improved considerably. We still have a time zone issue, but as quality increases this becomes less of a speed bump. Also, communication is much better (including the quality of telephone connections between the U.S. and India) and the working styles and language/translation gap has become much smaller. It seems that Indians know just as much about American culture now and news as we do (I’m embarrassed to say that sometimes they know more about what’s happening in the U.S. than I do!) All of this has made communication much more seamless; resulting in greater efficiencies. One resource sitting next to you in your office is still more efficient than one resource in India (communication being the primary factor); however, comparing that at a group level, you can gain greater efficiencies in India by having a 24 hour development cycle and greater flexibility for expansion.
Flexibility (Today = 4; 5 Years Ago = 2):
Another major advantage for outsourcing is the ability to grow your team quickly. Engineers overseas are easier to find than engineers in the U.S. In India, these days, they have training down to a science and they are producing engineers faster and more efficiently than we are here in the U.S. It’s almost like an assembly line for engineers. I’ve been able to quickly expand teams (permanently or temporarily) as needed and that can be a real advantage to a fast growing company. However, this “assembly line” can definitely have its disadvantages when it comes to quality.
Quality (Today = 4; 5 Years Ago = 2):
One of the most important things to pay attention to is the quality and experience of the engineers when outsourcing. It is important to consider their education and training and whether or not they’ve had real world work experience. A lot of outsourced firms are pulling people fresh out of training and putting them on new projects. The larger outsourced firms have a management and mentoring structure in place to make this more efficient and control quality; but that definitely comes at the cost of efficiency. Don’t let your project (and money) be the training ground for new engineers.
Security (Today = 5; 5 Years Ago = 2):
Security (of your ideas/code) used to be a big concern when outsourcing. In India, if you go with some of the more established firms, this threat is no worse than it is here in the U.S. As technology continues to fuel the growth of India’s economy, everyone has become very sensitive to this issue. They realize that stealing code and ideas could severely hurt their growth. When I first started outsourcing, there was an instance where we found that our ideas and code were being reused and promoted outside of our project (as a separate product at the outsourcing firm). It was alarming and made us really think about security as an important issue. Fortunately, that was the first and only instance I have ever encountered related to security threats. Having said that, this is definitely something to be cautious about when outsourcing to other countries whose economies are not so dependent on outsourcing as a source of income.
Creativity (Today = 3; 5 Years Ago = 1):
As I mentioned before, India provides an enormous amount of intellectual capital, however, where they excel in expertise, often times they may lack in creativity. Engineers in the U.S. seem to have an easier time expressing “vision”, whereas engineers overseas have an easier time expressing “architecture”. I believe in setting the vision, product definition and the architecture of the “user experience” with resources here in the U.S. and leaving the architecture of the code and platform to India. I have seen the creativity level increase quite a bit over the years in India, as they are exposed to more projects and as entrepreneurship grows. However, as a whole, the creativity level in India still has a way to go.
Loyalty (Today = 2; 5 Years Ago = 4):
Loyalty used to be a strength for outsourcing. It used to be pretty easy to keep engineers involved and engaged on a project long-term. Now, there is so much competition that it is very, very difficult to keep people. Engineers want to advance their careers by moving up within an organization (so they want to move from coding to architecture to management, etc. quickly) and they want to increase their earning potential. As a result, there is often a lot of churn and sometimes even a lot of “bait and switch”. When considering outsourcing, find out how long they typically keep an engineer working on one project. Churn will cost you time and money in training and ramp of new project team members.
Management Tip:
This tip is mainly for startup companies. Startup companies have less discipline, consistency, process and need to move much faster than larger companies. Outsourcing is optimized for larger companies, due to the management styles/processes of many outsourcing firms. Having said that, there are ways to optimize it for startup companies. The best way, in my opinion, is to manage your engineers directly. Outsourcing companies will try to put in project managers to “make things more efficient”, “maintain quality” and “manage goals”. They are valuable to the team, but I find it best to have a direct relationship with each and every engineer on your project. Manage them directly, communicate with them directly and make it as much of a fluid process as possible (this will also help with loyalty, too). Use the project manager to enforce the goals, but don’t let them be the only point of contact between you and your engineering team.
I still remain a very big fan of outsourcing, if done right…
By Frank Addante
(Part 4 of a 5 part series: "So, you need to develop a product?")
Any entrepreneur, CEO or CTO should always have a development SWAT team on hand. This team should be outside of the core development team and outside of the company's critical path. This team can be made up of employees, a virtual group of employees (borrowed from their core team/job) or an outside development shop. It doesn't matter as long as they are super "scrappy" (see Scrappy versus Steady), have great vision, move extremely fast and require little direction or management.
I have had to call on my SWAT teams many times in the past. Sometimes in emergency situations, and other times to take advantage of market opportunities that quickly arise. Sometimes I have had to trash what they produced, other times it became a major turning point in a company's growth.
At L90 (Startup 3.0), we were sued by DoubleClick on the eve of our IPO for alleged patent-infrindgement. They tried to sue us in Virginia. We were scheduled to launch a new data center (of over 300+ servers) in Virginia the following week. With hundreds of millions of dollars in shareholder value at stake, I had to call on my SWAT team to do two things. First, they needed to reroute millions of dollars in computing equipment from Virginia to Texas and setup a new datacenter in less than 2 weeks. And second, they needed to architect and deploy an alternative to our core ad-serving software (which was delivering billions of ads for the Internet's top web sites at the time), because DoubleClick was trying to get an injunction to shut us down. The SWAT team was able to pull-off both of these seemlingly-impossible objectives within weeks and it gave us a lot of leverage in settling the bogus lawsuit in our favor.
At StrongMail (Startup 5.0), in the beginning, our biggest selling challenge was that it was difficult for us to visually demonstrate the value of our infrastructure solution. We had developed the world's best engine, but it didn't have a steering wheel (our strategy was to rely on other companies' steering wheels). Our internal development team was busy focused on developing our core product, but I needed to develop an application with an attractive, easy to use web user interface. I called on one of my outside SWAT teams and within months they were able to create an application on top of the StrongMail infrastructure that made it easy to demonstrate the value of the core infrastructure and it made the selling process magnitudes easier. It turned out to be a catapult for the company, and sales have been booming since then. The application is now being used by some of the world's most successful companies. After the initial product was developed, it was folded back into our internal engineering team and became part of our core product offering.
Without having a SWAT team on hand, it could have taken 10X as long to build a team, product specs, an architecture and a roadmap. The SWAT team helped us kick-start the project and get it to market in less time that it would have taken us to interview and hire a small team.
A solid SWAT team is invaluable, and to me, it is essential.
Next... Outsourcing (Part 5 of a 5 part series: "So, you need to develop a product?")
By Frank Addante
(Part 3 of a 5 part series: "So, you need to develop a product?")
Good engineers are hard to find. In today's highly competitive job marketplace, it is becoming increasingly more difficult. My solution: cast a wider net. Focus on the best talent, regardless of their location.
I've built development teams in Chicago, Los Angeles, Silicon Valley and India. I've also hired engineers scattered in random locations around the world. I've built companies and teams where 100% of the development team was located at the company headquarters and other companies where none of the developers were at headquarters. I've realized that it doesn't really matter where they are, if they are the right people. There are many pros and cons to having your engineering team outside of the company headquarters (and/or in multiple locations), but I think the pros end up balancing out the cons. The main benefit to having your engineering team all in one place, at the company headquarters, is certainly communication. The con is that the developers can become 'tainted' or distracted by all the other business happenings and it can skew their thinking and creativity.
There are also geographical workforce talent pool advantages and disadvantages. Chicago was the easiest place to find engineers; they were cost efficient, hard working and very loyal. Los Angeles was a bit more difficult to find engineers; they were the most creative but more expensive than Chicago. Silicon Valley has a lot of engineers with a lot of experience, but also lot of competition, which makes it the most expensive place to hire engineers and loyalty can be a challenge. I will talk more about outsourcing in point #5, but India has terrific intellectual capital, is less expensive (however, costs have been quickly rising), but, it is very difficult to find "Scrappy" engineers (see point #1) and communication can also be a challenge.
At StrongMail Systems (Startup 5.0), our first three developers were in India. It was a challenge in the beginning, but ultimately, I attribute much of our success to making the model work. We started with three extremely talented, creative and innovative engineers. They were able to attract other talented engineers in India as we grew. There were many communication challenges in the beginning, but once we overcame them, we were able to leverage a full 24 hour development cycle between the U.S. and India and, as a result, we were able to develop product much faster than the competition. At L90 (Startup 3.0), our engineering team was based primarily in Chicago while our headquarters was in Los Angeles. As we evolved our business plan and tweaked our marketing messaging, our engineering team was shielded from a lot of the distraction (being in a different location, they didn't get sucked into the "water cooler" conversation or hallway chatter) and they always remained 100% focused on building innovative products driven by customer need. Of all of my companies, communication was probably the strongest at L90, even though the engineering and design team were completely separated from sales, marketing, business development and customer service.
Focus on the best people, not the best location... By casting a wider net, you can find better talent, better manage your costs and gain many other tangible and intangible benefits (e.g. loyalty, development and support expanded across multiple time zones, multiple geographical talent pools for growth, new and fresh perspectives, etc.) Fortunately, we live in a world where virtual locations are not only possible, but advantageous.
Next... Build a SWAT team (Part 4 of a 5 part series: "So, you need to develop a product?")
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?")
By Frank Addante
I had written a posting on how to rapidly develop high quality products. As I was uploading it, I remembered that I had put together guidelines for our product development team at L90 (Startup 3.0). I dug up the document and re-read it.
I think our team at L90 was one of the most efficient and customer-focused development teams ever to be assembled. They accomplished a lot with a little. The team developed adMonitor(TM), one of the Internet's largest and most successful ad-serving networks at the time. adMonitor delivered over 8 Billion advertisements per month for over 3,000 customers with 99.9% reliability in less than 3 milliseconds per transaction and reached over 65% of the worldwide Internet population. All of this, with a development team of less than 30 engineers. Speed was their mindset.
So, given that, I decided to scrap the post that I was going to upload and, instead, publish this document exactly as I wrote it back in 1999:
12 Guidelines for Rapid Product Development
Make Speed Your Mindset
Always be focused on moving the product forward. It's easy to get caught up in the weeds. Software code, by its nature, is very much like weeds. Focus on the finish line and the next two steps at all times. Do a mini-release everyday, it will force you to develop something "useable" each day and you'll get to the finish line much faster.
Functionality First
The #1 objective should always be to develop the product in such a way that user-facing functionality is built first. Then proceed with building the backend to support the front-end functionality. This will allow you to solicit feedback and will make your backend development efforts much more efficient.
Avoid Over-Engineering
The #1 challenge that engineers face is their own natural sense of perfection. Over-engineering will slow down product releases.
Start from the Middle: Well-Balanced Engineering
Start from the middle of your product and build out from there, keeping the front-end and the back-end in balance at all times. For every back-end function developed, there should be a front-end function built before moving on to the next piece of back-end functionality in the system.
Reduce, Re-Use, Recycle
Create re-useable code and functionality, this will reduce the amount of engineering needed later – try to recycle existing code into new functions. Don't get in the habit of "re-writing" code (a natural tendency of engineers), it's dangerous.
Keep It Simple
Software is intended to simplify an end-user’s tasks by using technology to assist them. Every step of the way, you should remind yourself that end-user simplicity is the #1 goal of the project’s outcome.
Keep it Ready
Your application should be presentation ready at all times, this includes:
- Demo Applications
- Demo Data
- Test/QA Applications
- Test/QA Data
- Documentation
Solicit Feedback
Don't build technology in a bubble. Show it to people as often as possible throughout the developing process, get their feedback and adapt as necessary.
90% Baked Rule
Build 90% of the finished product – then let the customer define what the remaining 10%
should look like. This will accelerate the development process and set a development discipline to create products that are molded by the market.
Build for Tomorrow, Engineer for Today
Always keep the immediate needs in mind and engineer to meet those needs as quickly
as possible. Keep in mind that technology can and will change later. Your product requirements will change and new (faster, better, richer, cheaper) software and hardware development infrastructure technologies are being created every day.
Leverage Hardware
Don't get too hung up on performance. Hardware is less expensive than people. People get more expensive while hardware becomes cheaper and faster every day. Good people are hard to find, good hardware is a commodity. Leverage hardware whenever possible to scale the performance of your application and don't spend too much time "fine-tuning" code, at some point it becomes diminishing returns.
Consistency
As the company grows and products grow, the engineering team and objectives become
much more complex. It is important to maintain consistency in development, speed and administration to efficiently grow the company and the products. Get in the habit of developing quickly, but maintaining a high level of quality. Go fast, but don't hurry.
By Frank Addante
Often times, companies get distracted by all the things that they -could- do, and don't focus enough on what they do best. This is especially true, and very tempting, for startup companies who can seemingly do "anything" because they are so flexible and agile. This is dangerous behavior. It results in a lack of focus and diluted brand equity.
You want to pick the #1 problem that you solve and be the absolute best at solving it. This way, when someone says "I have X problem" the default company everyone thinks of is yours.
Here are some examples:
"I have a database problem" = go to Oracle
"I have a networking problem" = go to Cisco
"I need to sell something on the Internet" = go to eBay
"My cell phone is dropping calls" = go to Verizon
"I need a portable music device" = iPod
"I need a photocopier" = Xerox (this worked for them years ago, then they started to dilute their core message and competitors quickly stepped in with a vengeance)
Sure, all of these companies do a lot of other things... But, each have positioned themselves as the "default" or "defacto" standard for solving a problem.
With startups, it is difficult to commit to just one thing that you are best at because:
a) You don't know if that one thing is always the right thing
b) You aren't confident that you truly are "best" at solving it yet
c) You try to cast a wide net so you don't miss out on any opportunities
Bottom line is that you have to do it. Pick something, stick to it and be best. Period.
My first company, Starting Point (Startup 1.0), was an Internet search engine and directory. We were simply the best metasearch engine on the Internet. When people wanted to "search the search engines", we were the place to come. At the time, finding stuff using search engines was difficult. You had to go to multiple sources before finding the results you were looking for. (It seems as though this trend is starting to repeat itself with today's search engine results). Starting Point was best at searching the search engines and, as a result, we quickly became the 7th most popular site on the Internet.
L90 (Startup 3.0), my third company, was the "premium advertising network". When companies wanted first class advertising placement and high-end marketing technology, we were the place to come. Sure, we lost out on some of the low end business, but in the end, that actually helped the business survive the dot-com bubble burst.
At Zondigo (Startup 4.0), my fourth company, we never really answered the question "what do we do best?". So, what we became best at was changing our business plan. As a result, we ended up doing a lot of one-off custom work for clients and never really gained traction in any particular area. The company eventually failed.
At my current company, StrongMail (Startup 5.0), we struggled with trying to stick to only one core message. We can solve so many different problems with email delivery ranging from performance to reliable email delivery to dynamic content. As a result, we weren't the default answer for companies when they said "we have X problem". So, we put a stake in the ground. We focused on proving that StrongMail is the best way to get email reliably delivered to the Inbox. We went out with the message that we are like "FedEx for email delivery" and now, when people have email delivery problems, we are their first call.
It takes confidence and discipline, but it is very important to be best at something. It will help your company stay focused, it will build confidence in your entire organization (especially your sales/marketing team) and most importantly, your customers/users will think to go to you first.
By Frank Addante
"Inventing things is a two-stage process. Stage one: Everyone says it's impossible. Stage two: They say the solution was obvious all along." -- Robert Fischell, Inventor (Holder of 200 medical device patents)
It is easy to come up with ideas. Convincing others to believe in your idea is hard.
I've found that a lot of people are interested in hearing about new ideas... they listen, they smile and nod, they say nice things and tell you it's a great idea. However, when you ask them to buy it or invest in it, the music stops and the number of interested parties decreases dramatically, fast.
Two things I have learned:
1. There are a lot of people out there that are happy to waste your time
2. New ideas that are obvious to you are not obvious to others
It makes sense. If it was obvious and easy, then everyone would be doing it.
My first company, Starting Point (Startup 1.0), was an Internet search engine. I spent a lot of time and energy trying to convince people (advertisers, prospective employees, investors, potential acquirers) that there was a market for search engines. Of course, a lot of that time was spent convincing people that the Internet was going to grow, and therefore there was going to be a need to make it easy for people to find content and sites on the Internet. Fortunately for me, I don't think I was the only one evangelizing the part of the story about the Internet growing. There were those who said the Internet wouldn't grow, others who said that there was no way to make money on the Internet, some who said it would be too expensive for the computer hardware and bandwidth required to operate such a site and others who said I was too young and inexperienced to make it work. Even as Starting Point grew to be the 7th most popular site on the Internet (passing up Microsoft at #8), there were still a large number of skeptics. I was 19 years old, full of blind-faith and was unphased by the naysayers. Today, I don't think I need to convince anyone that the search engine seems like an obvious idea. However, if I said that today's search engine is obsolete, I'm sure many would tell me that's impossible.
Even with my current company, StrongMail Systems (Startup 5.0), an email infrastructure company, there were a number of skeptics. You would think that the importance of email would be obvious to everyone. Not the case. I've had MANY people tell me that there are no improvements needed in email, others have told me that there isn't a big enough market for email technology, some have said that we wouldn't be able to displace the 20+ year-old freeware architectures that exist in over 90% of the world and I've even had some people tell me that email is going to go away. Personally, I thought that this was one of my more obvious ideas. Email is ubiquitous, email is ridden with spam, 25% of legitimate email goes undelivered (e-statements, e-commerce transactions, customer service emails, legitimate marketing e-mail), email usage is growing 30%+ per year and the world has been going paperless. It boggled my mind that it wasn't obvious to everyone that had an e-mail address that this is an enormous market.
At the end of the day, I think most people are momentum-driven. Once they saw us gaining traction, signing big Fortune 500 customers, signing smaller startup customers and providing technology to other e-mail companies (that many thought would be competitors), many of the naysayers jumped on the bandwagon... I can't tell you how many of the former skeptics call me saying "I knew that StrongMail would be successful." Now, lucky for us, it's becoming obvious.
No matter how obvious your idea may be to you, it will be obviously impossible to many others. So, if you've got an idea, whether it be for a new product or service, a new marketing message or new company -- be sure to invest in a good helmet and a rubber rejection suit...
By Frank Addante
The Kool-Aid Test:
1. Why do I need anything?
2. Why do I need yours?
3. Why do I need it now?
Put yourself in the shoes of your customers or users. If you cannot come up with very compelling answers to all three of these questions, you likely do not have a viable business. Answering only one or two of these questions won’t work. The more compelling the answer and wide-reaching the audience, the more successful your business will be.
Examples:B2C Example (for an eBay user):
1. Why do I need anything?
> I need to turn my junk into money.
2. Why do I need yours?
> eBay has the most reach.
3. Why do I need it now?
> I need to pay the rent.
B2B Example (for a StrongMail user):
1. Why do I need anything?
> I need to send marketing, e-commerce or e-statements emails to my customers to drive revenue or reduce costs.
2. Why do I need yours?
> StrongMail is proven to be the fastest, easiest and most reliable solution for email delivery. The world’s most demanding enterprises, such as Ticketmaster, Fox Sports/MSN, Intuit and Williams-Sonoma turn to StrongMail for their critical customer communications.
3. Why do I need it now?
> On average, 25% of legitimate business email goes undelivered and every day that I don’t fix it, I’m likely losing money or revenue potential.
Most companies can answer #2
(Why do I need yours?) because they are so focused on being better than their competition.
Some companies are good at answering #1
(Why do I need anything?) if they started a business that was driven by market demand (as opposed to new/cool technology).
Few companies are good at answering #3
(Why do I need it now?) - what is the compelling event that will cause people to use it
today?
For me, this test also serves as a strategic guideline for almost everything I do:
- business plans
- investor pitches
- sales pitches
- marketing messaging
- product management
- press/media calls
- etc.
Try it! Take your last business plan, the marketing/messaging on your website or sales PowerPoint deck and see if you have
clearly provided answers to these three questions. If not, go back and update it – I bet you will find it to be much more effective!
By Frank Addante
- Background – The S:C (Simplicity to Complexity) Ratio
- 80/20 Rule for Products
- Less is More; More is Difficult
- Don't Think Too Much. Stop Chain-Thinking!
Background – S:C (Simplicity to Complexity) Ratio
Complexity drives me crazy. My philosophy has always been to move as quickly as possible and the only way to do that is to practice the art of keeping things simple.
I have found that if an idea is incredibly complex, it inherently requires more time to develop and is harder to explain to customers, users, partners, employees, etc. And if customers, users, partners and employees have a hard time understanding or explaining the idea, then it will eventually fail. So, don’t kill your idea with complexity.
This “keep it simple” discipline was easy to practice when I was younger. Because I was not tainted by previous experience, everything naturally started out simple. For example, Starting Point’s (Startup 1.0) user interface was very similar to Google’s user interface in the sense that it was a very simple, plain web page that had one search box and a button to search.
As I grow older, I find that it is more difficult to adhere to this discipline. The more I learn, the more I feel compelled to apply ALL of my learning to new projects. Whether it be product development, marketing, sales, negotiating or raising capital, I find myself trying harder to not get bogged down with unnecessary details. Instead, I try to forget everything I know, wipe the slate clean and take a fresh, clear approach to improving the S:C ratio (Simplicity to Complexity). Finding simple solutions for solving complex problems is increasingly more difficult as the complexity increases, but if you achieve a high S:C ratio, it will be exponentially rewarding.
"80/20 Rule for Products"
I believe that 80% of the market will only learn, understand and adopt 20% of the features and functionality in your offering. The remaining 80% of the functionality will address very specific needs for the remaining 20% of the market.
For example, how much of the total functionality of Microsoft Office do you know how to use? What about your friends? Your kids? Your parents?
In general, startup companies that are in emerging markets should be focused on the former -- and should worry about the advanced parts of their offering later, when the market matures. At L90 (Startup 3.0), we developed an online advertising product (called adMonitor) that delivered emails and digital advertisements for blue-chip customers such as Microsoft, Visa and AT&T. We developed the product, took it to market and acquired 3,000+ customers in less than 3 years. While our competitors had hundreds of engineers focused on developing more complex bells and whistles, we had a fast-moving, killer team of 12 engineers focused on simplifying our product. We were successful because our product had, by far, the highest S:C ratio. It was quick and easy to set up, had an extremely simple-looking user interface and was very easy to use. Our “keep it simple” strategy enabled us to move faster than our competition, and more importantly, enabled our customers to move faster than their competition.
"Less is More; More is Difficult"
Think about successful products and services such as the iPod, eBay or Google. Their strategy was to provide very minimalist, easy to use products and services. Many of their competitors tried to beat them by developing more feature-rich offerings. Apple, eBay and Google focused on perfecting the core functionality that 80% of the market experiences during every use, while their competitors simply confused their users with more clutter. More complex clutter can also be thought of as "more rope to hang yourself with."
At StrongMail (my current company, Startup 5.0), using those same principles, we recently launched a product called Message Studio which takes very manual, complex email integrations and workflows and simplifies them with an easy, point and click graphical user interface. The first thing people say when they see it is “wow, that looks so easy.” The reason being is because we took user interface styles that people are generally familiar with already (concepts similar to Microsoft or Apple products) and applied them to what used to be very complex email workflows. As a result, this kind of customer reaction has stimulated rapid growth for our company.
In today’s complex world of technology and buzzwords, simplicity puts the user's mind at ease, gives it a rest and makes them feel refreshed.
"Don't Think Too Much. Stop Chain-Thinking!"
Spending too much time over-thinking things will lead to complication. People often spend too much time on the methods and lose site of the results. If you find yourself saying things like "and, we can also..." or "but, what if..." -- these are common phrases involved in what I call "chain-thinking" -- just stop!
I found the perfect video illustration of what I am talking about. It is a video spoof on what the iPod packaging would look like if Microsoft designed it.
CLICK HERE TO WATCH THE VIDEO
(The video is less than 3 minutes long, I definitely encourage you to watch it.)
Get your offering in your customers' and users' hands as quickly as possible.
Try this:
1. Listen to yourself explain your offering to your user (pay attention to how you describe it – does it sound simple to you?)
2. Watch them use it (do they struggle without your help?)
3. When finished, ask them to explain it to you (does it sound simple when they describe it?)
In general, make sure that your offering is:
- Simple to Understand:
If they can’t understand it, they won’t use or buy it.
- Simple to Use:
The quicker they figure out how to use it, the quicker they'll buy it and the quicker they'll be able to show it to others.
- Simple to Promote:
It needs to be easy for other people to explain. You need other people talking about your offering to generate buzz, awareness and scale.
- Simple Looking:
Perception is everything -- if it looks easy, then it is. The marketing and the product itself should look simple. You should make it easy for your customers to buy (i.e. no complex contracts or pricing schemes) or adopt (i.e. no complex sign-up processes.)
For more information on this topic, a friend and colleague of mine, Peter Sealey, wrote a book called "Simplicity Marketing." Peter is an adjunct-professor at Berkeley and Stanford, was the former Chief Marketing Officer of Coca-Cola, President of Columbia Pictures and has been either on the board or has served as an advisor to my past three companies. Peter and I share very similar philosophies on "simplicity" and I believe that his book says it well.
“Keep it Simple” has been my #1 golden rule. I believe it has been the single greatest contributor to the success of all of my companies and their respective products. My next posting will be about the second greatest contributor: “The Kool-Aid Test.”
Next on Deck: The Kool-Aid Test: “Why do I need anything? Why do I need yours? Why do I need it now?”
By Frank Addante
[Startup 4.0] Zondigo, Inc. – Wireless and Voice Application Development Software Company
Age: 24 - 25
Time Period: 2000 - 2001
My Role: CEO and Founder
High Point: Partnering with Intel and having Craig Barrett (Intel CEO) present Zondigo’s technology as “the future”
Wireless was going to be the "next big thing." I left my CTO position at L90 (Startup 3.0) to start a company called Zondigo (genesis of name: "its-on-the-go"), a wireless and voice technology company. We developed software to enable developers to quickly and easily create and deploy wireless and voice business applications.
So, I did what any other opportunistic entrepreneur does when they want to quickly build a company to capitalize on an opportunity. I immediately raised some venture capital and then recruited the most experienced team I could find. The individuals we recruited had very impressive backgrounds. However, they did not function well together as a “team.” I missed, perhaps, the single most important company building fundamental – I had failed to consider the dynamics of how everyone would work together. Nonetheless, though it was a bit of a struggle, the individuals eventually learned to work together as a team. We accomplished great things – we signed Intel as a customer and partner, developed a very strong product and generated a fair amount of awareness. But, there was always something “missing” in the teamwork category that prevented us from going full throttle.
Zondigo was the perfect example of why all good companies must be “right idea” AND “right time.” We missed out on the “right time” part. The company was about 5 years ahead of its time (starting this company today would be the right timing). Zondigo was creating the types of innovative wireless applications that you are seeing in use today. We were creating applications similar to the wireless phone/texting voting system used by American Idol or the rewards program that Coca-Cola recently launched (MyCokeRewards.com). As a matter of fact, we even pitched the idea to Coke about 5 years ago.
Again, like most opportunistic entrepreneurs, part of our growth plan was to raise venture capital. As CEO, I spent 6 months on the road, full-time, trying to raise our Series B funding. This was in 2001 when the market was tanking and all VCs were gun-shy. All of a sudden, wireless went from being the “next big thing” to being the last thing on people’s minds. As a result, like many entrepreneurs, we changed our business plan about 10 times to “fit” what the VCs were looking for so that we could fund the company and survive. Big mistake. Finally, we convinced a firm to invest.
After a small celebration, a few days later, I realized that two very bad things happened while I was out raising capital: a) the market opportunity disappeared and b) we had mangled our business plan so much that the plan no longer made any sense. But, the VCs liked it! So, for the first time at this company, I acted unlike other opportunistic entrepreneurs and I made a very unpopular decision – GIVE THE MONEY BACK!
So, we did just that. A couple of months later, we sold the technology and the rest was history.
An entrepreneur’s most valuable asset is time. You can always raise money, build things and find people – but you can never raise more time. Therefore, for true entrepreneurs, it is not about ROI, it is all about ROT (Return on Time).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SNAPSHOT:
Venture Capital Funding: $1.25M
Exit: Technology acquired
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LESSON(S) LEARNED:
Teamwork is critical: A startup company, like a baby, is fragile and impressionable. It is important to bring in the right people at the right stages. Personally, in the very beginning stages of a company, I think it is important to find young-thinking, hungry, passionate, quick learners who are willing to make mistakes, work as a team and constantly learn and adapt. I’ve learned to put experience far behind the rest of these traits.
Believe in YOUR business plan: If VCs (or anyone else, for that matter) had all the right answers, they would be starting their own companies – they’d certainly make more money that way. At the end of the day, right or wrong, you need to believe in your business plan and execute it to its fullest potential.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BIGGEST…
…reason for success: We did not let emotions cloud “market judgment.”
…mistake: Raising capital too early.
…challenge: Getting a bunch of smart, experienced individuals to learn to work together as a team.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IF I WERE…
…smarter: I would have been more careful about how I built the team and adapted the business plan.
…dumber: Instead of giving the money back and moving on, I would have wasted a bunch of money and time.
…to do it all over again: I would have secured a customer first and validated the market timing before rushing to build a company.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Next on deck: Startup 5.0… ”I’m just going to chill out for a bit… (OK, for a month…)”
