July 1, 2003
This software developer defied conventional wisdom
on the way to 1,888% growth; here's how
by Bruce Hadley, SoftwareCEO
Beverly, Mass.-based Teamstudio,
a developer of software engineering tools, is #91 on the current
Inc. 500 list
of fastest-growing U.S. companies, with 1,888% revenue growth from
1997 to 2001.
And, Teamstudio's real numbers are bigger than those reported to
Inc., because Inc. only considers U.S. revenues. The Inc. list shows
2001 revenues of $6.6 million, with 40 employees; the global total
was $8.2 million and 50 people.
Revenues for 2002 climbed 23% over the previous year, to $10.1
million, with a total headcount of 65 people; that works out to
revenue per employee of $154,692.
Teamstudio was founded in 1995 by current CEO Nigel Cheshire and
CTO Mark Dixon. We recently caught up with Cheshire to get his advice
for growth-oriented software company execs who'd like to mimic Teamstudio's
phenomenal growth.
It was a refreshing and revealing conversation, because Cheshire
immediately zeroed in, with entrepreneurial zeal, on all the "rules"
Teamstudio has broken since inception. Cheshire wasn't trying to
be defiant for the sake of rebelliousness, but he's certainly —
and justifiably — proud of what his group has accomplished.
The list of seven "broken rules" that Cheshire offers
serve as a reminder that in the software business, CEOs should never
be afraid to test their own limits and question conventional wisdom.
We call them rules rather than myths, because Cheshire says that
in each case, he got so-called expert advice that Teamstudio's chosen
path wouldn't work. So, that's how we've listed them: statements
that Teamstudio proved false.
Broken rule #1: Trying to sell over the phone to software developers
won't work.
"It's been extremely successful for us," Cheshire
says. "Contrary to what you might believe, developers do like
to talk to you if you have something interesting to hear."
Teamstudio software ranges in price from $300 per seat to $4,000
per seat. The company sells to other developers — people who
are building business applications for Lotus Notes and Domino, as
well as people who are building on any kind of Java platform.
Broken rule #2: To sell technical products, you need technical
sales reps.
"We use sales people who come from a non technical background,
and it has been a successful model for us," Cheshire says.
Teamstudio has eight sales reps in the U.S., eight in the U.K.,
and five in Japan. All are telesales people who very rarely make
house calls, Cheshire says. Reps are paid half base, half commission;
the average ones earn $80,000 to $100,000, but a top rep will make
$150,000 to $200,000 in a good year.
It's interesting to note that Teamstudio has recently shifted its
emphasis on lead generation from trade shows to the Web. "Leads
came through the trade shows in the past, but that has dropped off
recently," Cheshire says. "Increasingly, we find people
through Google
AdWords — that has been very successful for us."
Currently, 10% to 15% of Teamstudio's leads come from Google, the
balance from trade shows and referrals. "We still do 12 shows
a year," Cheshire says. "The range is from 500 to 17,000
attendees. Even though there might only be 500 people at a particular
show, the niche nature of the show means that the leads will be
very high quality."
Teamstudio's marketing director uses the show circuit to fine-tune
the company's Web-based efforts. "We talk to developers at
the trade shows, asking them what they're searching on," Cheshire
says. "The beautiful thing about AdWords is that if people
don't click, you don't get charged.
Teamstudio also undertook a search engine optimization (SEO) initiative
in the past year. Cheshire says the company hired an outside consultant
for around $6,000 for the initial implementation, then brought the
SEO effort in-house to Teamstudio's marketing department.
Broken rule #3: Put your full weight behind your initial product
launch.
Au contraire, Cheshire says: "You should anticipate that
the first product you launch will fail, and treat it as a marketing
intelligence-gathering exercise.
"When we first entered the Lotus Notes market, our product
was an end-all — it was a complete replacement for the Notes
IDE, and as long as you were willing to do your job, it delivered
an astronomical ROI.
"Touting this around to various trade shows, you could hear
the gasps as we were doing the demo — it was a phenomenally
sexy demo. People were simply blown away. They were ecstatic.
"We had one customer, a development manager, who ran off the
show floor saying that he was going to call his HQ so that he could
immediately halt all development and start using our product.
"But the response he got from his actual developers —
the software engineers who would implement it — was, 'We'll
install this over our cold dead bodies.'
"Buyers were too focused on meeting their next deadline to
change their usual way of doing things. We found that we'd sell
at most one copy, and that was it."
So, what happened to Teamstudio's first product? "We dumped
it," Cheshire says. "We buried it. We extracted some of
the better bits and made them individual, much smaller products."
That original product generated about $500,000 in revenue at $1,000
a pop, Cheshire says; the follow-on products generated much more.
In Cheshire's mind, the benefit of the experience was to underline
maxim of the software business: "When we launch a new product,
we take it as a very good sign that people buy one license and then
come back to buy several more," he says. "The key early
warning sign here was that people were buying one license and never
coming back to buy more."
Plus, it's changed his notions about market research: "The
experience with our first product put a big dent in my faith in
any kind of market research as opposed to just putting it out there
in the market," he says.
Which segues into the next rule.
Broken rule #4: To ensure buy-in, sell high in the organization.
Teamstudio take an opposite tack. "What's been successful
for us is building products that the end-users like," Cheshire
says.
"The secret is getting the end-user hot and bothered before
you take it up the foodchain." Two good examples of the opposite
ends of this strategy, Cheshire says, are Banyan and Novell:
Banyan went high in the food chain, while Novell products became
standards through pervasive use at the bottom. "It's almost
a viral thing," he says. "We're selling directly to the
end-users."
This doesn't mean that Teamstudio will turn up its corporate nose
at big opportunities; the firm sold an enterprise global license
to IBM — worth $1.5 million in 1998. But, Cheshire argues,
even that came through the same loop: "We were selling so much
product to individual IBM developers who were buying them at full
list price on their credit cards, we got a call from corporate looking
for a better deal."
Negotiation side note: How do you set a price for a global license
to IBM? "We made an estimate of how many developers they had
and multiplied that times our list price," Cheshire says. "Their
starting point was about one-tenth of ours. We went back and forth
and ended up somewhere between the two numbers."
Cheshire wouldn't tell us how much he gave up to IBM, but it sounds
like the deal made sense for the time and place. Remember, Teamstudio's
total sales in 1997 were $332,000. Even though we think that small
ISVs are too easily bullied by big buyers, it's hard to find fault
with a single deal that was worth five times the previous year's
sales.
Broken rule #5: Small ISVs can't build an international business.
"People thought I was completely out of my tree to go into
Japan as a sub-$10 million business," Cheshire says. "But
actually, it's not as bad as you think it is if you've got the right
people.
"I was lucky in that I had a sales manager who always hankered
after moving to Japan for a couple of years. He was already ensconced
in the whole philosophy of Teamstudio, he had been here a couple
of years, and was an enterprising kind of individual."
"We first built a Japanese localized version. To do that,
we hired a Japanese national, a developer who happened to be living
here in Beverly. We sold the Japanese version from our U.K. office,
because we hired a Japanese national, a woman who happened to be
living in the U.K. at that time, and didn't mind coming in at God
knows what time — 3 in the morning or something."
Are you picking up a theme here? Teamstudio first prepared their
product, then prepared their company with the right people —
they didn't go out and jump on the first reseller who gave them
a nod and wink.
"If you look hard enough, you can find these people,"
Cheshire says. "The reseller option didn't sound too appealing
to me; I didn't like the idea of flying into Narita and doing a
deal on Tuesday, shaking hands, then leaving on Wednesday.
Every country has its own issues of course, but Cheshire knew from
initial customer contact in Japan that Teamstudio needed a local
office to succeed there. "The response we got was very direct,"
he says. "We would never buy a product from a company that
doesn't have a local office.'"
Teamstudio continued selling to Japan from the U.K. for about six
months, after which the U.K. sales manager and the Japanese woman
they'd hired in the U.K. both moved to Japan to open the Teamstudio
office there in 2000.
"That first year of operation cost us about $400,000,"
Cheshire says. "Localization would add about another $100,000
to the initial expense. In the second year we broke even, and in
year three made profit of $300,000."
Broken rule #6: To build competitive software, you need to build
a big R&D group.
Nonsense, Cheshire says: "I believe strongly in keeping
the development team very small. I think there's a real law of diminishing
returns as your development team gets larger, and it's much steeper
than people think.
"I used to work for Data General, on the software engineering
side; they used to fill these huge, huge development teams, where
the majority of people were doing coordination and communication
and project management, and a tiny handful were actually writing
code.
"At Teamstudio, we don't' have more than two people working
on one product at any one time, not including docs and QA. That
takes care of all the communication problems. We have two product
families — six products on the Notes side, one on the Java
side — and have just four developers, all of whom report to
the CTO."
Let's put some percentages on this: Teamstudio has 65 employees,
so a four-person development staff represents 6.2% of the total
headcount. Or, if we include the CTO, it's 7.7%. Either way, it's
an extraordinarily small number.
But wait, it gets better.
"Even though we have a pretty good range of products, and
we produce a new release every three months, we spend only 9% of
revenues on R&D," Cheshire says, "and that includes
the CTO and QA and docs."
Among public software companies, most spend 20% to 30% of revenues
on R&D. Microsoft
manages to get it down to 15%, but there are some that spend 50%,
60%, or more. 9% is unheard of.
And, lest you think that 9% buys a bunch of slackers: In the last
six months Teamstudio released three brand-new products in brand-new
markets.
First key: Protect your developers. "People can crank
a lot of code if they don't have to spend a lot of time talking
to each other," Cheshire says. "Each developer has their
own office with a big, heavy, thick door, and their offices are
always waaaay down the other end of the building from everyone else."
Second key: Educate your sales people. "We do a good
job of educating our marketing and sales people about the products,
so they don't have to bother the developers," Cheshire says
Third key: Pay for top talent. Teamstudio's developers are
all superb programmers, Cheshire says, and they're paid accordingly:
the annual compensation range is $85,000 to $130,000.
Fourth key: Get a blue-ribbon CTO. "A huge amount of
the credit goes to our CTO," Cheshire says. "He's very
particular about whom he hires. He needs to know that he can rely
on these people to work to the same standards that he does.
Fifth key: Don't let crap out the door. "I was poking fun
at Data General earlier, but one thing I will say about DG —
one of the things that struck me when I left — I was totally
floored, in fact — was the poor quality of software in the
PC world," Cheshire says.
"Yes, at DG we gouged people on price, but I'll tell you what:
Back in those days, if we found a bug, it was big deal. One key
to keeping R&D costs down is to invest your money in writing
bullet-proof code in the first place."
Broken rule #7: Build your product first, then find a channel.
Wrong, Cheshire says; you should build your product with the
channel in mind.
"We have this telesales team," Cheshire says. "Typically,
they do not come from a technical background. Curiously, we've found
that the more tech savvy they are, the worse they are as sales people,
because they get into all kinds of fascinating conversations, then
forget to sell anything at the end of the call.
"But the point as it relates to product development is this:
It has to be simple enough that you can explain it to an ex-car
salesman, and he can in turn explain the benefits in the first 30
seconds on the phone. If you don't get them in the first 30 seconds,
you're lost."
What your software does must be simple enough in concept that you
can explain it to someone else, over the phone, without the benefit
of a demo or brochure or video, Cheshire says. At Teamstudio, marketing
develops the pitches that the sales reps use. "They're not
scripts," he says, "but they do have bullet points that
the sales people know they need to cover off."
Teamstudio gave us a sample of one of these internal "talking
docs" — a single-sheet
overview that guides sales reps in their phone calls with prospects;
this one's for Teamstudio Analyzer for Java.
Here's one pothole in the fast lane that Teamstudio failed to
clear
Despite its incredible success with rule-breaking, Teamstudio
hasn't executed perfectly in its eight years in business, Cheshire
says. When we asked him about past mistakes, he named one of the
most common for fast-growth companies: hiring too many people too
soon.
"September and October 2001 were actually pretty good months
for us, which fueled our belief that we were okay," he says.
"It was in December 2001 and January and February of 2002 that
we realized we'd overextended ourselves. Had I known at the time
that our growth had slowed, I wouldn't have hired the people that
I hired."
But, rather than wallow in hindsight, Cheshire believes he's found
a fix that can benefit all software CEOs; he just wishes he'd found
it sooner.
"I wish that when I started out I had this simple technique
that I have now, called a trailing 12 graph," he says. "I
picked it up at The
Executive Committee (TEC) three or four months ago.
"It's a very simple concept: You graph out your sales month
by month, but each point of the graph includes all of the previous
12 months added up. So at any point, it's as if your year just ended.
It takes any kind of seasonality out of it. For example, you can't
say that April was a bad month, because every single point on the
graph has an April in it.
"What a simple month-to-month chart doesn't show is whether
the company is growing or shrinking. In July or August of 2001,
our growth curve actually started to flatten out, but it was not
apparent to us at the time. We assumed it was just another trend
we were bucking.
"With the benefit of hindsight, you can see this sort of thing
in a very clear way."
|
