The Single Founder Musings on software and startups from a single founder Fri, 23 Apr 2010 10:43:14 +0000 en hourly 1 miketaber 5 Lessons You Could Learn From (Good) Professional Consultants To Advance Your Career Fri, 23 Apr 2010 10:43:14 +0000 Mike Taber

The pitchA colleague referred to me as Mariano Rivera this week. If you’re not a baseball buff, Mariano Rivera is the closer for the New York Yankees. Like most closers in baseball, Rivera usually comes into the game when it’s almost over and the Yankees are winning by only a couple of runs. It’s his job to make sure the other team doesn’t score so the team holds on and wins the game. If he does it, he gets a “Save” in his statistics. If he doesn’t, he usually ends up with a loss. He’s widely regarded as one of the best closers in baseball.

As I thought about this comparison, I realized that while flattering, it wasn’t remotely true. The people I work with don’t send me in to close a deal. I’m not there to “seal the deal” because I’m not that kind of person.

I’m the guy they call when all hell has broken loose. I’m the guy they call when someone screwed up, someone else got pissed, and tens of thousands of dollars of products, services, and future productivity are on the line. I’m the firefighter.

This week, I felt the urge to change my business card to Winston Wolfe or at least put a quote from him on there. If you remember the movie Pulp Fiction, he’s the guy who shows up to clean up the body after John Travolta’s character accidentally shoots “Marvin” in the face. When he arrives he says:

“I’m Winston Wolfe. I solve problems.”

In a nutshell, that’s generally what I do. I solve problems. And when I’m sent in to rescue a dying project, I look like an All-Star for a couple of reasons.
1) I know how to manage a project and set expectations
2) I have a deep and diverse set of skills
3) The customer expectations are based on the guy who went in before me.

How many of these projects fail?
A study by Gartner suggested that as many as 75% of IT projects fail and an informal poll by CNet in 2008 suggested that 62% of IT projects fail. Neither specifically calls out consulting projects, but personal experience from cleaning up some of these messes seems to indicate that it’s at least 20%. In the past 30 days, I’ve saved two different projects from completely falling apart after the customer lost confidence in both the consultant and in the vendor.

There are varying degrees of failure, but when the customer asks for a consultant to be replaced before the project is over, that’s a pretty good sign that they failed. I came in after one consultant who claimed to know how to use a software package that he had merely installed and used once or twice. When he started working on the project, the customer asked a bunch of questions he didn’t know the answers to, so the consultant went to the product documentation. After four days of reading the documentation, he’d found the answers. But by that time, the customer lost all faith in his ability to deliver and threw the company out. I delivered on the next several weeks of services and heard the story mid-way through the project. I’d be pretty irritated too if I paid $12,000 for a consultant to read documentation for a week. I knew what the customer was thinking and he didn’t hesitate to offer it up. “Hell, I could have read the documentation myself.”

Yes, you read that right. The customer paid $12,000 for a week of consulting services. Some consulting companies charge exorbitant rates is because they guarantee their work. If a project fails, they’ll throw another consultant on it for no charge. Usually they come out a little ahead or a lot ahead.

The problem for the customer is that they waste valuable employee time with the consultant doing things that end up being thrown out anyway. Failed projects cost them even more money. So how do you go about making sure that a project succeeds?

The obvious answer is to use great consultants in the first place. But finding a great consultant is a lot like hiring great employees. The difference is that you have less data and interaction with the consultant to make a decision. More interaction isn’t necessarily going to help because a consultant is generally taken at his word that he knows what he’s doing. It’s simply not cost effective to give a battery of proficiency tests to a consultant who is only going to be there to do a short term project.

When you hire a consulting company to come in and do work for you, you’re relying on the professional services manager to provide you with someone who knows what he is doing. You can stress how important that is, but at the end of the day, the company you hire is going to give you whomever happens to be free at the time unless there’s a very specific skill set needed for the job that nobody else has.

Basically that means it’s a total crap shoot. You can easily get stuck with a consultant who just doesn’t know what he’s doing. Guess what though?

It’s almost never his fault!

I generally feel bad for these guys, because if you hire a company to come in and deliver consulting services and end up with a consultant who really shouldn’t be there, it’s not his fault. It’s his boss’ fault for putting him there. Consultants don’t get to choose what projects they work on. They go where they’re told. And if that means they are put on a project they have no business working on, then so be it. But he didn’t choose to be there. Someone else did. His choice was “Give it a try, or find a new job.” If it works out, then great. He’s got some new skills they can peddle to the next customer. If not, there’s usually enough profit margin built in for the vendor to replace him with someone else who is more qualified and still at least break even. In either case, it reflects poorly on the consultant, even though it’s not his fault.

What’s the formula for being a great consultant?
If you think that a great consultant is someone who knows their products cold, then you’d be wrong. A great consultant is many things, but mostly is someone who is a good teacher. Customers don’t want to have to hire you every time they need something. They want you to come in and teach them to be self sufficient. If you can’t do that, then you’ve failed to do your job. I worked with a guy about 10 years ago who was a brilliant programmer. He could write C code in his sleep and was very good at it. But his abilities, much like the dark side of the Force, made him arrogant. As if he could do no wrong. His code was poorly documented and difficult to read. The few bugs that were in his code were notoriously difficult to find because of his programming style. Eventually, management fired him because he wasn’t willing to be a team player.

A great consultant has to straddle the line between being that kind of Lone Wolf who can accomplish a set of tasks without any supervision, but at the same time, fit well into a team. As a consultant you’re working with the customers employees and need to teach them the things they need to know to be successful. At the same time, you have to be something of a good project manager. If you’ve only got a week to finish a project, then wasting 3 days chasing down a “nice to have” isn’t going to help you finish the project on time, let alone give you time to do any sort of knowledge transfer with the customer employees.

Finally, dial up your Humility Meter a bit. So you’re a consultant. You’ve worked on multi-million dollar software deals. You’ve installed software on tens of thousands of computers in a globally distributed environment. Your customers are all over the Fortune 100 list. Big fat hairy deal.

