starting a micro isv in the beginning there was nothing

This essay is inspired by a post by Kevin Dangoor, which in turn was inspired by a post on, which was inspired by an article by Eric Sink!

The current hub bub in the ISV (independent software vendor) world right now is transparency and Kevin paid me a very nice complement by noting my attempts to be fairly transparent in the startup of my company, UserScape.

This then got me thinking a bit about what I’m doing and if I might be able to codify some of it for the benefit of all. I don’t think I’m doing anything special per se, but in my short time going at this I’ve picked up a few items which may be useful to others. Let me disclaim myself here by saying that none of this is really proven to work! What I have is anecdotal evidence and if you stick around awhile I plan to write up some updates as time goes along.

In the beginning there was nothing: aka where to start

A big question I’ve already emailed with a few folks about is where to start. The answer to this is always start before you think you need to. Huh? What I mean is that I “started” almost 2 years ago by reading everything I could about starting a small software company. Reading as many ISV weblogs as you can is extremely important. It’s just about the only place you can get a good in the trenches view on things. Back then there was no, technorati, feedster etc. so I foraged for what I wanted. You have those tools now so use them effectively.

Some of the stronger influences on me include Joel Spolsky, Brent Simmons, Dave Winer, and Eric Sink among others. I also think it’s very important to note Seth Godin as well. His books have had a huge influence on me. If you’ve never read Purple Cow run to amazon right now and get it.

Don’t just read them, understand them. Think about how it’s going to relate to you. See where they’ve made errors and learn from them. Make sure to note the things which have worked for them. Try as hard as you can not to reinvent the wheel. These people are out there giving you in depth details on their experiences, use that to your advantage. It means you may be able to avoid a few of the unavoidable pitfalls.

Pick your poison

How to choose a market to enter could be an essay all it’s own. To keep it short here are a few things that led me into the help desk software market.

1. I’ve managed help desks for both software products and services. Having strong knowledge of the domain is extremely important. That doesn’t necessarily mean you’ve worked in the area, but you definitely need to be sure you know your stuff or you are going to build something people don’t want.

2. I didn’t want to invent a new type of product. I think this is where alot of ISV’s go wrong. It takes alot of money to explain to someone why they need something they have never heard of. Sure you could get lucky and create something very viral that takes off, but you’re stacking the odds against yourself.

JotSpot comes to mind here. I’m sure it’s a fine product but hardly anyone knows what a wiki is much less an application wiki. Search Google for wiki and you get 4 ads. Try application wiki and you get 0, not even JotSpot themselves. They have some $ so they’ll probably be ok but most small ISV’s don’t. You don’t want to start behind the 8 ball.

On the other hand, help desk software is a very established market. People know what it is and why they want it. Do a Google search for it and you get 10+ pages of ads. That companies are advertising heavily for it is strong evidence that people are buying it.

(of course I’ve oversimplified things with these searches but you get the idea)

3. Joel didn’t invent bug tracking software
37Signals didn’t invent project management software
Eric Sink didn’t invent source control software
Microsoft didn’t invent the word processor or the spreadsheet

The question is do you have fresh ideas you can bring to the table. Pick a market with stagnation. Take a look at the help desk software market and you’ll see a bunch of websites and products that for the most part haven’t been updated in years.

When it comes to innovation you can probably move faster than the current market leaders. In most cases their slower pace and existing customer base preclude them from making radical changes in their products. That’s your big advantage as the newcomer to the market. Keep what works from the old models and innovate on that.

Get your money straight

Every situation is different so advice on money can be hard to give. All I would say is be realistic. Thinking you can do everything on the cheap and startup for $500 is not the case.

So you’ve started thinking about starting. What next?

Get a blog. It’s that simple. I really can’t express how much this simple act has done for me. It’s opened up many doors and is already providing me leads on a software product that won’t even be released for at least 3-4 months.

It’s scary I know. You’re going to make a fool of yourself. You’re going to post things with misspellings. You’re going to create sentences that sound like a 7th grader wrote them, and your readers will love you for it. Be open, be honest, be real.

Blogs are all about amplification. You can only reach X people, no matter how hard you try (well with your budget anyway 🙂 ). Bloggers help you amplify your message. If you write good stuff (interesting, useful, etc) other people are going to point to you and those “old time” bloggers have alot of readers. That gets your message out and those readers they drive to you post on their own blogs and on and on. Basically if you are starting a small ISV you can’t afford to not blog.

Blog early. Don’t start a blog the day your product launches. You need to be building interest in your blog and your product long before it launches otherwise you’ll be spending the first 6 months after your products out trying to build those connections.

