TryBeta.com

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.