First, I just wanted to say that I didn't realize I had blogger set so that I had to manually approve comments, so the few comments I've had now show up, sorry about that, I wasn't censoring anyone and appreciate the feedback!

Today I wanted to talk about the most important aspect of having a successful product (again IMO). Joel and Google and other newer technology companies have been spreading a lot of rhetoric that if one simply hires the best programmers, they will get the best product and thus the best profit. You can probably look at either of those companies now and think, well they are doing pretty well, so maybe they are right. But was it the developers that made FogCreek the sucess it is today? No. I'm certainly that at least through the first couple of versions of FogBugz no one had any clue how well written or how great the software was. They bought it because they heard it from Joel. Joel writes great articles, people read them, and when he comes out with an idea, be it City Desk or CoPilot, his followers will try it out because he recommended it. Maybe they simply weren't aware of any bug tracking software before they read his articles, but when you have a readership like Joel does, anything you recommend will be taken like advice from a friend. The sucess of FogBugz is almost entirely related to the sucess of Joel's blog. Sure, it has now reached a critical mass where people will stumble upon FogCreek because it has such a high PageRank, but if it weren't for Joel's blog, it would have just gotten lost in the sea of Bug Trackers that are out there.

What's my point? The point is that especially when you are starting out, the software itself is often the LEAST important part of the equation. I've seen people make some pretty impressive products and business ideas in the past, spend months working on them, and then simply put them on the web and wait. And wait. And wait. And then give up. Sometimes maybe they will spend a few bucks on AdWords. You could take every PhD at Google and create the best Bug Tracker around, and I promise you if you simply stuck it on the web and paid for a few AdWords, it would never get as many sales as FogBugz. The absolute number one most important thing when starting a new business is figuring out HOW you will get the word about your product out there. You should be thinking about this the whole time. You can produce the best software ever, and if no one has ever hears of it, it might as well not exist.

Ok, so how does one get the word out? Is purchasing a few AdWords the best and only way? Perhaps AdWords will get you a few sales, but frankly when I search for software on Google, the ones that come up at the top of the search results seem more legit to me then the ones on the sidebar. I would be more inclined to dole out my hard earned money to someone that Google trusts then someone who paid for an ad. Often in my previous IT jobs, we have purchased software from companies that was inferior to something we could buy elsewhere. Why did we buy them? Because the boss had some relationship with the other company. This is the absolute best way to sell your product. A recommendation from a friend. Many people I know won't buy anything computer related without asking me what I think of it first. I could tell them to buy the most expensive piece of junk out there, and that recommendation would carry more weight then a superior company's million dollar ad during the SuperBowl.

"So how does one get these recomendations?" you say. "I'm making software for nuclear engineers, I can't exactly get my mom to plug this to the neighbors". Good point. It is a very hard process to get that ball of trust in your company rolling. FogBugz and Google did not have the usership they have today over night.

There are several things we are trying. First, you really need users of your product to try it out, and get you feedback. This is a great time to get them hooked on your product and give recommendations. As hard as it may be, you should really give a couple copies of your software away. Perhaps find a user that would be less likely to buy it in the first place, find people who's recommendation will mean something. See how they like your program. This is now where the QUALITY of your program comes into play. If the original users of FogBugz had purchased it on Joel's recommendation but it sucked, both the product and the recommender themselves would lose credibility. While I am of the belief that given the correct marketing you can sell the crappiest product out there, it will probably cost you considerably more in support and public image then spending the time creating a great product in the first place. The Chimney Sweeps we have let us our program all have a similar reaction..."Wow!". This is what you want. I promise you a "wow" will result in sales. Seeing their collegues not carrying around maps, equipment and messy forms anymore means a great deal more then some ads with Google.

Recommendations are good for a localized area, but these will spread out very slowly. In many ways this is good. Why did many .bombs fail? They would put an ad out there on the Super Bowl, people would flood the site, it would crash, or the product just wasnt ready for prime time and people were left with bad impressions. You WANT your userbase to grow slowly. Get feedback while its managable. Give great customer service.

I'll continue with more ideas for marketing in other posts, but if you are not worrying about this already, you should start thinking of a comprehensive plan for proactive marketing now.

Sorry for the lack of post this week, I'm trying to make it my goal to post at least one thing each week. We are currently very busy trying to tie up all our loose ends, complete initial partner negotiations, and get all setup for our first trade show.

I'll write a more complete post about this later, but for now I'll say our first trade show is the All Fuels Expo and Chimney Sweep Convention in Mystic, CT January 25th-28th. Mike Morris, of RecDesk has had some great advice for trade show setups, and we are taking some of his hints.

We also technically begin selling the 1.0 software on January 1st. I've posted a bunch of screenshots of the program, if you're interested head on over to http://www.ChimSoft.com.

