The Magical, Erratical, Sometimes Tragical Money Shrinking Machine

It should come as no surprise, given the fiasco I've been documenting on this blog, that my company isn't profitable. We burn through an amazing amount of money per month. Given our bottom line, our only viable option as a business would be to become money launderers. Although, I'm not sure a 10 to 1 exchange rate of dirty to clean is all that good.

I know the person reading this blog is wondering how they too can successfully waste tons of investor money. Well, luckily for you, I'll give you a sneak peak of some of the business strategies that have made us a negative profit powerhouse.

Never Say "No"

The first has to do with the fact that we're giant pussies when it comes to dealing with our customers. As an example, we had one of our installers call our technical support line when he was having a problem configuring his network. We didn't sell him anything dealing with his network. We weren't responsible for his network problems. He was having problems configuring his DSL modem. Initially we said we wouldn't help him.

The installer then called the CEO directly and pitched a fit. Since he's an A++ customer (our customers are rated A, A+, A++, A prime, and A++ super prime I believe) the CEO assured him we'd fix the problem. We spent a couple of days trying to figure out what his problem was and how it could be fixed, all for free.

Fly Someone Out

The next tip I have is for you to fly a person out to babysit any install, free of charge. Any time an installer has an issue with our product we like to fly someone out for free to do the install for them. Sure, we could try and work them through it over the phone but that wouldn't waste enough money. We could even require them to complete our training program before helping them. Again, that's just not realistic. We could even bill them something for the fact that they couldn't do their job. No, the better plan is to provide a way for them to get free consulting and install labor whenever they want (and it turns out they want it quite a bit). On a plus note, all of our sales and support guys have shit loads of frequent flier miles that they've amassed on the company dime.

If You Burn It, Just Return It

We resell some hardware components from other companies as part of our overall solution. We frequently have installers that don't understand electricity wiring up these components. As you might guess, they often fry the components by wiring them incorrectly. What's an installer to do? They can just return it to us, claim it never worked, and get a free replacement shipped to them overnight.

We then spend more time testing the returned equipment to verify that it is ruined. If we don't have time to test it, we throw it in a bin of test equipment for our QA department to use. Inevitably, they grab the damaged equipment, things don't work, then they report bugs on the software. The developers then spend time chasing non-existent bugs. It's all very well planned from the perspective of wasting money.

Sell It, Then Make It