Customers might be a little impressed by that, but at the end of the day they just don’t care. They want to know that you’re going to do the job in a professional and competent manner. If you do a competent job, they’ll want your company to come back. If you do an outstanding job, they’ll want you back and won’t take anyone else. Which is great for you as a consultant, but bad for the consulting company you work for. This puts their consultant in high demand, rather than the company’s services. Don’t get me wrong, it’s great for repeat business, but if a consultant is good at what he does, most of his customers don’t want to take a chance on another consultant who might have a different style or a lower level set of skills.

How do I become a great consultant?
Like being successful, there’s no one secret to success. A great consultant is a combination of a lot of different things. Usually, you have to branch out a bit to be more successful. I’ve seen both ends of the spectrum and there’s a world of difference between a great consultant and a mediocre one, let alone a bad one. If you want to go from mediocre to great, here’s what you need to do.

1) Learn to be a great presenter
This isn’t just about public speaking, although that’s definitely a big part of it. I’ll give a follow-up blog post in the next couple of weeks to address this specifically because it’s a pretty big topic. Suffice to say that building a good presentation is key, as is being a good public speaker. If you have an opportunity to take a course on how to be an effective instructor, then do it. It will help you. Courses that teach how to be an effective instructor are generally technology or product agnostic. They teach you how to hone your delivery.

2) Become well versed in a lot of different technologies
It’s fine to be a Windows or Unix guru. It’s great if you can build PL/SQL queries in your sleep. But if you can’t relate your skills to problems across multiple technologies and business processes, this is going to hold you back. The ability to at least be aware of the pros and cons of various technologies allows you to relate those technologies to one another to solve larger business problems. It also gives you an effective position from which to offer suggestions on how to approach problems differently. It also helps to provide insight into how things work (or how they should work) when you run into technical difficulties. I’ve been able to pinpoint bugs in a product by knowing how the technology itself is supposed to work, without ever having looked at the code.

This is why developers who turn into IT consultants are so good. They tend to have an innate sense of how things would have been put together that they can troubleshoot things that they think are wrong. It’s like a sixth… or even a seventh sense. A good consultant doesn’t always know why he does the things he does.

3) Be professional
This sounds easier than it is and there are more things that you shouldn’t do than anything else. Don’t badmouth your product, your competitor, your competitors’ product, your boss, your ex-girlfriend, your employer, your ex-employer, the guy who was there before, etc. Airing your personal dirty laundry is simply not appropriate when you’re at a customer. It’s ok to tell stories of when someone did X, which was really stupid. But make sure that you do two things. First, don’t say names. The customer doesn’t need to know who the idiot was. Second, make sure the story serves a purpose.

For example, one of the best practices that I tell people when using a specific product is to always drag the computer onto the job, rather than the job onto the computer. It technically works both ways, but in the list of computers is a node called “All Computers”. If the mouse skips, or there’s a UI glitch in a remote desktop session, it would be very easy to accidentally install a new OS on every computer in the company. The story I tell is of someone who actually did that. It illustrates a point which is the potential consequences of doing it against best practices even though it works. And it illustrates that point without being demeaning.

Don’t brag either. Nobody likes the guy who brags about all of his past successes or the massively complex things he’s done in the past. On the other hand, you have to bring up some things you’ve done in the past to help make the customer comfortable that you’ve done this before. Using past experiences is a great example and an effective way to do this. You get to stroke your own ego a bit by telling a short story of a successful project you’ve done in the past, and at the same time answer their question.

“Mike, how do other companies do this.” “Well, there was another health care company I worked with that had a similar problem. Here’s what we did and it took us this long to do it. I know you’re a much smaller company than them, but it still takes about that much time to get it done. The issue isn’t the number of machines. It’s the setup time for all of the potential configurations. And the thing to keep in mind is that you’re using this technology instead of that one. So it’s a bit different, but the basic process is still the same. Here’s what I think you should do…” As you can see, part of this goes back to #2.

Finally, don’t look like a scumbag. Iron your shirt and pants. If your pants are worn out and threads are coming loose, throw them away and buy new ones. Customers are paying for a professional. The least you could do is look the part. Coming into work wearing jeans and sneakers isn’t going to endear you to the customer, although you can get away with it if there are extenuating circumstances.

I had a customer in Indianapolis who wanted me to deliver training to a class of 12 people for 3 days. I flew out on Sunday night, arriving there shortly before midnight. Unfortunately, the airline lost my luggage with all of my dress clothes. All I had to wear to the training facility the next day was the jeans and t-shirt I’d worn the previous day. The class started at 8:30am and since most stores weren’t open until 9am, it wasn’t as if I could go buy new ones. So I showed up in jeans and a blue t-shirt. I’d spent some time thinking about how to explain it, as I’d never met some of these people before.

I got a lot of funny looks as they walked in the door, but I started the class promptly at 8:30am with no nonsense. I told them that I was wearing blue because I was still upset that my Patriots had lost to the Indianapolis Colts several weeks before and that the reason I was wearing jeans and a t-shirt had absolutely nothing to do with the airline losing my luggage. They laughed at the terrible joke because all of them could relate to the situation. My professional, instructor-like demeanor carried me through noon when I was able to get back to the hotel where my luggage had thankfully arrived. Feedback at the end of the sessions included comments about how some of them were initially skeptical based on how I was dressed, but that I had handled the situation very professionally and they were very pleased with the course.

The way you look and present yourself in business as a first impression is very important and it can go a long way. But if you act like a douche-bag or don’t know what you’re talking about, your value as a qualified professional decreases dramatically and in very short order.

4) Shut up and listen
Customers and people in general like to talk. They want to tell you what’s going on and if you let them, they’re not going to be shy about telling you more than they probably should. You need to let them talk. I’ve been told of goings on which are considered illegal by simply keeping quiet. If you have ideas of how to solve their problems, ask if they’ve considered them. Don’t tell them what they should do before you find out if it’s something they considered. Otherwise, they will tell you why they already tried or considered that option and knew that wouldn’t work in their environment. Eventually they stop listening because you haven’t actually contributed anything.

The point of the first day at any customer is not to solve their problem. It’s to get the lay of the land and figure out what needs to be done. If the first thing you do is jump right into the middle of things without taking the time to find out the background story and what’s really important to the customer, you’re simply setting yourself up for failure.