So the first question you probably asked when you heard about this software was "Why do Chimney Sweeps need software?". Thats a good question, and the answer is, "they dont". Yes, you heard me, obviously chimney sweeps have been doing their thing for a long time without software, and can continue to without buying ChimSoft. But before you put that checkbook away chimney sweeps, remember that typesetters didn't "need" a word processor. Accountants didn't "need" a spreadsheet program. Sure everything can be done manually, but think of what a performance improvement those applications brought to the business world. In that same sense, I believe our product can bring service professionals (and specifically chimney sweeps) that same leap in productivity.

There are four key features of our program that I believe on their own would be worth their weight in gold to a chimney sweep.

1) Customer Database
2) Electronic Inspections and Estimates
3) Mapping
4) ChimScan integration

Right now, if you're a chimney sweep, you probably have a big filing cabinet of people that have called you in the past for a sweeping. If someone called you today and asked when the last time they were swept was, you'd have to manually thumb through all kinds of paperwork, perhaps looking at some old carbon paper chimney inspections, and hoping you have it. You have no way of easily finding out when someone had their last sweeping. With ChimSoft, a sweep can pull up a customer's entire history with one click. If a customer calls, you can amaze them by bringing up estimate information, detailed chimney sweeps, and notes of past conversations instantly, while they are on the phone. Second, you can generate new business by running our report that tells who hasn't had a sweeping in a certain amount of time, then simply mail out reminders to those people. This feature alone would bring in enough business to pay for our program.

The next key thing is electronic inspections and estimates. Right now, most chimney sweeps walk around with a carbon paper pad for inspections. They then hand write up an estimate and give it to the customer. Doing all the math in their head, or sometimes going back home and typing up a pretty estimate. With ChimSoft a person can have a custom estimate, with their logo, and print it out right there and then. They can even find the price of a part from their vendor (if their vendor is one of our partners) without flipping through some huge catalog. And best of all, these estimates don't just get lost, ChimSoft keeps you up to date on that status of all your estimates, so you can follow up with a customer to make sure you win the job. They can do all their jobs quicker, allowing more jobs in a single day, and making more money.

Mapping. This is perhaps a field tech's favorite feature. With ChimSoft you can set up your entire day's route, and simply pull up customer's addresses from the database in one click, and map your entire day. Getting turn by turn directions means no more getting lost. You don't need to carry a hundred printouts from MapQuest and spend hours typing in each person's address. You can also use the mapping data to determine where your customers are and are not, and target your advertising dollars more effectively. Both these features will allow you to fit in more jobs, make more money, and find new ways to maximize your revenue.

ChimScan Integration. Chimney Sweeps these days are more high tech then most people remember from Mary Poppins. Many Chimney Sweeps have found there is big money in scanning your chimney for cracks and faults that are impossible to see with old fashioned techniques. They have a high tech device called the ChimScan. While this is a fairly high tech setup, currently they still need carry around a large box with a VCR, a TV, and a breakout box in it. Once scanning, there is only one option, watch on the smallish TV, and record to a tape. With ChimSoft, sweeps can use the same equipment they already have, but take that VCR and TV out of the box completely. Now they can view their scans in high resolution on their laptop. They can pause the video stream to point out important details to customers, and best of all they save a digital copy of the video, and associate it with the customer's record. Insurance companies now get a crystal clear DVD quality scan if repairs are needed. And no need to hold on to video tapes for years, you can pull up an old scan in 2 clicks.

There are many more features I can go into eventually, but the point of this post is that almost no one NEEDS your software. You need to add the value that will convince them to buy it.

I believe there are basically three types of people in the world. Those that are freespirit artists, those that are extremely logical, and the rest of the world. Notice I leave very little room for artists and logic people to overlap. Which is why you can probably imagine that I disagree with Paul Graham's "Hackers and Painters" philosophy. I'm sure there are definitely a handful of people that are good with both art and logic, but I havn't met one yet. Well, I fall squarely into the logic category. I can program, I can diagnose whats wrong with your car, I can fix electrical things and set a VCR. I can't draw a stick figure straight, let alone anything fancy. I actually wanted to be an artist when I was a kid, but if you've ever seen anything I've drawn you will know that was a career destined for failure. Why do I bring this up? Well event though small businesses owners tend to want to do everything themselves, sometimes you have to outsource. No, not to India, but to another company or person that has a talent you are lacking.

It's been said many times that if given a choice, a customer will buy a product that looks graphically impressive but only has 10% of the functionality any day over a program that looks thrown together but has 90% of the functionality. So looks are VERY important to most people. Especially non-technical types. We programmers tend to write very bland looking things. Google is a good example. However, it's sucess is the exception, not the norm for such a thing. I believe SearTech has both high functionality and decent looks (I've consulted with two art friends heavily during it's design).

