TryBeta.com

If someone were to ask me what are some quick things to do as an ISV that won’t take too much time I would tell them the five following things;

1) Create a Google Sitemaps Account
You don’t even have to create a sitemap, although doing that is very easy. All you have to do is add, and verify, your web site with Google’s Sitemap program. The information you get about your web site is simply amazing!

Here are some quick screen shots and descriptions of some of the information you get;
1) See Exactly Where Your Web Site Appears In Search Engines
2) Find Out Why Your Web Site Is Not Appearing In Google
3) Control How Often Google Scans Your Web Site
4) See Exactly How Many Web Sites Link To You

This service is absolutely free and the information you get will help you improve your search engine rankings, find out who is talking about your web site/products, and locate broken links or HTML errors in your web site.

2) Create A Google Analytics Account
If you do not have a Google Analytics account, you don’t know what you are missing! It’s not just the details it provides, but how it lets you easily compare data against previous dates. The best part comes when you link it with your payment system. You can see how much money, on average each visit gets you separated by country, region, city, source, etc… to name just a few. So for example, if you know new visitors from Toronto bring you on average $0.34/visit, that gives you a good estimation for your Google adwords campaigns. Many payment processors will easily link up your data including eSellerate. If you use PayPal, I have never used them, but I’ve heard good things about e-junkie. They take care of a lot of things including sending payment details to your Google Analytics account.

3) Buy A Really Nice Stock Icon Set
My favorites, for Mac OS X, are from Icon Drawer. You can also try Icon Buffet, and of course Icon Factory. Stock Icons are always good to have around and add a level of professionalism to your web site and products.

4) Buy A Psychology Textbook
From motivation, to time management, to understanding how people react to different kinds of advertising, an Introductory Psychology textbook will cover all the topics that all those self-help gurus and marketing know-it-alls pretend to know about. From somebody who has spent a fair amount of money and time reading books upon books of “advice”, a Psychology textbook will cover it all, complete with actual, real-life studies instead of personal opinions and misinterpretations. Many are available from Amazon.

5) Take One Big, Huge, Gigantic Risk - Without Asking
Ever get an idea that you think is really great, only to be shot down by friends or colleagues you ask for advice? This time, don’t ask, just do it! I always get the impression in various newsgroups, mailing-lists, and forums that developers have these great ideas and than when they ask whether or not they should do it, they get conflicting advice from other developers. Sometimes their ideas are trivial like adding an online forum, some are much bigger and take longer to implement. Maybe it’s an advertising opportunity or exhibiting at a trade show. I say just do it! Maybe it works out, maybe it doesn’t. Naivety is your best friend.

As microISVs, especially those who are just starting out, we have one big advantage over large corporations. This advantage gives us the ability to develop and release applications that would take larger companies much longer. This advantage allows us to take risks that larger companies can not even consider. This advantage is so great that used properly, it allows us to accomplish things that no other company can. This advantage is our naiveity. Our ability to try new things, take risks, and learn more because, well, we just don’t know any better.

We can decide today to try something new simply because we can. We don’t have to worry what our boss thinks or what it will mean 5 years down the road. Our lack of experience and, in some cases, lack of knowledge about certain things pushes us to try new things without considering all of the consequences.

Large public companies have to evaluate all projects and ensure their rate of return is as much, or more, than their investors are expecting. For example, if you have purchased stock in Google you are paying 60 times their current earnings (as of the time of this post according to yahoo finance) for each share. This means you are expecting huge growth in their profits which will eventually be distributed to you in dividends or increases in the stock price. The only way to ensure growth in dividends and their stock price is by continually increasing their rate of return on their investments and making more money. Why else would you pay so much to own a share of Google? Now, how would you feel if Google announced today that instead of putting their money in creating new products, they will be putting it all into a savings account and earn 3%/year in interest? Or they decided they will go to vegas and put their 10.43 billion dollars in cash on double 0? Of course these are extreme circumstances, but the fact is that these large companies have a measure they must meet, and they better be pretty certain they can meet and surpass these expectations. You won’t see many companies take a large amount of risk without evaluating possible outcomes.

We as microISVs can use this to our advantage. We can be the ones who launch a simple site that sells each pixel for one dollar. We can decide that we will release a utility that lets users share files without concern for legal issues (not to say that this would be a good decision). We can decide that today we will try something new and so what if it fails. If it succeeds, WOW!