Listen first. Ask questions. And don’t offer suggestions unless directly asked what to do. Even if that happens, talk about a few different options and then ask more questions. Trust me, you’ll seem smarter and sounds like you know exactly what you’re doing, even if you don’t. Making decisions without all of the information simply leads to poor decisions. Let the customer tell you everything. In fact, ask them to. Then filter out what isn’t important. Don’t let the customer tell you what’s important and what isn’t. You need to make that decision. By all means they should decide what is important to them in terms of goals and accomplishments because that will help guide how your solution is implemented. But you need to decide what information is relevant to the success of the project. That’s part of why you’re there.

5) Manage the project and your time well
Arrive on time, especially the first day. Most customers tend to be a bit lax about the exact hours when they’re paying for X weeks of assistance. So long as you get the job done, they don’t care about the hours you spend unless they are far lower than the amount they paid for. Unless you make some major mistakes, there should not be an expectation placed on you to work late unless that was a commitment made as part of the project. I’ve had customers start at 7am every day. Others have said that 10am is fine. The customer generally dictates the hours. It’s up to you to make sure that the project gets done during that time frame.

As the project progresses, your role should change from that of an information gatherer to that of a project lead. You need to drive the engagement, as opposed to letting the customer tell you what should be done. The presumption is that you’ve been a consultant for a while and have done a job like this before. You know the process and what should be done next. The customer doesn’t. Show them why they hired you. Unless you’re truly at a standstill and there’s nothing else you could be doing, then you should be working and moving towards your goal.

I’m not a consultant. Why should I care about how to be a great consultant?
The skills that make a great consultant translate very well into being a great employee. These skills translate into being a solid and well rounded business owner.  If that’s not something you’re interested in, then there’s somewhere else they come in handy. These are the same skills you need to be a great manager and I’m sure we can all agree that the world needs better managers.

These skills really aren’t for making a great consultant. They will help turn you into a trained and polished professional. Being a polished technical professional will translate very well into any career path you choose. I’ve never heard of anyone who was called “too professional” for a job in the technology industry.

]]> 0
Stupid Reasons to Start a Software Company Tue, 20 Apr 2010 11:00:44 +0000 Mike Taber

The second episode of our free podcast named “Startups for the Rest of Us” that Rob Walling and I created is live at our podcast website. This episode is titled “Stupid Reasons to Start a Software Company”. You can either listen to it in your browser or download the MP3 and a full written transcript of the episode has been made available. In an attempt to keep the noise on this blog to a minimum, I will only be announcing one more episode here. After that, it will be up to you to keep track of the new episodes, which will come out every Tuesday for the foreseeable future. So tune in and subscribe using any of the links below.

Subscribe Now:

In other news, look for another blog post later this week. Enjoy!

]]> 0
Podcast Launch: Startups for the Rest of Us Tue, 13 Apr 2010 12:30:01 +0000 Mike Taber

In 2006, I had been self-employed for less than a year. I knew a decent amount about business and a whole lot about technology, but wasn’t quite sure what I wanted to do. I had been involved in a startup called “Pedestal Software” for the previous few years and it was sold to Altiris to the tune of $75 million in March of 2005. I thought it was something that I wanted to be part of again, but having spoken with other founders who’d received angel and venture capital investment, the politics of it all made me queasy. I wanted to build software. Not cater to people who’d never actually done it before.

Then along came game Paul Graham, a former software founder who was offering people a chance at building their own startup via Y Combinator. Initially, it seemed like a great deal for an entrepreneurial founder but as I read the fine print, I realized that Y Combinator was not designed for someone like me in mind. It spawned a blog post called “Startups for the Rest of Us” that has since gone viral twice.

My biggest problem with Y Combinator wasn’t so much that you had to move, give up part of your company, or that you had to be selected. It was the fact that they were offering a paltry $2,000/month for three months to build a product and for that “privilege”, they would charge you 6% of your company.


Umm… This is Massachusetts. My mortgage alone is more than that. And their expectation would be that I would move to Cambridge, rent a house, and build something reasonably good in 3 months that people would be willing to pay for. In addition to paying my mortgage of course. Again, I don’t have a problem with the timetable, but the money is a deal breaker. For someone like me who is married with kids, a mortgage and the sole breadwinner for the family couldn’t possibly make ends meet for three months to do that. My only hope would be to use personal savings to help bridge the gap and if I’m taking that kind of risk, why should I bother giving up part of my company to do it? Feel free to read what I wrote back then, as I’m not going to rehash it here.

A tiny bit more background…

About 9 months ago, I reconnected with Rob Walling, who runs a blog called Software by Rob. Together, the two of us have been building a community of developers as part of the Micropreneur Academy to help people who want to be self employed but don’t know where to start. We came to the realization that we wanted to take things a step further. We wanted to provide even more information to developers who were interested in building and launching their own products. Not everyone who comes to our site is going to join the community, but that’s no reason to deny them valuable information to help them on their way.

The Actual Announcement

So today, it is with great fanfare and gusto that Rob and I are launching our new podcast, named “Startups for the Rest of Us“. If you’re looking for practical advice from experienced entrepreneurs who have been in your shoes, then our podcast is the place to get it.

The Details
We will release a new episode every Tuesday. The first episode is live at the podcast website and you can listen to it in your browser or download the MP3. We’re also providing full written transcripts of each episode in the show notes.

Episodes will be concise and run 20-30 minutes so you can listen to them during a jog, a short commute or part of a lunch hour.

We think that this is something you’ll want to check out. We’ve never done a podcast before and the first couple of episodes are a little bit rough, but we get better at it pretty quickly. Tune in and subscribe using any of the links below. Enjoy!

Subscribe Now:

]]> 3
The Single, Most Important Secret to Success Tue, 16 Mar 2010 12:34:27 +0000 Mike Taber

iStock_000010304538XSmallAbout 6 weeks ago, I had dinner at a pizza place near Boston with some fellow developers. We were generally discussing various aspects of business, things to do, things not to do, etc. One of the guys asked me a question that I feel like I get quite frequently:

“What’s the most important thing you need to do to be successful as a single founder?”

I immediately came up with three different things, but settled on explaining the importance of setting goals and having a plan for meeting those goals. We talked about how to go about setting goals for a few minutes and then went on to discuss other things.

This isn’t a new question to me, but I was uncomfortable with the answer. I seem to answer it differently every time I’m asked and not usually the same way twice. This past Friday, as I sat white-knuckled in a small turbo-prop plane that was being buffeted violently by winds over the mountains of West Virginia, it dawned on me why I had been uncomfortable with my answer.