So to make a long story short, recently we had a logo designed professionally. We chose Logo Design Creation since they were highly recommended in Wired. Their portfolio looked decent and they promised a 72 hour turnaround (!!) which I didn't need but certainly wanted to see. The good thing is that they are very impressive art wise. When they send you their ideas, they send three concepts, which you can pick one to tweak a bunch (all for only $50). All the concepts were decent, but there was one that stood out amoung them all. The bad thing was the sucess from Wired has them EXTREMELY backed up. It doesn't mention this anywhere on their website during the order process, but if you go to the contact them area, they are offering refunds and explaining the delay. Instead of 72 hours, it took about 30 days for me to receive my initial logos. I contacted them after about 8 days and they claimed email server problems. That certainly may have been the case, but if you're backed up, just be honest guys! Anyways, for the price they do really good work, and I would recommend them if you are not in a rush (or maybe wait a couple months for the hype to die down). Here is what we ended up going with:



Let me know what you think. A logo is worth getting done professionally. It will be the on the front line of your corporate identity.

So how should one go about choosing the correct tool for their project (programming language, runtime, etc...). When creating my product, these are the things I considered:

- My familiarity with the language
- Will it run on Windows?
- Availability of components, librarys and online help.
- Is a runtime necessary and how many people have it?
- Most flexible

Things I did NOT consider:

- Is the language "manly" enough
- Is the language popular

Software development is perhaps the one industry where using the tool that is easiest is looked down upon. I have heard time and time again people using C# over Visual Basic .NET, because its "more techy" or "not as embarassing". I've heard similar arguments about using LISP over perl, or C++ over Java. People that use the "easiest" tool often get mocked and get into holy wars with other developers. Can you imagine a similar argument in any other profession? "Dude, you use an jackhammer? Everyone knows REAL construction people use thier bare hands". Maybe you see where i'm going with this. Yes, this program was largely written in Visual Basic .NET. I'm proud to say it, because even though I know and use C#, Java, perl, and C++, I can develop 100 times faster in VB .NET.

Your end user has no idea what you created your program in. Even if you use something more exotic on the windows platform like perl or java, 98% of people will not know. Currently on the web there is an "Ajax revolution", where everyone is trying to integrate AJAX into their app. Go show that to some non-techy sometime... you know what they'll say? "I've seen things that are much cooler then this like 5 years ago, flash something or other".

So what finally led me to develop this in VB .NET? (it's also maybe 20% C#) #1 reason was familiarity and speed. Before discovering .NET, I had written all my windows apps in C++. It took me about two weeks to write a snazy Blackjack program in C++ a few years ago. How long would that same program take in C#? Probably about 4 hours. Visual Basic .NET? 3 hours. While it took quite a lot to get used to Visual Basic being so "friendly" (it still feels dirty not putting semi colons after each line), in the end, it plays much nicer with the IDE then C#.

Now, a lot of people will take their decision for a programming language and deride what anyone else does. I will not. If you can develop apps faster and better in Java or Perl go for it. The only time I believe actual language matters is when writing something Open Source. If you use a popular language you're more likely to get more people working on it. Otherwise, it does not matter.

One thing that is a major negative of "easier" languages is the runtime required. This is a big concern to any .NET developers. From my own completely unscientific research approximately 70% of Windows users have some version of .NET installed. Perhaps 50% have JRE installed, and maybe 2% have ActivePerl installed. This gives non-runtime languages like VB6 and C++ a huge advantage. No large runtime to install. If you are offering a program that is only distrubuted over the web (say a solitare program), C++ or VB6 is probably a good bet, because people won't want to download a 25MB runtime to run your 600KB program. The plan for SearTech though is to distribute our app 99% of the time by physical CD. This may seem old school, but one of the things we are stressing is a high value, personal relationship with the customer. We don't plan on selling more then 10-20 copies our first year, so every one will matter. A huge impersonal download goes against our current thinking. Giving a CD means we also don't really need to worry about the runtimes. Getting a .NET program to run on a fresh install of Windows 98 requires quite a lot of extra things. They all fit nicely on one CD.

By the way.... I meant to mention this in my original post. I don't claim to be an expert. Much of the stuff you'll see here will come off as advice from "on high". Its not. It's just my advice based on my own experience. I don't believe there is any one way to do things to be sucessful. However, people seem to love to follow the advice of people on the internet, so here it tis if your interested in following my model, and I enjoy writing. I also will not spend much time editing and revising these posts. Yes, my grammar and spelling sucks. I'm not an english major, i'm a programmer :).