Don’t be scared that you have nothing to sell yet. It’s not about that. It’s about building relationships with the sneezers, it’s about building relationships with other bloggers in your market, it’s about learning how to effectively communicate with the market you are trying to reach. If you have people contacting you about how to get your product then you know you are on the right path. It’s going to pay off later.

OK I’m signed up with Typepad, now what?

So you’ve got your blog up and running several months ahead of your launch. You’re building interest, people are starting to occasionally link back to you and comment on your blog. You need a mailing list.

You need one because right now you have no idea about how many of your readers are simply interested parties (remember these people are very important don’t discount them!) and how many are potential customers (super duper important). A mailing list helps you understand how many people are interested enough in your product to give you permission to contact them further about it.

I know what you’re thinking. You can’t remember the last time you signed up for a mailing list on a product. Me either! But I can tell you from experience that other people do, A shocking number of them. These folks are very important for a number of reasons.

  1. If you can keep even a fraction of them interested in your product, then you might have a nice little group of purchasers right at your product launch. That’s a very nice thing.

  2. They are a great indicator of how well what you’re writing is doing and what types of postings/articles drive the most potential customers to you. Once you have this information it makes targeting that market much easier.

  3. They provide what I call “little bits of encouragement”. You’ll find yourself refreshing your mailing list subscriber page several times a day and every time that number jumps up by one or two it really really lifts you up. Somebody is interested in what you are working on. This really helps through the low points when you’re working on that really terrible administrative page that’s boring you to death.

Don’t be cheap! You probably need to use a hosted mailing list service. It’s not just about sending out emails. You want reporting on how many people received the mailing, how many opened it, how many bounced back, how many clicked a link in the mailing, etc. This reporting is vital in gauging the success of your campaign.

Get designed

I already wrote one article on logo design and I’ll have another shortly on website template design so I won’t harp on it too much here, but you need a professional designer. You need to get your logo’s, website templates, and interface designed by a professional who understands color combinations, fonts, etc. If you don’t look professional you aren’t professional.

Wrap Up

So that’s where I’m at right now. Hopefully you’ve found some of it useful. If you have your own experiences or questions, I’d love to hear them in the comments below.

What I thought I’d leave you with is information on some of the applications and services I have found useful throughout this process.

  • – A great place to find information on the ISV industry

  • – I do have my own log analysis software but StatCounter is great for quickly checking out where people are coming from. It’s real time and free!

  • CampaignMonitor – Makes it easy to run a mailing list. Very good reporting and very good pricing compared to other hosted mailing list services.

  • WordPress – Good self hosted weblog tool

  • TypePad – Nice hosted weblog tool

  • – Email hosting service. I’ve used them for about 3 years with 0 down time.


There’s an

interesting article over on about XMLHttpRequest. That’s the javascript object which makes it possible to communicate with the server from a webpage without the page refreshing.

Its most prominent use currently is with Google Suggest. There are several places in HelpSpot where this technology would be a great use. It could potentially make parts of the system like the inbound request queue extremely dynamic and completely real time.

My hesitation in using this is that unlike Google’s use of the technology, mine is part of a larger system. In Google’s case the technology is used on the one form the site has. In HelpSpot there are many many forms, data tables, etc. In most parts of the system using XMLHttpRequest would make no sense. So the question is does the benefits of using it in a few parts of HelpSpot outweigh the significant downside of creating alternate user experiences in different parts of the same application?

I don’t know.

functional specs to do or not to do

OK I really have an entire essay I’d like to write on this, but I’m already working on another and don’t have time so I’ll just throw this out there. I read this on the Signal vs Noise blog yesterday and it kinda blew my mind:

*”Don’t write a functional specifications document. Why? Well, there is nothing functional about a functional specifications document.

Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different. This inevitably comes out in the future when it’s too late. “Wait, that’s not what I had in mind…” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it – you even signed off on it.” You know the drill.

Functional specifications document are “yes documents.” They’re political. They’re all about getting to “yes” and we think the goal up front should be getting to “no.” Functional specs lead to scope creep from the very start. There’s very little cost in saying “yeah, ok, let’s add that” to a Word document.”*

The main part I find striking about this is how much it contrasts with the Joel Spolsky method, which I’ve used in the past:

“Software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.”

Doesn’t really get more far apart than that. Since the SvN guys seem to be more in the design realm and Joel is a Microsoft guy perhaps there vastly different viewpoints make sense? I’m going to have to think about this a bit more.