The other way we screw ourselves is that our sales people promise customers that our product will do anything and everything (who doesn't have that problem?). On the rare occasions that they close a sale we're then on the hook for implementing something that didn't previously exist (for free of course). And, since it's already been sold, the time line for implementation and testing (ha! testing...) is extremely short. Finally, it's often a feature that no one else cares about. But, once it's in the product, it costs us money in terms of code complexity, maintenance, and testing time. It also prevents the developers from implementing features that a larger group of people want, which could theoretically increase the product's ability to compete long term. It's sweet, sweet genius.

Sustaining This Model

How can we afford to keep doing things this way? You might be tempted to think that we make it up in volume, but you'd be wrong. We usually just find a way to dupe investors into giving us more money. This is usually sold to them on the "Amazon Land Grab" model where you spend a lot of money to be the first business into a relatively virgin market. You build your customer base so large, so quickly, that it becomes very difficult for people to compete. Then, you crank up the profit machine and hire people to count your money.

The problem is we're not Amazon (those guys are smart), it's not virgin territory, and there's not enough money in the industry currently for us to make up the amounts of money we're wasting. Sometimes investors still fall for it. But, what happens when they get tired of giving you money? We'll talk about that next time.

Who Wants Some Popcorn?

I've mentioned Ike the sales guy before: "We'll call this sales guy Ike because 'Ike' has one good 'I', much like the sales guy." Upon further reflection and discussion, I think I have to rename this guy "Popcorn" because his mind works kind of like a bag of microwave popcorn. Nothing. Nothing. Then suddenly, a pop here, a pop there and then a flurry of activity. "Okay, now that that's done--Pop! Pop!" And then back to nothing. It's next to impossible to have a discussion with him in the room. For example, I decided to put up a PHP based content management system for internal discussions and such. For the next week Popcorn would randomly say "PHP-Nuke!" several times a day.

Our product integrates with some third party software that keeps track of some hospital related stuff. Let's say it's prescription history. This prescription history software uses an Access "database" to store its data. I don't consider Access a real database, that's why it's in quotes. We integrate by creating a view of some integration table in their Access install. The whole thing is very ill conceived and brittle. The version of the product that we integrate with supports exactly one station for updating and viewing this prescription information.

Our sales manager, that frequently hangs us out to dry and injects last minute requirements into upcoming releases, sells an install of our product that will integrate with the latest version of this prescription history software that supports multiple stations. He is, on some level, aware that we need a new version of the third party software so he orders a copy. Trent then schedules Popcorn to head out to the customer site four weeks later to make the install work. He apparently feels this is the end of his responsibility on the matter. Popcorn sits on this information for three weeks while the microwave heats up his idea factory.

Finally, a week before the install date, Popcorn mentions to one of the developers that he's planning on dropping this new, untested version of third party software into a new install. He holds the ignorantly optimistic view that it should "just work." The developer expressed some concern since it sounded like the third party software may have changed a bit. It may also have been several major versions of theirs since we used this integration feature. "*pop* *pop* Yeah, I'll probably try it out here first *pop*." The Friday before he flies out we ask him how the test went. "*pop* Oh, I haven't tested it. It shouldn't be any different. PHP-Nuke!!!"

He is once again warned about the fact that the developers all feel that it is a significant risk. "I agree," he says. "I'll probably try it out this weekend just to be sure." Well, he goes the weekend without trying it out, flies out to the customer site on Sunday and begins the install on Monday morning. Tuesday afternoon the developer gets a call on his cell phone. It's Popcorn. "Hey man, this shit doesn't work." The developer starts asking some questions about what's going on with the install and Popcorn hangs up on him. Thirty minutes later Popcorn calls back. "Do you guys have any ideas?" You can practically hear his little bag a-poppin'.

Again, the developer tries to get information from him and is hung up on. The next time Popcorn calls back we ask him what the hell is going on. "Sorry dude. The customer keeps coming into the server room so I'm hanging up so they don't think anything is wrong. You know what? Don't worry about it. I think I can get it working."

The next day we're in the middle of a department meeting when Trent bursts into the room and says, "Hey, this new install with the prescription history integration is blowing up all over the place. They're threatening to cancel the deal and rip all of our stuff out if we don't get it working by tomorrow." Given the circumstances I express to him the very real possibility that this won't be fixed by tomorrow and that he should begin thinking about alternatives. "Sorry guys, but we don't have an option on this one. We need to get this working. The whole deal is riding on this. We're painted into a corner," he says. You know, it'd be a little easier to take shit like this if 1) we ever learned from "our" mistakes, 2) we took risks seriously ahead of time, and 3) the person saying we were painted into a corner didn't have a wet paint brush still in his hand.

The development department breaks up the meeting, gets a copy of the new software, and begins to try and figure out what's going on with it. We get to the point that we've duplicated the problem when Popcorn calls again. "Any progress?" he asks. We tell him the situation so far when he tells us that he's gotten a patch from the third party and he thinks it fixed everything. We should "stand down" whatever the fuck that means. Trent tells us that he wants us to keep working on the solution. We can't seem to get the patch out of Popcorn but that shouldn't matter since he thinks it "just started working." The next morning we get another call from Popcorn asking how we're doing with the patch that he still hasn't given us. "It's still broken here, but I think this third patch is going to work." Since none of us locally have the first patch, aren't aware of a second patch, and obviously know nothing about the third patch we're all pretty much just watching the train wreck at this point.

Sadly (on some level), the third patch does indeed seem to fix the problem. This is the least satisfying resolution to the problem from my standpoint. Once again, the sales people chased a sale and their commission without thinking. They sold us into an install that we weren't prepared for. They didn't take the QA process seriously since in their mind our product hadn't changed. The sales guys didn't bother using their ample lead time of four weeks to try and resolve any of the issues, with or without development help. Then things blew up, we became a "team" and lucked out on the resolution. All this means is that from their viewpoint it was a success. Let's do it again on the next one. Yay.

In the aftermath the dev manager, Fredo, said that Trent felt really bad. Since I was feeling particularly mouthy I said, "Unless he feels bad because he's been fired and he's come to the realization that he doesn't have a sufficient skill set to get another job then I don't particularly care." Fredo is one of those managers that likes everyone drinking healthy doses of the Kool-Aid so I'm sure he didn't particularly like it. Luckily enough for him though he was able to read my not so subtle hints and keep his mouth shut about the matter. PHP-Nuke!