This does not mean that companies do not make bad decisions or try stupid ideas. What this means is that companies are required, by their investors, to provide a return on investment that will continue to attract these investors. In order to so, they must be careful to analyze everything they do.

When I released my first application I had never spoken to another developer. I had no mailing list. I hosted my web site on one of those free domain web sites. I didn’t do any market research on whether or not this product was something people needed. I didn’t even do any real beta testing (though it was a public beta). I just built it because it was fun and posted it on some software listing sites.

Seven years later I have a successful software company and am getting ready to launch an invaluable service for software developers. Looking back, I would never have released the product as it was knowing what I know now, or how much work would have to be put in to get to where I am now.

How far has your naivety taken you, and where will it lead you next?

Google has created a really easy way for web developers to optimize conversion rates on their web site.

Its currently being beta tested, but the Google Website Optimizer looks like it is going to be a really useful tool for micoISVs, or anyone for that matter, who want to test and improve conversion rates on their web site.

Web site developers place a code snippet on their web site, just like with Google Analytics. Then you can create modified versions of your landing page with different headlines, images or content. Google will then randomly display one of the modified pages to web site visitors. You will then be able to track which page provides the best conversion rates.

Over the past few years many developers have focused on creating applications online instead of making downloadable executables. And why not? You get applications that can be used from virtually any computer, you can share information with many people in real-time, and you can communicate easily with others no matter where they are located.

My question to you would be, how often do you need these features and what are you willing to give up to get them?

Lets face it, many online applications are really cool. Google Analytics and Google Spreadsheets are two that come to mind. Zoho’s product line is also very impressive.

However, realistically, how often do you need to share documents in such a way that your current tools become inadaquate? More importantly, how often do you need the benefits offered by these online applications taking into consideration how you currently get by without them? Are they really all that necessary?

For some people they may be a necessity, but is this the case for the majority? Are the majority of people willing to give up the benefits of their word processor to switch to an online application? Are they willing to upload all their current documents to someone else’s server? Are they willing to lose the integration that downloadable applications can offer with their operating system and other apps (i.e. on Mac OS X you get one common spell checker and dictionary so adding a word to the dictionary in one application automatically makes other applications aware of it)?

Operating systems have been refined and updated for decades in order to provide a great user experience. How many people are willing to give this all up for the benefits listed above? In addition, how many people are going to pay for these benefits in order to use these online applications.

TryBeta is browser based because it requires users to collaborate with other users all over the world at any time. This doesn’t mean that every feature should be offered purely as a browser-based option.

My point in this article is not to downplay the significance or the hard work of developers creating online applications. My point is to ask yourself, in all honesty, do the benefits outweigh the drawbacks? How many people can really benefit from an application that is provided online versus as a downloadable application?

I am using online applications to help prove a point that can be considered for any kind of design or feature you are planning to add to any kind of application.

How often will the feature be used and by how many people?

Write down the feature you would like to add. Does it contribute to the core problem that the application is set out to solve? If not, does it solve a new problem? How many people are looking for a solution to this new problem?

In my last post I talked about some of the strategies I use to help determine which features should be added to an application. It’s always a problem to determine which features should be implemented, especially when the feature request comes from a customer. If a customer needs it, its hard to say no.

However, further to my points from last week, after I have determined the kind of feature it is, I borrow a model used in Management theory to help categorize features further.

I like to look at potential features in four ways. They include;

1) Is the feature valuable to your company

In order for a feature to be valuable to a company it must improve the product significantly enough to increase revenue. Obviously a feature that increases revenue must also be valuable to the customer. The perceived value of a feature is what counts, not necessarily how useful it may be. That statement may seem a little odd, because naturally one would assume a feature must be useful in order to be valuable. However, I have found that this is not always the case.

Take for example the web hosting industry. Companies are offering 250GB of bandwidth and 5GB of file space as a starter account for $3.99/month. It is a well established fact that most users of web hosting use less than 5% of what they pay for. Why then are hosting companies competing so aggressively on bandwidth and space? Because that is what customers find valuable. Customers believe this is what they need so they go ahead and look for companies that provide the greatest amount bandwidth and file space, even though they will never use that many resources. This often prompts web hosting companies to oversell, but this is a discussion for another day. There are many other features that should be valuable to a web hosting customer, but for the majority, bandwidth and file space are perceived as the most valuable.

