How to Kill a Software Company

©2002 Don Gray

A Software Project By Any Other Name

Most software practitioners and managers are aware of a project’s three legs. These legs are features, schedule and quality. (1) While all of these are important for a successful project, one must be dependent on the other two. (2) Failing to acknowledge this will guarantee that if the project does succeed, it will be due to the sacrifice of the quality of the participants’ personal life (health, finances and relationships), the fortuitous combination of the team’s skills, and a good dose of luck.

Interestingly enough, we seem to succeed at software projects often enough that an while individual project or multiple projects fail (for whatever reason)3 enough projects succeed that the act of creating software is valuable enough that the “pockets and bean counters” continue to fund additional aberrations of reality.

Close But No Cigar

So being unable to deliver good stuff (or anything) most of the time is not sufficient to kill a software company. Nope, to kill a software company requires a solid understanding of three slightly different “legs”. These legs are “If It Ain’t Broke, Don’t Fix It”, “It’s What The Customer Thinks”, and “The Number of Nerds are Finite”. Anyone of these legs can be sufficient to do you in. To fail quicker, you need to have at least two, and for complete, total, and a quick freedom of your future, you should strive to grab all three legs.

If It Ain’t Broke Don’t Fix It

Seems obvious doesn’t it?

You’ve finally shipped something that people might want with hopefully good enough quality that people actually buy it. Using it would be nice too, but isn’t necessarily needed5. In fact, based on the product, it’s possible that it’s so hard to use that the tech support costs will be more than the revenue generated by the product. But assuming that’s not the case, now is the time to relax, and take it easy. This would be nice except that …

Plagiarism is the sincerest form of flattery

And some company out there is going to flatter you. Even if you do have bullet-proof exclusive “rights” and the money to defend those “rights” in court, eventually the competition is going to provide a solution to your customers that is going replace you in their mind, on their computer, and from their wallet. In an industry where events are measured in Internet Time6 not updating your product reduces your time to market to 0(t), which is probably about how long you’ll be around.

The Only Constant Is Change

If you don’t keep changing with change, you’re going to change anyway. The difference will be an opportunity to have (hopefully) some input or influence in the change (8), or suddenly you (and your company) will be the byproduct of the change.

It’s What the Customers Think

What if you’re cursed with a company that realizes the need to follow the market changes?9 All is not lost! Just as important as how your company deals with technology is how your company deals with people10. This means that if you can frustrate, aggravate, or discourage the people who do buy your product, you can still kill your company.

Of All The Things I’ve Lost

I miss my mind the most. This is where I kept who and what is important in my life. The good news for you is your customers keep who and what are important to them in their minds. The point here is that you can be replaced in your customers’ minds in two convenient methods. The first is complacency (remember the “If It Ain’t Broke …”). The second is to make sure that every time the customer interfaces with your company, it is a bad experience.

Training?

It left on track 9 at 8 this morning. Didn’t we tell you? For maximum effect I recommend you schedule software training classes randomly, and create a semi-correct training manual11. For extra effect, have a new employee who doesn’t understand the problem domain, hasn’t used (or contributed to) the product, and doesn’t like working with people12 teach the class. To help confuse things, have non-native employees create your documentation. The unique language constructs will help aggravate your customers. For added effect, randomly change type sizes and fonts.

If you do a bad job at bad training, the users will understand how to apply the software to solve their business problem. This reduces the technical support burden (less cost to your company and less aggravated customers) and could lead to a reverse in negative training cash flow as the users recommend the training to other companies.

For More Help, Deposit Another $25

It used to be a Quarter ( $ 0.25), but everything is more expensive these days. If you’ve done a good job at bad training, no one is going to understand how to use the software. The problem they wanted to solve by buying the software won’t be solved (but that’s not your problem), and the probability of losing the customer’s business is increased (especially if they lose their job because of it). For added assurance, have the same employee teaching the class provide the technical support when they’re not teaching the class. This should really discourage the users.

For Extra Credit

You can figure out additional ways to alienate customers. Possible areas include order processing/shipping, invoicing, licensing … and(13)?

Where’s A Nerd When You Need One?

Last But Not Least

You should figure out where your product is in its life cycle. This will allow you to violate the following Quality Perceptions over Product Lifetime table (14) intelligently. You should leave nothing to chance.

* Medium pressure for features does not mean pressure for new features. It means that the promised features must be in the product and must be working.

In fact armed with this chart you should be able to “spiral” back to “It’s What The Customer Thinks” (15) and review your plans for frustrating, aggravating, and discouraging your users. The truly attentive student now realizes that there are 5 * 3 * 3 (or 45) different things they should be doing to alienate their customer base.

The Good News Is

It is a limited marketplace. There are a few applications that are relatively common, but most software companies have a much smaller possible client base. To calculate the number of people you possibly need to deal with, the equation is PND = TP - TAA - TUCP.(16)

Risk Is Risky

Do Them All

And leave nothing to chance. The future is out there. Bright, rosy, and just around the corner. If you follow these simple steps, I’m sure you’ll be able to kill your software in no time.

But In the Interests of Science

I should mention that I’m sure there are other ways people have killed their companies. If you have a really creative story, and would like to share it with me, my email address is [email protected].

For First Time Offenders

What you might want to do is keep a diary of how things are going. Don’t be discouraged if it takes longer than you expect. Users can be loyal much longer than they really should. There are reasons for this, but they are beyond the scope of this article. When you finally succeed, send me a note and let me know about it. Feel free to use the same email the story tellers are using.

Notes

1. Actually, there are a couple of other “three leg” choices, but you get the point. If you don’t control at least one “leg”, place your bet on long hours, unhappy users, and very probably a disastrous project
2. I first learned about this in an article by Rick Zahsiner on “Time-boxing”
3. Industry literary coverage is thorough in its numbers. Pick some value between 30 and 80 percent on the number of projects that fail for whatever reason. It would be nice to have a breakdown on the failures by category, but that seems to be not as spectacular and a whole lot harder to determine.
4. The current quintessential example of this is the stock market current darlings “Internet Companies”.
5. Does “shelf-ware” mean anything to you?
6. I dislike phrases like this, but it looks good in print and I hope gets the point across
7. Things like operating systems, languages, and such.
8. Notice I didn’t say “control over change”. This was not a mistake.
9. There is a difference between the bleeding edge and the leading edge. You figure out where you want to be, but being on the bleeding edge is a better way to kill the company. Read on and find out why.
10. Face it, if we were good at dealing with people, we’d have chosen a career like selling shoes or doing something with a higher success rate than writing software.
11. This is much better than a manual which is totally correct or totally wrong. This way the user isn’t sure which is wrong, them or the manual.
12. In case you forgot, see 10.
13. If you have an example you’d like to share (from either side of the relationship, my email address is [email protected].
14. I’m sure when Johanna Rothman published this table in Reflections, Volume 1 Number 2, Page 4 “Project Toolbox: What’s the Focus of your Project?” she had no idea it would be used for such an interesting use. But a tool is a tool, right? And if your only tool is a hammer, everything looks like a nail.
15. Blaise Pascal noted “The last thing one knows in a work is what to put first”. I think I got that right although I may have flopped 2 & 3.
16. Where PND is People you Need to Deal with, TP is the total possible population, TAA is the Total number you’ve Already Aggravated, and TUCP is the Total Users using a Competing Product. This represents a single point in time. The equation with respect to time will appear as decreasing Log curve.