IT Employment

Tech startup tips from Spiceworks' co-founder: Building the business, year one

Spiceworks' co-founder and CEO, Scott Abel, has been involved in six company launches. He shares his advice and experiences with TechRepublic contributor Justin James in this collaborative series, which examines the strategies that lead to startup success. Part three: How do you get down to business and get your business off the ground?

Editor's note: This is the final installment in a three-part series written by Spiceworks' CEO, Scott Abel, and TechRepublic contributor Justin James. Although this article is co-authored, "we" refers to Abel and his business partners, not Abel and James. This article is also available as a PDF download.

The first article in this series discussed how to begin the process of launching a tech company and how to determine which of your ideas are most likely to fly. It mapped out four steps for getting underway and discussed the "idea percolator," which is a way of analyzing the viability of a potential product or service. The previous article looked at how to put together a business plan that defines the way you'll build and market your product and how to raise the money you'll need to fund your new venture. In this installment, we'll roll up our sleeves and see what it takes to get the business off the ground.

Building the startup team

You've raised your money. It is time to get down to the business of building the business. Nothing gets built without people, and hiring your startup team is probably the most important thing you'll do. Of course the kind of people you need to hire depends on the business you're starting. Ours was a software business, so the bulk of our hiring was software developers. But these guidelines will apply to any business:

Hire the best people you can find. No matter what discipline you're hiring for, you should hire the absolute best person you can find. Now best doesn't mean most expensive or even the person with the most experience. Here, best means the person who will most complement the team, fill any holes in the team's expertise, and mesh well with your overall culture. We try to hire for "attitude and aptitude" over experience and expertise. That's not to say the latter isn't important; when we can get it, we take it. But we won't take it instead of the first two qualities. Over the years, I've found that there's no substitute for pure drive and a willingness to learn. I've seen more hurdles overcome by that than all the experience in the world.

Find "startup" individuals.The startup environment is exciting, challenging, demanding, chaotic, and ever-changing. In short, it's a blast if you're up for it. Many people are not. The concept of a startup looks romantic from the outside. But inside, it's a lot of hard work. Make sure that the people you hire are up for that. The hours can be long; 60 hours a week is not uncommon. Direction can change monthly, sometimes weekly. And everyone (including the CEO) wears lots of different hats. Translation: You might be asked to do everything from designing the architecture of a new system to getting a phone line installed. The people you hire have to want to work in this kind of environment. If they're coming from a big company and used to a clearly defined role, direction that changes yearly at most, and lots of support staff, it's just not going to work out. Your job is to weed those people out early.

Hire "product" people. Startups are about changing the world, or at least your small part of it. To do that, you need people who are passionate about what they're doing. You want them absolutely committed to the product they're building and selling. These product people have a sense of ownership about what they build, market, or sell. It's not enough for them to just be handed a spec and told, "Build this." They want to get inside the user's head, understand what makes them tick, and turn that into some improvement in the product. These are the people you want. They understand what it takes to ship software used by tens of thousands of people. They have the drive to build the absolute best product they can. You don't have to hire 100 percent product people, but you want a few. They can make or break your company.

Building the right product

The first year of your startup is uniquely challenging. If you're a software company, it's highly likely you're creating something that's never been done before. This is an exciting time, but it is a precarious one, too. You've got to be sure that the thing you're building addresses a real need in the market. The single most important thing you have to do in year one is build the product and validate that it's a product that people will actually use and pay for.

I know only one way to do that: Spend lots of time with your target customer/user. You've got to really understand their needs. The most common mistake I see is people guessing. They sit around their office and "imagine" what problems the customer has, and then they come up with a solution. Don't guess. Find out. Here's how.

Understand their real problems. Go visit them in person! Don't do it over the phone with surveys. Don't outsource it to some research firm. Do it yourself. After all, is there anything more important than getting the product you build right? How do you do this? Just ask. You'll be surprised how willing people are to help you if you just tell them the truth about what you're trying to do. When we started Spiceworks, we picked up the phone, called IT administrators in small businesses, and said, "We want to better understand what you do every day. We don't think the industry cares about your unique needs, and we want to help." Very few people will turn you down when you offer to help them.

Now that being said, when you go to see them, don't waste their time. You should have thought through carefully what you're trying to learn, what questions you'll ask, and so on. Most important, watch what they do versus what they say. They'll often say one thing and do another. For example, we found that when asked, "Is there any one place you go online for help?" they all answered "No." Yet when we sat in their office and watched them, the first thing they did when debugging some issue was pop over to Google.

Get feedback early and often.The second most common mistake is taking the initial research into a black hole and coming out with the 'perfect product" 12 months later. I can almost guarantee it will be wrong. Get your initial feedback, build a prototype, and get it back in front of the users fast, in 30 to 60 days. And then listen carefully! You'll be surprised at what they'll tell you. Some of the features you've come up with they'll love. Some they'll hate. The most important part of this process is the new features they suggest. Something about having real software in front of them frees their imagination. They'll suggest new functionality based on what they see in the current prototype. You take that, rev the software, and do the whole thing again. You'll quickly converge on a solution that truly solves a real problem, because the users designed it.

At Spiceworks, we took this one step further. We designed this kind of product feedback directly into the product itself. We added a "feature request" section to the product, where users can suggest a new feature or vote on features suggested by others. This way, our users can tell us what they want and how important it is. More than 75 percent of our new features get into the product this way.

Get customers early. Until somebody pays you money for your product, everything is hypothetical. It's one thing to "think" your software has real value and that it solves a real problem. It's another thing to 'know" it does. The only way you'll know for sure is to have people open their wallets and give you money. Whether your software costs $10 or $10,000, it's all the same. You won't know that you really have a valuable product until somebody pays for it. So get paying customers early. It doesn't even matter how much they pay, as long as it's in the ballpark of what you think you'll be charging. If your software will sell for $500, get somebody to pay $200 to $300. If it will sell for $100,000, get them to pay $20K to $30K. It's less about "how much?" and more about "will they?"

As with the functionality feedback, once you ask them for money, you'll get "value feedback." Is it worth what you're asking? Are there hidden costs, like the cost to install and set up the software? Do they need dedicated resources to support the software once installed? Do they feel these costs are in line with the value they get out of the software? These are all things you want to learn as early as possible. Maybe you can make some of these costs go away by redesigning the software. Maybe you need to provide services to help them deploy the software. But the sooner you know this, the better off you'll be.

Well that's it for year one! Come up with the idea, develop a pitch, secure some funding, hire the team, and build the first product. There's plenty to do that will keep you busy. Year two is even more exciting. You get to dial in the go-to-market model, the sales model, the marketing programs, etc. But we'll leave that discussion for another series.


Scott Abel has started three software companies over the past decade and previously worked for industry leaders such as Apple, NeXT, Motorola, and Apollo in sales and engineering. He is co-founder and CEO of Spiceworks, which developed the first free IT management software to help IT professionals in small and midsize businesses easily inventory and manage the software and hardware assets in their networks.

Justin James writes in TechRepublic's Programming and Development blog. He also contributes articles on a wide variety of topics, from graphics programming in .NET to building and configuring SOHO router/gateway appliances.


1 comments
JodyGilbert
JodyGilbert

Have you reached the point in your own business launch that involves making key hires and validating your product? Are you in touch with potential customers and getting the "functionality feedback" and "value feedback" described here?

Editor's Picks