I was wrong.

If you ask 100 successful people what the secret of their success is, every last one of them is going to be more than happy to tell you because successful people like to tell you their story. In listening to 100 stories, you will probably end up with at least 50 different answers. You will also get a mix of things to do, and things not to do. This is a problem because after listening to all of the answers, you are still left wondering what the secret is because everything they said will make sense and for each of them, it was probably true.

As my plane was buffeted by high winds and we dropped another 20 meters in a very short timespan, it dawned on me that being successful with your business is a lot like flying a plane. There are a lot of things that have to be done right in order to keep it going. There’s no single factor that makes a business successful and in fact, most of the time it takes many things done right to be successful.

It also isn’t so much about being great at any of them as it is about being competent at most of them. I had an interesting conversation one day with a pilot who was on his way to an assignment and he explained that he flew the big jumbo jets out of Minneapolis to Shanghai. I explained that I had a great deal of difficulty driving a 26 foot truck with a car trailer hitched to the back through the Berkshire Mountains in the middle of the night through rain and fog. I couldn’t begin to imagine how hard it would be to land a Boeing 747.

Pilots in the cockpitHe explained: “Landing a jumbo jet really isn’t that difficult. It’s all about systems management. You are just making small adjustments based on what the instruments tell you is happening and where you need to be.” I’m certain that he was oversimplifying the issue, but I also realize that my answer of setting goals and having a plan for meeting those goals is an oversimplification as well.

Running a small business is like flying an airplane. There’s not a single thing that keeps you in the air. It’s doing a lot of things right. But the truth is that whether it’s landing a plane or running your business, you can screw some things up and still be successful. You can recover from most mistakes, while others are going to be catastrophic. Forgot to refuel the plane before heading overseas? Probably catastrophic. Didn’t do the best SEO for your website? It will probably cost you more to acquire customers by using AdWords, but ultimately is probably not going to kill your business unless you screw that up as well.

If you compound your mistakes, your chances of failure increase dramatically. But each success will reduce the consequences of the mistakes. This is why large companies can have such a shoddy product and still make money off of it. They have so many things going on that the law of averages ultimately weighs in their favor. Does the product manager suck? No big deal. The engineering team will probably pull his weight. The code is riddled with bugs? No problem. The support team is there to help with workarounds.

So the secret to success is to realize that there isn’t a secret. Everywhere you look, you will find something that needs to be done competently. For everything you do that doesn’t measure up, you will have to make up ground in other places, keeping in mind that one success is less than or equal to one failure and that the sum of your successes must be greater than or equal to the sum of your failures.

If it’s not, then you probably just crash landed.

]]> 7
The Builder and the Salesman Tue, 09 Mar 2010 14:20:28 +0000 Mike Taber

Job Well DoneI published a popular article named “The Single Founder Myth” a few years back. In this article, I contended that contrary to popular opinion, it was not impossible to go it alone with a software startup and be successful. To clarify up front, what I mean by “going it alone” is that you build up the company without handing over equity to someone else, be it either investors or other co-founders.

In this article, I gave several reasons why companies have multiple founders and countered the necessity of each for a single founder company. I came to a sudden realization the other day why most technology companies have two founders.

It’s because one of them is a builder, and the other is a salesman.

The Builder is the person who is doing the bulk of the work building whatever it is that you’re trying to sell. The Builder is most likely the better of the two at development or engineering than the other and it is internally agreed that the Builder is going to make the major design decisions.

The Salesman is the person who spends most, if not all of his time trying to find customers and sell the product. It’s quite possible that this person will be the person searching for investors for the company as well and in essence, is “selling” the company as a viable investment.

Responsibilities other than building the product or finding customers are likely to be divided between them to some degree, but these primary roles will remain steady for quite some time until the company either starts hiring employees or falls apart. Things like creating marketing collateral, business negotiations, financial planning, etc. All of these things can be done by either co-founder.

But the ability to sell technology products and the ability to build technology products are two entirely different skill sets. There are very few people who possess both skills and even if you do possess them both, there are only so many hours in the day. The problem with trying to build up a product while you’re also acting as the salesman is that at the beginning, both of these tasks are extremely time consuming and tend to be mutually exclusive.

I know from experience that developing software or designing hardware is something of an art and it helps if you’re “in the zone”. It takes time to get into that zone and once you’re there, if you’re interrupted it can take a long time to get back, assuming you can get back that day at all.

I also know from experience that sales is very much an interrupt driven process. It takes several minutes to prepare for any “major” sales calls and when you’re leaving messages, people can reply at any time which is very disruptive to whatever schedule you were trying to keep. With a co-founder, it would be a lot easier to have one person field all of the calls while the other concentrates on building whatever it is that you need to build.

Does that mean I’ve changed my tune? Do I now want to run out and find a co-founder for my company? Not a chance.

You see, the Builder and the Salesman model works great for companies where you really do need a sales force, be it for customers, angel investors, VC’s, or distributors. While one person is working hard in a back room somewhere, the other can be on the phones or hitting the pavement trying to land sales and close deals.

However a lot of software companies these days don’t hold themselves to that model. In fact, many shun it like the plague because the cost to acquire a customer on the internet is exponentially lower than it is if you require a sales rep to call on each of your prospective customers. It’s more efficient to use Google AdWords to solicit 1,000 visitors to a website and sell to 1,000 people at the same time than it is to have a sales rep call 1,000 people in succession and ask if they’d be interested in what you have.

“Hi, this is so-and-so from Acme Widgets and we’d like to sell you some software.” *click*
“Hi, this is so-and-so from Acme Widgets and we’d like to sell you some software.” *click*
“Hi, this is so-and-so from Acme Widgets and we’d like to sell you some software.” *click*
“Hi, do you have a minute?” *click*
“Hi, do you have 30 seconds?” *click*
“Hi, I am in contact with you to disperse a sum of $30 million US dollars from a bank in Nigeria that is no longer being claimed.” *click*

This sort of thing gets old quick. You can hone your story as good as you want, but at the end of the day it’s still difficult to make sales one on one. A lot of large companies are still very successful these days doing it because they have price points that are so high you absolutely need to have a sales rep.

Do I need a Salesman as a Cofounder to be successful?