In order to determine what is valuable to your customers it is important to know a few things about them. This always comes back to knowing your target market. Looking through your past support emails, what do your customers value?

It may include;

1) Ease of use

2) Speed

3) Interface

4) Compatibility/Integration with other products

5) Customization

By determining what they value, you can have a better idea of which features should be added and when. If feature requests come in that don’t fall under what your customers consider most valuable, you may want to delay adding that feature.

One of the more general aspects of an application that users value is speed of execution. That is why with technologies like AJAX and even just regular, old javascript, combined with the increasing number of users using broadband connections to connect to the web, online applications have a greater chance of prospering. Google has done an amazing job with gmail, Google Spreadsheets and Google Analytics to name a few. However, there will still always be a lag when information must be passed to the server and back. That is why not all applications are suited to go web based.

Where users value collaboration and portability, web based applications have a huge advantage over desktop applications. They can be accessed from virtually any computer, anytime, without the need to download large software packages. Multiple people can work on them at the same time, and data can update live as each individual makes changes.

One last example can be found in web browsing software. With the increase number of viruses and spyware, security has become a feature of great value to customers. Firefox was able to gain significant market share as users perceived it to be more secure than Internet Explorer. As Internet Explorer 7 continues to aggressively fix security holes (as well as add tabbed web browsing), they may be able to get back lost market share to recent Firefox switchers. Although, without additional features of value, doing so may prove to be difficult.

2) Is the feature rare?

Copying the features of rival applications may be required in order to keep up with the competition. However, when you find a feature that is not found anywhere else, you can gain a short-term competitive advantage and have the benefit of customers knowing you were the first to implement it.

Adding features not found in other applications is not an easy thing to do. Often times you set the standards for how the feature will be used. Educating customers on how to use the feature may turn out to be difficult.

When deciding on which features to implement, if you are the only application that has the certain feature, you can quickly convert customers to your software. If their current solution does not offer what you do, new customers will be more willing to try your application.

3) Is the feature hard to imitate?

Building on the last point, if the feature you are going to implement is hard for other companies to imitate, you can maintain your competitive advantage indefinitely.

It may be hard to imitate because you own the rights to a certain technology. For example, a certain protocol or file format. Or, you may just have a certain employee with skills beyond what your competition can attract. A strategic partnership may arise which allows you to integrate the core competencies of either company to deliver a superior product over what your competition could ever do.

As a developer of web development software, we have a partnership with a web hosting firm to offer one year of personal web hosting with the purchase of our web development products. By taking advantage of the economies of scale provided by our partnership with a web hosting company, we are able to offer this package that would otherwise be very expensive for us to do on our own.

4) Do you have the capabilities to take advantage of the feature

The last criteria you have to judge against the potential feature is whether or not you have the capabilities to take advantage of the particular feature.

Can you actually implement this feature? Is it too expensive? Does it rely on technology that you do not currently have? Can you promote this feature to customers and get them excited about it? Most importantly, do you have the resources to pull it off?

If the feature is beyond your coding abilities then it may not be a good idea to pursue it. Perhaps it will require 2 additional support personnel just to handle future support requests. If you can not pull it off, its not worth doing a poor job.

Summary

In summary, when deciding what feature to implement, you have to ask yourself a few questions. Does it create value for you and your customers? How many other applications already offer it? How hard is it to copy by your competitors? Are you or your company able to take advantage of it?

I am not saying to rank features by any order of importance based on this model, though you can certainly come up with a ranking scheme. What I am suggesting is that for each feature you are about to implement, you should ask yourself these questions. Take them into consideration to help you decide which feature you should add to your software next.

You open up your email to a list of feature requests from customers. The emails go something like this;

“I think your software has good potential. It definitely needs X though in order to be really useful”

or

“Great program! Are you planning on adding X? When you do I will buy it.”

Now you rush out and make sure the next update has X in it. You don’t put a lot of thought into how its going to be implemented, you just know it has to be there. If your product doesn’t have X its not any good. Oh and wouldn’t it be really cool if it had Y too. You can’t have X and not have Y. If I don’t add X, Y and probably even Z, no one will buy my software again!

Sound at all familiar?

When you get that new feature idea in your head, you start to wonder, how did my software not have this feature before?