Personally I tend to write short specs. I exclusively use an outliner for this process. I think it’s much more productive to be able to open and close parts of the spec than have a big scrolling Word doc to deal with.

helpspot mailing list

Last night I sent out the latest edition of the HelpSpot mailing list newsletter. Features I covered in the newsletter included:

  • Our innovative customer satisfaction survey

  • Private help desk communication tools

  • Web services integration in HelpSpot

If your interested in HelpSpot and want to learn more you can sign up here. I plan to send out a newsletter about once a month over the next few months. As we approach the beta test period I’ll send them a bit more frequently.


Another great article by Eric Sink over on MSDN: Tenets of Transparency

I think UserScape should score pretty high on this checklist. Your reading #1 right now 🙂

HelpSpot will be able to help other ISV’s with #2 and #3

Great stuff. I’m excited to get our demo rolling. I think having a timed demo is going to be a big key to our success. Once potential customers see how easy managing their support requests are and the power of the integrated self service features they’ll be won over.

a bad help desk experience gets blogged about

It’s so important to have good help desk interactions with your customers. Why? Because the bad ones get blogged about. Alan has a typical post about a poor experience with his corporate help desk.

Many of the frustrating aspects of his experience are directly related to his organizations help desk software. Let’s break it down point by point and see how HelpSpot handles these situations.

  1. No part of the customer facing help desk should have any “weird” requirements that may interfere with the customer experience. In this case odd javascript which prevented him from entering his request from a Mac. I would also say there was a second problem here because the reason for the javascript is to do an LDAP lookup and fill in the rest of the users information. None of that system integration should be on the customer facing end of the software. Simply ask for a name and email or an employee id if available. That’s it! You can do additional lookups later if necessary behind the scenes.

HelpSpot makes it easy to enter requests via the web or by integrating with one or multiple email accounts. All your customers need to do is email in a support request and a ticket is created automatically.

  1. If you need to ask for browser information ask it in a drop down select list of browser types, don’t get fancy and try to figure it out by the browser the user is currently using. Maybe they’re using a different computer, perhaps the error is with their main browser, in any event don’t try and guess just ask.

Provide a good user interface for the user. They are reporting their problems here, having a tiny little text box implies that you don’t care and you just want them to keep it short.

HelpSpot lets you create custom fields so you can ask any type of information you need to that’s specific to your desk. We’ve spent countless hours working on our user interface to make sure your customers don’t feel frustrated with the experience.

  1. Make a special category for security issues and have them route directly to the person who needs to know. The user shouldn’t have to know who this is and go out of their way to notify them.

HelpSpot lets you automatically assign incoming requests for a category to a particular user so that it’s routed to them as fast as possible without even stopping at the help desk.

  1. OK this is good! The user should get an email with the ticket number and in HelpSpot’s case they’ll also get a one time use, unique password they can use to check the status of their request on the web.

Look for a future article I’m writing about how we handle customer access to request information

5,6,7,8. Here we have the standard breakdown in communication. Most likely the help desk didn’t know the right person to contact or had to work outside the help desk software to contact them. Since that puts the help desk out of the loop nobody follows up with the customer and frustration sets in.

*HelpSpot addresses this issue by encouraging every “level 2” support person to be part of the system. Licenses in HelpSpot for level 2 support people will be cheap so their’s no excuse not to include every user who needs to be in the system, in the system.