Absolutely not. There are millions of products being sold online today which don’t require or use a sales rep at all. Don’t get me wrong, the price points are a lot lower, but let’s be honest. What price point do you expect to be putting on your software?

The reality is that in many organizations, the role of the salesman can be eliminated, especially if you’re selling your products online. In that case, what you really need is a marketer. Building a better mousetrap doesn’t do the job like it used to. When two products go to war, the one that wins is going to be the one that has better marketing, not the better product.

Now here’s the best part about this arrangement. Because you’ve eliminated the salesman in favor of a marketer, guess what time is the best time of day to do business on the internet?

The answer is that it doesn’t matter. Whether it’s 2pm or 2am, you can make changes to your website, update your marketing collateral, review website visitors and statistics, etc.  No matter what time of day it is, you’re not actually interfacing directly with customers. You’re setting things up so that customers will see what you want them to see, and when you want them to see it. There’s never a time when a customer comes to your website, you size him up and say “No, come back tomorrow.” It just doesn’t happen. Sales reps on the other hand are required to work within the schedules of their customers and try to convince them to allot time to speak with you.

What this means is that you can be both a builder and a marketer and so long as you’re selling your products online and don’t require a sales channel, you don’t need that salesman. Hence, you don’t absolutely need a cofounder.

A Word of Caution

To be a successful single founder business, you need to be really really good at two things: Building software, and marketing it. Without both of those, you’re basically sunk. If you’re a great builder, then you’ll have a wonderful product that nobody is ever going to hear about. If you’re a great marketer but a lousy builder, you’re going to find that you can put lipstick on a pig, but it’s still a pig and everybody knows it.

]]> 1
Podcast appearance on .NET Rocks Fri, 05 Feb 2010 19:02:41 +0000 Mike Taber

Fellow blogger Rob Walling and I were featured on the .NET Rocks podcast yesterday. You can check out the interview here. We’ve been featured on a few other podcasts for the Micropreneur Academy that we put together last year. When I get a chance, I’ll post the links to those podcast interviews.

]]> 0
Be Smart, Make a Ton of Money Doing Stupid Stuff Fri, 08 Jan 2010 13:43:16 +0000 Mike Taber

Several weeks ago, someone pointed me to an article on a blog I’d never read before. It was very profound it its simplicity. It was called Smart People should do Stupid Stuff. The basic concept of this blog post was that there are millions of dollars to be made doing things on the internet that anyone is capable of doing. I mean quite literally, anyone can do these things, regardless of how smart or how dumb you are. Here’s a very short excerpt, because I know you’re not going to go actually read the entire article.

I once met a man that made over $1,000,000/year selling bowling balls on the Internet.  I asked him how he had built such a fantastic business. I was looking for this guy’s secret sauce. Was he a marketing guru, a tenacious entrepreneur that didn’t give up, saw an opportunity earlier than most? None of the above. He was an average guy, with below average technical skills. He hired 2 kids to work out of his garage to build his website.

When I hear about ideas like the Million Dollar Homepage, Santa Mail or Antenna Balls that easily rake in more than a million dollars, I almost want to puke. Or at least I used to. Let’s face it. These are stupid ideas that border on absurd. But they work. And do you know why?

Because the people behind them found a niche market that nobody else was looking at. Each of these people did something that any of us would have the skill or lack thereof to do. Making money online isn’t always about technical ability. Nor is it about being in the right place at the right time.

The key to success for these people finding a niche market that nobody else was in and dominating that market. Once you’ve dominated a niche market, you’ve done something that makes you virtually untouchable because you’ve done two things. First, you’ve identified a niche that nobody else had the time or energy to go into. Second, you have created a barrier to entry which virtually assures you of owning that market for years to come.

The next time someone tells you that they have an idea for an online business, think twice before spouting off about how dumb the idea is. I’d bet money that if you told someone more than a few years ago that you were going to make a 9 figure business out of sending 140 character messages to a website, a lot of people would have laughed at you. Guess who’s laughing today?

]]> 4
Demote Your Product Manager, Release Better Software Wed, 06 Jan 2010 19:04:18 +0000 Mike Taber

trashmanagerWhen it comes to software, my second biggest pet peeve is software that doesn’t work. By that I mean software that blatantly doesn’t do things that it should fundamentally be able to do. For example, things like… I don’t know… like maybe changing the administrator password of the application to something other than “admin” without crashing the whole damned craplication until you reinstall it.

I don’t blame the developers. Sure, they write the code, but at the end of the day they’re not the ones who sign off on the release. I think it’s pretty rare that some junior developer says “We’re ready. Ship it!”, and only then will the product ship.

It’s certainly not the testers. Heck, does anyone listen to the testers or take them seriously? I do, but I think I’m in the insignificant minority there. No, it’s not them either.

It’s always the Product Manager that makes the decision to ship. Meanwhile the junior developer is jumping up and down in his cubicle screaming at the top of his lungs. “What are you idiots doing! It’s not ready yet! We still need to fix this bug over here which crashes the application 14.7% of the time, and the font size I reported as being wrong four months ago which would only take five minutes to fix STILL HASN’T BEEN FIXED!” Meanwhile, the senior developer next door has long since been hardened to such ineptitude sits back, drinks another cup of coffee, and checks the local weather for his kids soccer game that evening.

I remember being “that junior developer” and asking myself why we were shipping a product with tons of bugs that we knew about. Why couldn’t we just hold off just a little bit and fix the things that were out and out bugs? Didn’t anybody want to ship a product that actually worked the way it’s supposed to?

I’m specifically talking about bugs. I’m not referring to features that haven’t yet been implemented or are on the roadmap. I’m referring to actual bugs that cause the application to not work the way its supposed to and that we already know exist because they’re in the bug database. If some things are inconsistent or the fonts are wrong, big deal. I mean the stuff that’s kind of a big deal.

Shoddy software really gets under my skin. Over the years, I realized that the developers are actually the people who are the least responsible for these problems. Certainly, my experience is limited to the handful of companies that I’ve worked at full time. But, I’ve consulted for dozens of companies and I’ve never seen a company let the developers make the decision about when to ship a product.

This is just sad.

Unfortunately, product management generally makes the decision to ship and it’s my contention that this is probably the worst place to make such a decision. Here’s why.

Product management has the power to order a product to be released, but is not provided with the incentive to ship a good product.