Adding feature X won’t necessarily benefit your software. Why? Features don’t sell software. The ability for your software to quickly solve a problem is what counts. Now you have to ask yourself, will feature X (and Y and Z) really help my users solve their problem much more quickly?

Some things to consider about new features;

1) Not all users need these features

2) Most users won’t even know they exist

3) Most users don’t use your software the same way, and won’t have any use for that feature

4) Features add software bloat and software bloat adds confusion and requires more training to use your software

5) Creating a solution to a problem that people don’t know they have is difficult to get users to understand. So just because a feature might help improve productivity, it may be tough to convince a user that they need it. This afternoon I was sitting with a friend who was using Internet Explorer 6. I told him he has to get FireFox to use tabbed web browsing. He said to me I have no problems with Internet Explorer, why should I change? He has never used tabbed web browsing before so he didn’t know how much it could improve his web browsing.

First, and most importantly, you have to know how many people actually need that feature in one form or another. If a lot of users are requesting a certain feature, you have to move it up on your to do list.

Here are a few things to consider;

1) Define what your program is most used for, the major problem it is trying to solve. Not what every single user may be using it for, just what the majority (70%+) might use it for. This will be called your Core Problem. The Core Problem is the problem your software is providing a solution for. You can have multiple Core Problems, but try to limit them to what the majority of people would use your application for.

Example: Link Checker

Core Problem: Help me fix all broken links on a web site

2) Separate Feature Requests into Categories
Core Features: Core features are those features required for your application to actually solve its Core Problem. If they are not there, your application would pretty much either do nothing, or it would be more convenient to do what it does manually.

Example For Link Checker:

Spider to scan/check links

List of broken links

Error number for each broken link

Which pages contain the broken links

Without the above features, your software would pretty much be useless. If Your link checker didn’t report the error code for a broken link, I would have to go an extra step in order to find it, which would make fixing it harder. Competition often defines what can be considered a Core Feature.

Convenience Features: These features make using your software easy to use. They don’t contribute to the Core Problem, they just provide a more pleasant use of your software. These include; undo/redo, Open Recent menu listing recently opened documents, auto check for updates, auto install plug-ins, keyboard shortcuts, spell checking, speed improvements and optimizations etc… They make solving the problem even faster than before by fixing little bottlenecks in the software design.

Functional Features: These features add additional functions and uses to your software. They are hard to determine because they may help with the Core Problem. To distinguish them from Core Features and Convenience Features you must consider these points:

1) Are there many other applications out there that perform this function? Do they do it better than you ever could? Are there standards that your customers are already used to?

This question helps distinguish the Functional Feature from a Core Feature. For example, adding an FTP Client to an HTML Editor to upload your web page files. This is not completely necessary and there are many third party programs that already do this really well. In this situation it may be better to integrate two separate products than add in an FTP Client.

2) Is this feature always required in order to solve the Core Problem of your software or are there just special circumstances where this feature can be used?

3) How many users can take advantage of this feature? Does it require expert knowledge? Can your target customer take advantage of it?

If only a small percentage of customers will actually have the knowledge or capabilities to use the new feature, it may not be worth implementing until more critical features are added.

4) Will it require a change in the category your application falls under? For example, you have a file browser and you add the ability to open Text files, Picture files, Movie files, Audio files, etc… and make quick changes to them. It now crosses the line between “file browsers” and “File preview tools”. Define the boundries of the category your software falls under so you know when your crossing that line.

There is nothing wrong with adding Functional Features. Functional features help attract more customers by stretching to more markets. All you are doing at this step is determing how to rank features based on the usefulness to your current market. However, you should always make sure core features are implemented first, then convenience features, and then functional features.

While working on a version 1.0 of your software, knowing the kind of features you are adding can help reduce the problem of never getting a final product out. It can help you decide which features must be added for version 1.0 and which feature can come in an upgrade. Functional Features can usually come in major upgrades at later times.

Using the above strategy does have its problems. It is subject to personal opinions of the developer. It is often hard to determine the difference between Core, Convenience and Functional Features. How you define them may be related to how you define the Core Problem. However, if you use this method of thinking, it may help you spend your time more efficiently and make your decision making process a little easier.

In my next post I will talk about how to decide on which features to actually add to your application by looking at each feature using four additional criteria.