In a HelpSpot installation the request should go something like this:

  1. Customer fills out simple web based form or sends an email to [email protected]

  2. If the category of inquiry has a user assigned to it the request gets assigned directly to them (skip down to #4) if not the request goes into the help desk queue.

  3. A help desk team member assigns the request to the correct level 2 user. In this case someone who can change the Unix permissions.

  4. That user is notified automatically by the system since they have an account in HelpSpot.

  5. The level 2 user sees the request come in and makes the change in 2 minutes. Marks the request as resolved and closed and the customer is notified.


jeeves purchases bloglines a different take

For those unaware, the news broke today about

Ask Jeeves purchasing Bloglines. There are some good posts by Mary Hodder and Russell Beattie on it.

What nobody has really talked much about though is what’s going to happen to Mark Fletcher, the creator of Bloglines. Mary assumes he’ll be an Ask employee “Mark Fletcher will be their newest employee starting Monday”. I hope he isn’t.

I’ve had some personal experience as a member of a very small company that was purchased by a large one. It’s great of course for the owner and it’s basically “the dream” of most people who start a small web business. I’m all for it.

What I’m really talking about is that once you sell your company, especially a small one, it’s not yours anymore (duh). That leads to big problems because all those great features you added in an afternoon before now go through 15 committees and take 6 months to implement. All the personal relationships you built with the community by being open about your business … gone behind a shield of NDA’s. The nice simple interface …. replaced by giant “search Jeeves” buttons everywhere. It goes on and on.

So for Mark’s sake I hope he took a little less money and hands the keys over to The Man and walks away.

Creating a Business Logo

So you want to be in business? You need a logo! This article documents the process I went through to create the logo’s for UserScape (the company) and HelpSpot (our new help desk software). Hopefully this can provide some guidance for future ISV’s on how the process goes.

The first step was contacting Mike Rohde of MakaluMedia. I found him via the NSLog weblog, which was having a design contest that Mike won. While everyone may not be able to get this lucky and find a great designer by accident, I do encourage you to look through the weblog world for one. Many many designers have blogs and it’s a great way to see what a designer is about. Usually they’ll have samples on their site, but more important is that you can go back through their blog and get a feel for how they work, their style and so on all without a lot of phone calls, emails and general back and forth.

Once I contacted Mike we went over my business plans, what sites I admire and the general feel I was looking for. Mainly I was looking for something modern, but I explicitly did not go into any great details. I prefer to let the designer come up with a variety of options first with only rough guidance. I find this usually works the best as they’ll often take the design in a direction you haven’t thought of. Remember you’re no designer! Let them go and be free to create beautiful images, your job is to rope them in when they go too far and keep the process moving in the right direction.

Mike is the first designer I worked with who does all his conceptual drawings on actual paper (fancy that). Below are the first sketches he sent. As you can see there are a bunch of ideas on here. This is why I love letting the designer do their thing first. This is so much more productive as a first pass than if he went off and came back with 2 options because I specified everything down to the inch.

Some of the ideas here include “text as logo”, a helping hand, a group of users, small group of users, and some abstract users/symbols based on an @ sign.

Sketch 1

Sketch 2
Sketch 3

After some discussion we focused in on trying the “text as logo” based approach using dots to represent different features in each one. In the UserScape logo it represents a user and with the HelpSpot H it forms an exclamation point. The dot worked nice because it carried through from company logo to product logo.

Mike then went to work doing a more detailed version as well as taking one more pass at the “helping hand” theme. In the end I thought the hand was just a bit creepy and I preferred the connected feel between the UserScape and HelpSpot logos that the dot provided.

Sketch 4

Now that the dot’s were agreed upon it was time to build them in a digital format and decide on fonts. Mike has a rule about not talking about color until the end and I think it’s a great rule. I know whenever I’ve built websites for people in the past that they always get caught up on color. It doesn’t matter how much functionality is there all they want to know is if mauve would look better than magenta. Leaving the color out definitely helps keep you focused on the structural design decisions.

Here we have the initial go at it and #4 (lower right) is actually very close to the final product. It’s Interstate Condensed Bold (for start of word) and Regular (for back half). Interestingly Interstate is a font that was developed for the interstate highway system. It’s what you’re looking at on all those big green signs.

Logo Image 1

Things were looking good, but I wanted to checkout Futura a bit more. We also decided to change the cut style on HelpSpot from rounded above the dot to flat above it. Here you can see the one we went with (lower left).

Logo Image 2

With the tough stuff over it was time to finally get down to colors. Here’s the first stab at it. We tried a few different ideas here. Different colors for first word and second word, same color, same color with different first letter. They were good but nothing really stood out to me. #5 down was probably my favorite, but it was a bit too “Mets” for me, though it made me sure I wanted the dot to have a color which stood out from the rest.

Logo Image 3

For the second round a few new color combinations were added. I really liked #5 and it almost won out.

Logo Image 4

Here’s the final layout. It was a very close call between #1 and #2. In the end, the way the orange dot contrasts with the darker colors works a bit better. Also Mike’s wife and my wife preferred the second one so that’s what we went with 🙂

Logo Image 5

Here are the final versions:

Final UserScape Logo
Final HelpSpot Logo

I’m extremely pleased with how they came out. They look good on the web and will also perform well on business cards, print brochures and so on. Their simplicity makes them very easy to recognize and the strong colors attract the eye.

Hopefully some of you have found this pictorial interesting and informative. I encourage everyone to leave design to designers. This work is not that expensive and having it done professionally makes all the difference. You don’t know Photoshop as well as you think you do! Using Visibone to pick your colors isn’t going to cut it. Get it done right the first time so it doesn’t need to be done again later.

Check back soon for my next article, which will document the process Mike and me are going through now to design the page template for the UserScape website.