TryBeta.com

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?

We have invited dozens of Early Adopters who signed up over the last month to start testing TryBeta. They were given instructions today on how to sign up and use the web site.

We’re really excited, and eager to hear what software developers think about TryBeta and any suggestions they may have. We’re working really hard to make sure TryBeta becomes an invaluable tool for software developers.

If you missed the last posting about the early adopters program, you can sign up to beta test TryBeta here.

We look forward to hearing your feedback.

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.

Ok, its here! We are now accepting applications for our early adopters program where we will provide selected software developers with access to TryBeta. Selected developers will be the first to get to use the new service and submit any feedback they may have.

We are real eager to hear what the community has to say.

Go to our Early Adopters Application form to sign up. This is only for developers right now. Beta Testers will have their chance soon.

Early Adopters will get free beta testing opportunities when we launch.

We got a lot of great feedback from our online survey last week. If you haven’t taken it yet, you can still fill it out here.

It’s interesting to see how many developers either rely on their own testing and don’t have a formal beta program, or do have a beta program but hardly if ever hear from their beta testers. This made up about half of the surveys.

Virtually every developer who filled out the survey felt that beta testing was extremely important or very important but not their highest concern. Over half thought it was extremely important to beta test their software.

70% of developers who did not have a beta testing program, would like to start one and the remaining 25% or so of developers would consider starting one.

Problems faced with Beta Testing
Can’t find reliable testers - 56%
Feedback is inadequate or incomplete - 51%
Hardly or never hear back from testers - 32%
Too hard to manage - 6%

Some other problems felt by developers;
Not enough people who understand the software
Beta Testers Lack Time
Beta Testers don’t have the resources (ie hardware, software etc…) to test the software

Essential Features of a Beta Program;
Easy way to submit feedback - 73%
Active involvement of the developers - 59%
Having an organized way to manage user feedback - 44%
Incentives for users who beta test - 32%
Group discussions between testers - 27%
As many users as possible - 24%

Some other essential features of a beta program;
- Clear instructions on how to report bugs
- Know the experience of users
- Automated testing

We truly hope that TryBeta will help developers produce more stable products. Thanks for the feedback, and stay tuned for our early adopters program.

TryBeta is for you, the software developer looking to make sure your software is stable, high quality, and accepted by your potential market. We believe it’s going to be a great resource for all developers and we want to make sure that it is not only an affordable option for developers, but that it provides the features that developers are looking for.

Please fill out this quick questionnaire. We take all feedback very seriously and would like to know, based on your experiences, what makes a good beta testing program. What do you, as a software developer need? What do you want TryBeta to do for you?

We look forward to hearing what you have to say.

Note: All fields are optional

If you would like to read up on TryBeta, you can read an earlier post describing the service.

You can sign up on our main page to be notified when TryBeta is launched

Selling software is not about the software, its about the service you offer and the experience you create for your users. That’s what separates commercial software from open source software.

I am a big supporter of customer focused software development. Solving the customer’s problems is what software is intended to do. If your software can’t provide the solution your users are looking for, do everything in your power to make sure you do.

When it gets tough to spend time handling support emails instead of developing software, think about all of your customers as potential sales people. Make them happy and they will spread the word about your products to friends, family, co-workers etc…

Now, some customers wont ever tell a friend about your product, but others will. Its difficult to determine which ones will end up talking about you.

For the past 7 years I have put a large focus towards helping customers as quickly and as best that I can. Here are some of the ways it has paid off;

1) A customer needed to use one of the applications provided by my company but it lacked a certain feature. I created a simple plug-in and sent it to him which provided a solution to his problem. A few weeks later a review came out about the product and the reviewer just happened to be the same guy I sent the plug-in too. The application ended up getting a great review that went out to a large user group.

2) A customer who bought our HTML editing application owned a large web site with a pretty big following. He sent in a handful of emails and surprisingly to him, we delivered prompt replies to all questions. He continues to recommend our software to his community.

3) We ask customers where they heard of us when they order. The most significant answer is friend, colleague, or co-worker followed by search engines and download listing web sites. Clearly, leaving a good experience with customers is the best form of marketing you can offer.

4) Another interesting success story can be found here.

Tips On Turning Customers Into Marketers
1) Encourage customers to spread the word
The usual tips of having a tell a friend link on your web site and an affiliate program are important. However, you have to actively seek out users who get exciting about your software. These users are the ones who provide feature requests, report bugs, and actively try to engage in any form of communication with you. If they take the time to talk to you, they are most likely excited about what you have to offer. After you provide them with top of line support, give them a coupon (try making the coupon ID their name), and tell them they can send it out to 10 of their friends for a 20% discount.

2) Take the blame for ALL mistakes
Did a bug in your software crash your customers computer or was it an error on their part? Who cares! Apologize for anything that goes wrong and offer to fix it. Tell them how important this issue is and get it fixed ASAP.

They don’t want to deal with your company anymore? Give them a refund before they get the chargeback and bad mouth your product. Never take money from a customer who can not use your software as advertised, whether or not it is your fault or theirs.

3) Understand that not all customers are as knowledgeable as you
After receiving their registration code I got an email from a customer saying that they need a new code because their keyboard could not type the zero with the diagonal line through it.

Lets face it, we are not all experts in all areas and will look inexperienced in anything we do. Understand where your customers are coming from and don’t get frustrated with any “basic” misunderstandings they may have.

If you get the same basic question over and over, there is something wrong with your software!

4) Always encourage customers to provide more feedback
Communication is the most important part of any business. You must base your decisions on what your customers need. Encourage them to continue to send feedback so that you can develop a bond that keeps them coming back to buy what you have to offer.