And it began.... After our initial talks about the product, we got together for a big requirements gathering. Since the first version would be targeted primarily at Chimney Sweeps, I asked of our Chimney Sweep what he would want....what he would need. This was in January. I, like most people today want INSTANT results. I figured I could put together what he was asking for in 2 weeks (Using .NET), since I my AutoShop program already had much of the basic functionality he was requesting. I figured we could test it for a month and begin selling a month later. I set an initial target date of March 1st because there was a chimney sweep convention mid-march that we could sell it to. Well... it didn't quite work out that way, and boy am I glad. While I did have a functioning "1.0" product, the quality of which was similar to many things I see "just being put out there" by developers these days, it didn't go out. Compared to the 1.0 we are actually releasing next month, I feel much better about the product we are selling now. It has lots of "wow" features, and is as good as some of our competitors 5th or 6th versions.

First impressions mean everything. Perhaps if we had gotten our 1.0 out the door last year we would have made a sale or two. But I think most people would have been highly unimpressed with our product, and we still probably would have made the same changes we have in there today, so people would have constantly have been updating. Constant updates on a web app are no big deal, it doesn't require much from the user. But users do NOT want to update their software frequently, if ever, on the desktop. Techies like updating, or at least don't mind it, because its like getting the newest model of a car for free. But non-techies (whom our customers mostly consist of) just want the software to work out of the box. If it doesn't work like they expect the first time, they will not purchase from you again, and assume all future versions are similarly bad. I also go by that line of thinking. Netscape 4.7 and early 6.0 were so terrible, that even though the new Netscape is essentially Firefox, I refuse to try it because I assume its nothing but slow, buggy junk.

When you release desktop software, assume its impossible to get someone to update their software. That means you can not be casual about small bugs...everything must work from 1.0. Thats the next lesson... always get a wide variety of people to test your product. What is intuitive to one person may be completely incomprehensible to the next. It never ceases to amaze me how after weeks and months of usability testing, how a new user can find something or point something out that we missed in all other rounds. Also be sure to test on a variety of computers. Using Virtual PC or VmWare is not good enough. I tested our later betas on every Windows OS using Virtual PC, and it worked with flying colors. (Well Win98 pointed out a couple things that needed to be tweaked) But low and behold, on Win XP computers running Novell, a new bug appeared. A bug that would not appear anywhere else, but made the product almost not work at all in Novell. Users will have computers loaded with spyware and viruses, they will have AMD's, they will have low ram, low hard drive. Each of these situations can present unique problems that YOU will be blamed for. "This program runs slow", could mean their computer has never been defraged and is filled with spyware. But the user does not know this. That is one reason we encourage our customers to buy PC's from us. Selling PC's and laptops is a low margin, high frustration business. If I had my choice, I wouldn't mess with the hassle, but it is more important to us that our customers have the best experience possible.

So in conclusion, don't rush things. Take your time. As Eric Sink says, we are craftsmen. It is absolutely worth spending the time to polish and perfect your application, because you never know what little problem or feature is the difference between a sale and a return.

Well after much debate I decided to finally launch a blog about my software I've been working on this past year, and about the development process behind it and the business lessons learned. Since this is an introduction, I'll try to keep it brief, but I have a tendancy to ramble and rant.

First about me. I continue to work a full time job, and did not wish to quit to work "fulltime" on this project. Some people choose this route, but I was in no rush to get this business going. I'm not trying to get some Web 2.0 tech out the door before someone beats me to it, I'm not trying to get something to sell to Google, and I like my job. So no rush. I've attempted to create quite a few software products in the past, but most of them ended up being half finished. For example, I have a Bug Tracker that is neat...but not awesome: http://2see.com . But I have a huge interest in business, running a company, competing, and designing software. I am a hard core believer in automation.

Now about the company, and product. Last year around this time, i had finished one of my half-finished ideas...it was a Auto Shop management software, so mechanics could check in cars, give people auto maintenance histories etc. I showed it to one of my friends, and he thought it was neat, but I never tried to sell it, and kind of moved on to other things. Well two weeks later, the same friend calls me back and says another mutual friend had an idea. He was a Chimney Sweep and really needed some software to manage and run his business. Lets talk I said...

Well we got together, discussed the specifics, and after looking at the market, realized this might be something that others could use. The product we came up with would be generic enough to work with almost every service industry (HVAC, Plumbers, etc), but have specific plug-ins and value adds for each specific area we would target each time (The first people targeted will be Chimney Sweeps). And so our company was started. How we came up with the name and some other things will be discussed later, but for now the website (yes its a cheesy template) is http://www.SearTech.com

Since I am publishing this blog AFTER I've done most of the development (the release candidate for 1.0 is going to testers today, and the final product will be on sale Jan 1st), the next couple of posts will be about the development process, the business process, and more details about everything in between. Plus come January you get to start hearing about how we do at conventions, mail marketing etc. So stay tuned.