Many people ask me about the roadmap of various products, although usually it happens in informal discussions. And this is not the only question, I got many of them about how we design things, what I believe to be hot next year and so on. Although these are the questions one could ask over a few drinks, the answers are quite complicated (and they require more drinks than I can take). 🙂

Product Strategy

I will try to detail a bit our products lifecycle, using VoipNow Professional as an example (since it’s our most complex and popular product). I will start with the product strategy. As you probably know, we released the first version of VoipNow in 2006, making it the first VoIP product targeting small and medium providers. Actually, with the first version we simply aimed at telling the hosting market “Hey, this is a new opportunity for you. Come and try it.” At that time, most hosting companies had no clue about VoIP.

When we gathered data for the first version of VoipNow, we investigated lots of VoIP products and learned many things. However, nothing beat the real experiences. After about a year or so, while looking at other VoIP products, we realized that they followed no rules and most companies on the market tried to compete against each other in terms of features. They did not care about the architecture of their product, what those features meant in terms of business and so on.

At that time, we started having internal fights – sales told engineering – “People are asking for this feature, customer X told me that product Y has it. Please add it”. Just for reference, having a product (any product) development driven by sales people is a recipe for disaster. I know that this happens in many companies, but even though they might be successful in the beginning, it definitely comes with a lot of losses afterwards. Many companies notice the mistake and switch strategy while others simply die.

I don’t know how it happened, but in most cases, those features were stupid: too exotic to be used, too complicated for the end customer to understand or without much business application. Usually, they were requested by people with absolutely no market experience or business strategy. Anyways, it was really amazing to watch how companies followed each other, wasting their time developing non-sense. Maybe they did that because of the lack of ideas and steering, I don’t know.

We started to design VoipNow 2, and the idea I transmitted to our engineering team was easy to understand: “Guys, we don’t compete against anyone on features, we compete on architecture. We want to have the best architecture to build business-oriented features on top of it. It needn’t be perfect from the start, I want to make it a three year plan and I want to make anyone who wants to follow us cry.” The Sales people were crying too “That’s not good, you know that people never ask about architecture, they are just comparing features, we will kill the product by investing so heavily in something that people don’t buy, etc”. For Sales, I had a different story “Guys, we are simply preparing the product for the VoIP boom. We don’t want to build just another product that follows the crowd. We want to be able to easily add features for our customers without compromising the product reliability or performance.” Some didn’t quite agree with my vision back then, but they didn’t really have a choice.

We have currently completed 70% of our architecture plans, and the Sales guys just realized that this was the right approach. They are now looking at opportunities that they didn’t even dream of back in 2007.

How Much Does It Take To Add A New Feature?

Let me start with the development process. Every 90-120 days, we want to deliver a new minor version of VoipNow. Although minor, such a version would normally have about 20 new features, many core improvements, usability improvements and bug fixes. The most interesting story is about core improvements. Even if we have 3-4 months between two releases, this does not mean that all new features were developed during that time interval. We constantly add new functionality and prepare the core platform for these new capabilities, and it’s common to work on certain functionality for more than 6 months. This might sound pretty surprising, but it’s actually very simple. For example, we have worked for about six months on improving the CPU consumption and the memory footprint. We are still working on this because there are features we cannot add if we don’t make the SIP server faster. We worked to improve the speed of the AJAX engine for several weeks, because otherwise we cannot build some nice functionality on the interface. In some scenarios, we improved the speed up to 50x times, which is impressive. Usually, such improvements do not even reach the release notes, or if they do they tend to be ignored. For instance:

[=] Major improvement of AJAX interface

With each release, we improve interface usability to lower product adoption barriers. This is a long-term task and I do not think that we will ever complete it.

What To Add In The Next Version?

The selection of the features that go into a new version is a very complicated process. On the one hand, we receive feature suggestions through several channels, on the other hand, we come up with our own ideas. When we receive the same feature request from many people, we analyze it very thoroughly and consider its priority. The final decision on making a specific feature available always takes into account the following:

Is It Useful For The Service Provider?

If the feature is on the platform management level, it must simplify, automate or create strong new opportunities. It should reduce costs or drive new business.

Is It Useful For The End-User?

When the feature targets end-users, it must be relevant for most categories of end-users. For example, suppose we determine that something is very interesting and really helpful to medical doctors. We add the feature to a development list, but it will not get a high priority. If any of our customers has a large community of medical doctors, he should be able to sponsor the development 🙂

Is It Easy To Understand?

We hate complicated things, especially when talking about end-user features. I remember that last month I discussed with a customer who wanted to explain killing feature. It took him 5 minutes to tell me how it should have worked. I cannot imagine such a feature going mainstream.

Is The Market Ready For It?

We know from the start that there are things for which the market is not prepared. For example, we have features scheduled for 2010 and I think that we will implement them in 2011. They would be nice and revolutionary now, but we are not Microsoft or Cisco to change the world.

That is why we prioritize features extremely carefully and with a lot of effort (all the criteria above is relative, so it is hard to decide if feature A is more important than feature B). That’s why the information we gather from our customers is so important.

Bug Hunting

Bug hunting is a continuous process (not very spectacular also). Important bugs are fixed in maintenance releases, but in some cases we find bugs in the development process or bugs that could not be fixed without some risky changes that required a lot of quality assurance. For example, in VoipNow 2.0.3 we released two maintenance releases only 10 days apart. Although they didn’t fix critical issues, there addressed several important things.

An important bug is a problem that affects many customers, affecting their business or credibility. We don’t make any release with known issues that might impact the customer business in any way, but they might occur. Compared to hosting products, where use cases and interactions are obvious and clearly established, in VoIP world things are not so evident. For example, we deal with an increasing number of incidents that are very difficult to fix because they involve interconnection issues. Such problems cannot be solved overnight and there are also cases when we decide that the reported issue is not a bug, because we follow the RFC and the provider does not.

In other cases, standards are so relaxed that implementations from different vendors are not compatible. So once again, it takes a while to figure it out, as we do not want to break inter-operation with other providers. It’s our company policy to make our products more reliable and compatible, so if you report a valid issue, it will be fixed.

Most things in this article actually describe the beauty of the Agile development. We don’t want to develop everything at once and we prioritize things based on importance. If a customer requests us a feature, he can only increase its priority by sponsoring development to a certain extent. We will never implement a feature that cannot be added to the product backlog.

This post was quite long (but my flight made it possible – had all the time to write it), but at the end of it, I guess you have a better picture on how things go around with VoipNow. This is only a piece of the puzzle, so perhaps now it makes more sense why we cannot talk about it over a beer. 🙂