There, I said what all of you were thinking and know to be true. Product managers, commence flaming.

If you look at the job description of a product manager, you’ll find that the intent is to make him the interface between developers, customers, the sales team, and management.

Developers are content to sit at their desks and bang out code day in and day out. They want to ship a good product. Their egos depend on it. Customers have demands of course, but the Product Manager  can balance them against the needs and goals of the company by putting feature requests on the roadmap and countering opposition by saying “It’s on the roadmap and our roadmap is dictated by the majority of our customers”. The customers want a good product too, but they also want new features.

Interfacing with the sales team is hard for the Product Manager. The sales team will do as much wheeling and dealing as is necessary to convince him to ship the product on a particular date and the Product Manager has virtually no incentive to do otherwise. It’s the squeaky wheel that gets the oil, and sales people squeak a lot.

The sales team has no direct power over the developers, so they leverage the Product Manager to get him to do their bidding. The sales reps are compensated on what they sell and it’s obvious that releasing a new version of any software will provide a boost in sales. Ultimately, this is good for the company and indirectly it is good for the Product Manager because more sales means the product is doing well.

With the management team, the product manager is between a rock and a hard place. He has no power to tell the management team “No, we’re not going to ship the product yet. It’s not ready.” His job is on the line and lets face it, nobody really enjoys looking for a new job or looking bad to their boss.

So products get shipped with bugs, the support team deals with the influx of calls, the product sucks,and we have the product manager to thank for it.

There’s a relatively simple solution to this problem. Make the product manager subservient to the development team. This isn’t going to sit well with Product Managers because they are currently autonomous for the most part. But if the Product Manager is forced to convince the developers that a product is ready to ship rather than the Product Manager dictating when it’s ready, then perhaps the software that gets unleashed to the rest of us will get a little better.

And isn’t better software the ultimate goal?

]]> 2
The Day the MicroISV Movement Died Tue, 17 Nov 2009 22:34:51 +0000 Mike Taber

Rest In Peace #1

I remember the day very clearly, although it was not apparent to me at the time. It was the day that the Micro-ISV movement died.

A Brief History

For those of you who aren’t familiar with the history of the Micro-ISV, I’ll provide it for you here. Eric Sink is widely credited with the creation of the term “MicroISV”. As far back as May 8, 2003,  Eric was talking about what he referred to as “Small ISV’s“. The concept is rather simple in nature. An “ISV” is an independent software vendor, a phrase which is derived primarily from the Microsoft ecosystem and refers to software companies that are not Microsoft. As for the “Small” part, they’re small companies with anywhere from 3-100 employees. It’s a pretty simple definition, but definitive as well.

In September of 2004, Eric Sink published this article on his blog, which had appeared on MSDN a little bit earlier. His intent was to focus on what he called the “MicroISV”. It seems to have occurred to Eric that companies of only one or two employees were out there, producing software and doing rather well for themselves as single founder companies. This thought intrigued Eric. So much, in fact, that as part of his MSDN series of articles he decided to undertake the process of building a MicroISV himself to provide him additional content and experience to draw new articles from.

So it was, that Eric Sink, CEO of Source Gear and self-proclaimed .NET Redneck undertook a 16 month journey in which he built a product in his spare time and sold it online. Over the course of those 16 months, he chronicled his progress on both his blog and in his MSDN column titled “The Business of Software“. Developers and geeks around the world rallied to the battle cry raised by Eric. Large numbers of new MicroISV’s were founded, forums were started, and journalists latched on to write books about the topic and ride the wave of popularity to success.

He can show us the way!” some thought.

He has unfair advantages like his MSDN column and a massive blog following. This isn’t going to show us anything!” said others.

How much money would he make? How do I follow in his footsteps? The world of Geeks held its collective breath and watched as Eric raced down the path laid before him. Behind him followed a crowd of geeks, waving flags and pom-poms, watching intently to see which way the story turned. So for 16 months, we followed Eric to see the conclusion of the story.

And Then Eric Killed the MicroISV

Abruptly, one day Eric announced that his journey had ended. He sold his MicroISV to Dennis Cronin for an undisclosed 4 figure sum, which implies a maximum sale price of $9,999. With sales reaching a mere $215 over the course of 16 months (including September of 2004), we can surmise that the actual amount was probably a lot closer to $1,000 due to the multiples at which products are typically acquired. The “profits” were donated to charity.

What did this mean for the MicroISV movement? A giant kick to the crotch. That’s what it meant. And it accomplished virtually the same thing.

I’ve seen the statistics for one such website that marketed directly at MicroISV’s starting in 2004. Website traffic has approximately halved every single year since Eric’s announcement. Websites are supposed to grow. You add content, you build out the site, more  visitors come, and website traffic grows. That hasn’t happened. In fact, the reverse has happened. Traffic for this particular site shows that the current traffic levels are a mere 6.25% of what they were at the end of 2005. That’s not just bad. That’s appalling. I did some in-depth research and found that traffic started dropping quickly immediately after Eric’s announcement, after showing month over month growth the prior year. Other sites have disappeared from the internet entirely.

Therefore, I submit to you that it was on December 26th, 2005 with not much more than a keyboard and a blog entry, that Eric Sink effectively killed the MicroISV movement.

This Is NOT Eric’s Fault. It’s Ours.

I’m going to be blunt here. Eric was not trying to start a movement, nor was he out to kill it once it started. He started his MicroISV for two reasons, and only two reasons: He was curious about what it took to run a MicroISV and he wanted to help generate content for his Business of Software column on MSDN’s website. That’s it. He didn’t do it for you, he didn’t do it for me, and he certainly didn’t do it to build a new revenue stream for himself. I’m fairly certain that he is well compensated as the CEO of SourceGear.

Far too many people are under the impression that if Eric Sink couldn’t make it work, then what chance do they have to make it work? This is the wrong way to look at it. Instead, as I’ve said in the past: “If at first, you’re not successful, take a good hard look at what went wrong.” Unfortunately nobody seems to have done that and when the appointed figurehead of a movement falls, people lose interest.

Everyone has honed in on the fact that Eric failed. Thank you, but I beg to differ. Let’s get one thing straight. Eric accomplished what he set out to do. He never intended for it to turn his MicroISV into something bigger. In fact, Eric intentionally stacked the deck against himself.

Eric’s (Self-Admitted) Mistakes