5) Your customers will talk about you
Your customers are talking about you, both good and bad. Don’t let anyone get away with a bad word about you.

The most important advice I have used for the past 7 years is to treat each customer as if their happiness means another sale. You never know who they will be taking too.

6) Get them involved in the planning/development
If your customer sees his or her opinions and suggestions incorporated into your software, which product do you think he is going to be sticking with and recommending to his friends?

Show your customers how much you value their opinions by taking their advice seriously. If you don’t quite agree with their suggestions, tell them why and offer alternatives.

1) Show confirmation after an action has been performed
After the user has performed an action, such as deleting a message, sending a message, uploading a file etc…, make sure it is clear that the action has been carried through.

Often applications will assume that just because the user has knowingly pressed the ‘Send’ button or the ‘Delete’ button, they know exactly what has happened. However, it is important that the users gets proper feedback even if the last action was a success. Don’t allow your users to wonder whether or not the last operation was carried through properly.

Another important principle that falls closely in line with this one is to provide active feedback as a long operation is taking place. Instead of making it seems as though your application has froze, visual feedback during long tasks is extremely important to let the user know what’s going on.

2) No Error Codes
Building on the previous point, when an error occurs, notification to the user is extremely important. This error code, however, must be descriptive and offer advice on what the user can do to fix this.

At a bare minimum, any error codes reported by the operating system, web server, etc… should be converted into plane English (or whichever language the application is developed in).

Once you translate the application’s error codes into something your users will understand, provide them with the steps to fix this problem. What should they do next? How can they fix the problem so it won’t happen again?

3) Always Provide A Way Out
Wouldn’t it be scary if you pressed the Delete button by accident and the confirmation message that appeared did not include a Cancel button? That would be the absolute extreme situation where the user was not provided with a way out.

Often applications don’t provide a clear way out of an operation if the user changes their mind. This happens a lot with online applications that force users to press their back button. I believe there should always be a way out of an operation without having to press the back button or quit an application.

This issue comes up a lot when an application tries to perform a long operation, for example, searching through thousands of files. It’s always important to let the user cancel the operation if they feel it is taking too long or realized they made a mistake.

Make sure you provide a way out of every decision you ask the user to make.

4) Easily Accessible Help
Are your users reading your manual from start to finish before they open your application? Not likely!

Nobody wants to read through manuals before they can use the new software they just downloaded. However, that doesn’t mean that they won’t go looking for help.

It’s important to provide the user with the necessary information and help resources when they need it. Using help tags is a good start, but combine that with quick links to additional help topics without making the user stop what they’re doing.

Help icons in all dialogs should take them to additional information on the current features they are working with. When they’re in the ‘Search Dialog’, the help icon should take them right to the search topic in your user manual.

5) Let Your Users Be Lazy
Spend that extra time putting in the necessary features to make sure your users don’t have to do additional work. Do they need to locate a file on their hard drive? Your application should offer to find it for them. Do they need to install another component from your web site? Your application should install it for them (Or at-least take them to your web site).

Allow your users to do less, so they can focus on using your application.

6) Make It Inconvenient To Delete Data
Even if this is an important feature in your application, make it really inconvenient. Don’t allow users to delete data easily. There is a reason Windows has a Recycling Bin and the Mac has the Trash can. If you allow users to delete data easily they will delete important data and blame you. Make it really inconvenient for them to delete anything, and if they do delete something, offer them a way to get it back.

7) They’re Not Reading Your Warnings
Building on the last principle, it is important to know that users are NOT reading your warnings. No matter how much you try to tell them, they are not paying attention.

This includes the pop-up Message Dialogs right before the user decides to delete his hard drive. The fact is, if users actually did read your dialog boxes, you would have a lot less support to handle. However, that doesn’t mean that these messages should not provide all the information necessary for users to make decisions.

Message dialogs that try to show a warning or error message should be visually different than other messages. I don’t mean to make your application completely different from other applications your users are used to, just to make sure that they know the message they are about to dismiss is real important.

Multiple Undo/Redo
So what happens after they ignore your warning dialogs? They realize where they want wrong and want to fix it.

All applications should have multiple undo and redo features. This should not be a feature, but rather a “Bug”, if it does not exist.

9) Hide the Advanced Features
When you design your application plan out what are the essential features and what are more advanced features for the users who want more control over your application’s features. Users just want to get their work done and not be bothered with dozens or options and choices. Give them what they need and tuck everything else away in an unobtrusive spot that users can get to only if they want more control.

For example, if your image editing application allows users to export images they have edited, a basic feature might be to choose the picture format. A more advanced feature would be the number of colors or the ability to include comments in their picture files.

10) Remember What They Like
Your windows and dialogs should remember previous settings that the user has chosen before. Going back to your image editing application, if they previously selected to export as a JPEG picture, your Export dialog should remember these settings.

11) Stay Consistent
Stay consistent both within your application and with other applications the user is used to. Make sure that interface elements are standard and are used properly. It is really difficult to create a new widget and expect users to know what it’s supposed to do. This is one of the problems with cross platform applications. They just don’t seem to blend in with the Operating System. It’s also a problem with web-based applications. Who gets to decide the Interface Guidelines that should be used? These decisions are already made for you when creating desktop applications for Mac or PC.

Non-standard controls will also not look good as operating systems get updated or the user uses different skins and templates.

We’ve been working really hard on getting everything ready. All the the functionality is there, we are just re-working the interface and looking for critical issues.

The site is coming together very nicely. We want to make sure that it is as easy to use as possible before we start inviting developers and testers to try it out.

I am going to post very soon how we plan to launch the web site. Remember to sign up on the front page to be notified when we launch.

Here is a little teaser to show what the web site looks like now. Enjoy:)