Lack of Motivation- Eric was simply not committed to building his MicroISV into a solid revenue stream. He built the product to write articles and once that had run its course, he had little use for the product or the MicroISV that was built from it. To quote him directly:

But I must admit that my situation is unusual. Most people start a micro-ISV because they are attracted to the idea of being an entrepreneur. A sense of dissatisfaction with their current job is a source of motivation.

I’ve been there, but right now I don’t have that particular set of problems. I am already an entrepreneur, and I am quite happy with my situation. Here at SourceGear we actually like building developer tools, and we’re having some very nice success doing it.

So with Winnable Solitaire confined to my copious spare time, it may proceed slowly. But I do have some ideas for what I want to do next with this project. I will close with a few remarks about my next iteration through the cycle that Pavlina describes.

Choosing the Game Industry - Speaking from experience, I can tell you that the game industry is brutal. Either you have a hit or you don’t. And if you don’t, you need to dedicate significant resources to finding out how to make it more appealing. Selling games is different than selling business software because you’re not solving a pain point. You’re providing entertainment, which although it is technically a pain point for the consumer, there are millions of competitors.

If you’re selling source control products, you have maybe 20 competitors tops. When you sell games, you’re competing not only with other games, but all other types of entertainment mediums, such as tv, movies, newspapers, comic strips, not to mention all of the other computer games out there. I’m not saying this is impossible, just a lot harder than selling business software that solves a definitive need. Eric basically admits that he would likely be more successful in a different market, almost from day one in his First MicroISV report.

Competing with Free Products - Solitaire is included with every copy of Windows. I’m not sure I see the point in competing against Microsoft in what is arguably the smallest niche market I’ve ever seen. ie: Solitaire games that are guaranteed to be winnable. Thomas Warfield seems to do pretty well in the broader Solitaire niche.

Ignoring Common Sense – Eric openly admits in the Bottom Line of his initial blog entry that “Common sense would say that my product is doomed.” This is putting it lightly in my opinion, but is true nonetheless.

The bottom line is that if you know the mistakes that you’re making before you’ve even started, you’re going to wind up flat on your back like Charlie Brown. Letting Lucy hold the ball doesn’t excuse you from being the source of blame anymore than Charlie Brown’s faith that, just this once, Lucy will let him kick the ball.

Wait… How Is This Our Fault?iStock_000010207268XSmall

Eric killed the MicroISV movement because we let him. Eric never asked to be the poster child for the MicroISV movement. Neither did Joel Spolsky for that matter. But they have been for nearly a decade because we appointed them to those positions. The MicroISV concept struck a chord with a lot of developers and micropreneurs who wanted to start their own companies and quit their day jobs. The expectations that were placed on Eric to do well with Winnable Solitaire were unrealistic and quite frankly, not in line with what Eric was trying to do.

When Eric’s product failed to produce anything remotely close to a full-time income, scores of developers abandoned their MicroISV’s and started looking for another way out of their 9-5’s. They found what they were looking for in Paul Graham’s Y Combinator program. Paul launched Y Combinator with in early 2005 and quickly produced success with companies like Reddit and Loopt. The dynamic quickly shifted and as the MicroISV movement slowly withered away, the future for micropreneur hopefuls shifted to startup companies which leverage Angel and VC funding.

Let me be honest for a minute. In no way, shape or form would I claim that starting your own software company is for everyone. But the Angel and VC funding route is a lot harder to swing for most of us and living in the geographically blessed startup hubs is merely one of those reasons. Back in 2006, I wrote an article called “Startups for the Rest Of Us” and posed the question: What about me?

At the time, I had mixed feelings about Eric’s “failed” experiment. On one hand, I felt like he didn’t really follow through with it the way he could have. On the other, I had recently left the fold of Pedestal Software which was acquired for $65 million and the lure of doing a startup and cashing out after two or three years for millions was pretty high. I knew I could build products, but didn’t feel like I had any ideas at the time which were worthy of millions of dollars of investment. I had been offered $50k as an initial investment, but ultimately turned it down. Instead,  I decided to take it slow and build my own company.

The Landscape Today

Amazingly enough, the landscape of building an internet business today is not much different than it was five years ago. All you need is a computer, an internet connection, and knowledge of how to develop software and you can crank out a product. There are thousands of resources available to help you get started. There are countless blogs, startup schools, online academies, free or reduced cost software packages for startups, and a host of other advantages that didn’t exist several years ago.

It doesn’t matter how old you are today, where you live, or what you do for your full time job. If you have a computer, an internet connection, know how to write software, and most importantly, the drive to succeed, then you can sell products on the internet and make money from them.

Eric didn’t make a lot of money with his MicroISV. Big deal. Does one failed attempt from an internet legend define a movement? I think not.

Besides, just because you start out small, doesn’t mean you have to stay small.

]]> 5
How to Make Developer Certifications That Matter Thu, 12 Nov 2009 13:34:23 +0000 Mike Taber

Breakthrough! Jumping of happiness

Last week, I was asked by a potential business partner what I thought of certifications. I immediately clapped my hands like a giddy 3 year old at Christmas and screamed out “It depends, it depends!!!”. Ok, so maybe I didn’t really get giddy, clap my hands or scream, but in standard consultant fashion, I did say that it depends. Then I launched into a spiel about the customers we were specifically talking about who might or might not actually care about certifications and why. This made me think about certifications for developers.

Unfortunately, certifications for developers don’t mean much to other developers. If you have just one certification, people will probably look past it. But if you have a laundry list of developer certifications, other developers are going to start asking what it is that you really know. In general, I’ve found that the number of certifications a developer has is usually inversely proportional to their actual skill. Most people I talk to would agree. But why is this? There’s one simple answer.

The certification system for developers is fundamentally broken.

Certification Is Intended to Signify a Minimum Level of Skill

In some industries, it’s perfectly valid to ask that people go through a certification process. What kind of people you ask? Oh, I don’t know… maybe the guys who run the wiring in your house for example. Need to ground a wire? “Oh, just hook it to a pipe that drains outdoors somewhere. Hey, there’s the pipe from the bathtub. Perfect!”

Meanwhile, he crosses hot and ground, thus giving your wife a good jolt when you turn on the lights in the bathroom because for some inexplicable reason, she showers with the lights off every morning. Don’t ask me how this happened. It’s your wife, not mine. I just write the facts. Anyway…

The intent of a certification program is for an independent party to somehow measure your skill or ability and declare that you are reasonably competent with whatever it is you have been certified for. In the case of an electrician, a board has certified that you aren’t a complete moron and you would probably know the safety and state code violations associated with connecting a hot wire to the pipes instead of the ground. I would probably also want the EMT’s who show up in the ambulance to be certified at what they do, as well as the guys working the nuclear power plant down on the Cape. I’m sure you can think of other places where certifications are probably warranted, but remember, we’re talking about software development certifications here.

Skeptics such as Tom DeMarco argue vehemently against certification of any kind for Software Engineers. Tom makes many good points during his argument about the potential for abuse, de-certification processes and that the people who argue that certifications are for the greater good are the ones who stand to benefit from implementing the system itself.

Touché Tom.

But all of this is beside the point. Tom wrote those words more than a decade ago and our resident “hire the smart guys who get stuff done” leader Joel Spolsky didn’t have much to say about it back in 2000, instead pointing to Tom DeMarco’s original post. Today there are dozens of development certifications out there, many of which either didn’t exist at the time (MCSD) or were still in their infancy (SJCP).

So why do they exist today and what purpose are they supposed to serve?

The Problem of Hiring

Over the years, the IT industry in general has pushed for certifications because managers know how to manage, but not how to identify talent. Most people lack a fundamental understanding of how to interview new programmers and even the ones who do understand it aren’t perfect. Many are constrained by a corporate culture which forces them into accepting one of the 15 people who were brought in for an interview rather than going back to the pool of candidates to keep looking.

So the tech industry giants plodded on, in part at the behest of giant corporations seeking new and “innovative ways” of evaluating developer applicants. An entire ecosystem of software development training was born and guess what?

It sucks.

What’s worse is that everybody knows it sucks.

Certified vs. Competent

Being certified doesn’t mean you are competent. And being competent doesn’t require certification. The original intent of these certifications was to test for competence but thus far, they have failed to do so. Essentially we’re left with a truth table which reads something like this:

Certified Competent Reasonable Hire
True True True
True False False
False True True
False False False

The only influencing factor in whether the person is a reasonably decent hire is that the person was competent to begin with and certification has done nothing to improve identification of this. In fact, it has arguably made it worse because developers tend to look down on other developers who hold a lot of certifications.

Co-Worker/Colleague Opinions

I’ve never spoken with a developer who had good things to say about any of the major software development certifications. It’s not outright hatred of certifications that I’ve seen; merely indifference. The problem is that a certification doesn’t actually prove anything beyond the fact that you can take an exam and pass it. Big deal.

But what about the money? Isn’t your salary higher if you are certified? Not necessarily. Unless I’m misreading the statistics here, the most recent survey from MCP Magazine shows that the mean salary for an MCP is $77,244 and the mean salary for someone without any Microsoft certifications is $84,839. That’s a $7,595 difference advantage for not being certified. So what gives?

It’s important to note that these statistics don’t give all of the details about how they were put together, so we have to infer some of our data points. First we go back to the reasons to get certified. If the primary drivers behind getting certified are to fast track your career or lend credibility to your abilities because you don’t have a proven track record, then it stands to reason that you are an entry to mid-level programmer.

If the number of certifications is weighted towards those with less experience, they’re going to make less money than those with more years under their belts. This doesn’t mean they make less money. Just less than people with more experience, which tends to make sense. I have yet to see statistics that directly pit the salaries of certified developers against non-certified developers. I’m sure they exist, but I couldn’t find them anywhere for less than a few thousand dollars. I like my readers and all, but it just wasn’t worth the money to find out the details.

How To Fix Developer Certifications

iStock_000001171305XSmallThe fundamental problem with developer certifications is that traditionally, they don’t actually prove anything. Microsoft, Sun and all of the other major software vendors have a financial interest in making sure that their technologies are used pervasively in the world. One of the ways to do that is to expand the number of people who are qualified to implement solutions based on that technology. So they lower the bar by producing easier tests and lowering the required test scores, thus allowing thousands of people become certified in an effort to expand their reach, while at the same time ignoring the implications of diluting the meaning of those certifications.

Can this be fixed?

I believe that it can and all it would take is one relatively simple change to make these developer certification exams a lot more meaningful.

Make applicants write code and grade them on two things:

  1. how long it takes to complete a moderately complex problem relative to other applicants
  2. the number of bugs that are encountered in the final product

That’s it.

You see, the fundamental problem with these exams is that they don’t actually test what developers are supposed to know how to do, which is how to write code. All through college, you take free-form exams for subjects such as Calculus, Differential Equations, Physics, Computer Science, Software Engineering, Senior Projects and others. It’s very rare to find multiple choice exams here and the ones that do exist are so difficult that if you didn’t know what you were doing, you would get the answers wrong anyway.

Some professional exams do this well. For example the Professional Engineer Exam is a two exam certification process. The exam part contains both free form and multiple choice questions. After several months you get your results. Assuming you pass, you must continue to work in the field, provide proof of that field experience and take a much more difficult exam which consists of advanced engineering topics.

There are certain types of financial accounting exams which are notoriously difficult because they use a ladder system where at each stage up the ladder, only a limited number of people are allowed to pass. You must beat the scores of your fellow test takers, rather than beat a predetermined test score. As you progress up the ladder, the competition makes the exams more and more challenging, thus allowing only the best of the best to advance.

Using a developer certification exam with the above criteria would easily accomplish the goal of separating the mediocre programmers from the rock stars. In addition, the higher up the ladder you go, the easier it is to quantify how you relate to the rest of the developers who took the exams.

There are of course some logistical problems that would need to be dealt with. For example, most developers search the internet for code examples pretty extensively. You would need to allow searches, yet disallow chats with other people who might help someone cheat. Doing this for tech savvy developers is going to be difficult, at best. Also, developers would be much more comfortable with a configuration and software setup that mimics their own development environment. These and other problems would need to be addressed.

But where there’s a will, there’s a way and I have no doubt that if a major software vendor were so inclined to do this, it would work. This would put solid metrics on the certification exams and provide meaningful, quantitative measures in place for measuring the development ability of a candidate.

Do you agree or disagree? Please post your comments below.

]]> 3