Just How Important is Your Software Installer?
Most people probably think it’s not that important, as long as it just works and installs your software for you. However the reality is that this is far from true. Your installer is the first impression people have of your software, and you only get one chance! If it doesn’t work, if it’s hard to do, it will cause a negative perception of your software before they even have a chance to try it! I don’t know how many of you are familiar with Zune, but this software is getting a horrible reputation online because of how difficult it is to install. Just look at the size of this review, it doesn’t really talk about the software, it’s all about how horrible the installation process is! So why start with a negative against yourself when there’s no need.
Not only is it your first impression, but just as importantly it’s not part of your core product. So in other words, not only is it important to do right, you also don’t want to spend too much time on it (it’s used only once) and it’s not your core competency. Talk about contradicting priorities!
Therefore, that being said, I strongly suggest you look at a software solution that will build your installer for you. Some of them are great, others not so great. Not only that, but they also range in price from free to very expensive, as well as in complexity, and what you can do with them. Before I start to go into details, just to give you a disclaimer, we at LandlordMax now use Install4J which I strongly personally recommend.
Getting back to the discussion, I’ve personally used 4 different installer packages in my career, including 3 with LandlordMax alone (there is some overlap). The first installer I ever played with was a custom built installer for the company I was working for at the time. Yes this solution worked, and it had by far the most customization, but it was also the most expensive to maintain and support. It’s really a second application for the company. They eventually moved to InstallShield, which at the time was one of the better solutions (this was many years ago). It worked, it definitely simplified the installer process. Now although I said it simplified it, it wasn’t the end all be all solution by far. If I remember right (this is a long time ago), every wizard screen had some code behind it in InstallShield’s own proprietary language. And at that time if you clicked on the back button, it didn’t remember the state you were in, which resulted in some very crazy scripting code.
Moving on to today and LandlordMax and skipping several other installation experiences, we initially started with InstallAnywhere. One of our requirements was that the installer we used also install a JVM with the local application. I don’t remember why I picked InstallAnywhere, this is about 4 years ago, but that’s the solution I chose. After a couple of years, we also started to use NSIS (Nullsoft Scriptable Install System) for our patches, which created much smaller installers (the patch installers just overwrote some files in the application directory versus a full install). I used NullSoft for the patches because it was a much quicker and simpler installation than InstallAnywhere.
At several points, we even looked at using NSIS to fully install LandlordMax, but let me tell you this is a complex endeavour! Although NSIS is a great little installer, it’s all script based. That means you need to learn another programing language. Not only that, but you need to become proficient in it do anything beyond the basics. Yes, we could learn it, copy snippets, etc., but from that point on we’d have to keep maintaining it. Someone would always have to be familiar with the language. This might seem like a small factor, but let’s say the “Installer person” quits? We have to find someone with that skill or train another person. Very expensive! Especially having gone through something similar with my first installer experience, I’m not willing to go that route again.
Since I wrote about JProfiler here on my blog, the people who make this amazing software contacted me to tell me about their installer solution called Install4J. After a few emails with them, I decided to give it a test run, and boy am I glad I did!!! They’ve created an amazing installer that’s in the same league as their code profiler! Within 1 hour I had created a brand new and fully functional installer for LandlordMax, including time to read a couple of advance features in the user manual! That’s amazing! Not only that, but if you consider the human resource costs of learning an installer like NSIS and the cost of Install4J, Install4J wins hands down!
I did mention that we were using InstallAnywhere as well. After trying Install4J, we decided to convert entirely over to Install4J and stop using InstallAnywhere. It was a good product for us at the time, but it’s now time to move on to a great product like Install4J. This is why in the upcoming version of LandlordMax later this month you’ll see a new look and feel to our installer. We’re now using Install4J for all our installers.
Why did we convert over? For several reasons. First, it was just too easy to learn and use. To do the same things I did in InstallAnywhere in Install4J takes me a fraction of the time. And I’m not the only one who thinks this way, the following thread on JoelOnSoftware has other people expressing their sentiments on the unnecessary complexity of InstallShield (same family of products as InstallAnywhere).
It’s not just the complexity of creating an installer, it’s also the ability to perform tasks. Everything seemed intuitive within Install4J. To give you another example, let’s say you want to install an application local JVM with your installer, you don’t need to go download it from their website (never mind finding it on the website which always take me a while) and put it in the right file location for the software to pick it up, they have it built right into their software. You just select the JVM version, and if it’s not there, you just press the “Download JVM” button right below which lets you pick it from a list. It then automatically downloads it, installs it, and you’re ready to go. No need to do anything more.
Another feature I really liked about Install4J is it’s ability to compress the installer itself. With InstallAnywhere last installer had grown to over 35MB in size. With Install4J, our new installer is going to be about 15MB, and this is with a bigger install on top of that. That’s more than a 50% drop in download size! This might not seem too significant, but remember that if you have thousands of people downloading your software, it sure can make a large reduction in your bandwidth usage.
Something else I really appreciated, which I have to admit I’m not as familiar with in InstallAnywhere, is the ability for it to use files relative to the project file. Why is this important? Because I can use the Install4J installer script directly within an Ant task! I build my main Jars, pick up my other Jars and resources, and away I go, all from within the same Ant script. I can now check the installer script right into CVS, and any other developer who has a license to Install4J can create their own test installers! WOW! Yes you generally don’t need to do this, but when it comes to testing an install environment versus your local environment, there’s no faster way to get the latest install than just generating it yourself within your IDE at will!
Another thing to realize with Install4J is that it’s not limited to just Java applications. Actually I’d say it’s amazing for Java applications, but you can use it to install any type of software. They have hooks for pretty much all types of installs. It’s just that for us, we also need the ability to install an application local JVM, which greatly limits us in terms of which installer solutions we can use. If it wasn’t for this limitation, I would still use Install4J, it does everything you need your installer to do and more. For example it has the different install modes (silent, graphical, etc.), multi-platform support, multi-language support, etc.
As an additional little tidbit of information which really excites us, from what I understand the fine people at Install4J are looking at potentially extending their API to allow hooks into your own software application for auto-updates in an upcoming version! What this means is that you’ll be able to use their knowledge and technology to allow your customers to click on an “Update” button directly within your software which will update it, without the need to download and install a patch. This is great! Yes, we could build it ourselves, and we actually did look into it. From our calculations, it would take at least 2-4 weeks, so let’s say 20 days * $1000/day (this includes salary, benefits, etc. i.e. all the costs for one developer), then our costs is about $20,000. If we can outsource this technology, assuming the highest price point, we come out ahead by more than an order of magnitude! And not only that, this is their field of expertise, their core competency, and they will maintain and update the feature for us. We could instead spend those resources building other highly valued features that are unique to LandlordMax.
Therefore, as you’ve seen, your choice of how you build your installer is important. First, it’s your first impression, so make it a good one! You only get one chance! As well, since your goal is to minimize your costs in this area, you should look at purchasing a solution rather than building a custom one. If I had to calculate the costs of a custom solution, well any of the installers available today on the market would probably be cheaper. Even NSIS, which has many copy/paste scripts available is still fairly expensive in developer time. After having used several alternatives, I’m strongly recommend you check out Install4J. This is the one we’re going to be using from now on, it’s the best one I’ve ever worked with!
Permalink to this article Discussions (5)
Should We Release Now?
A common question with software companies is when to release the next version of their software. Should it be as soon as enough new features and benefits are available that people will be interested in? Should it be when there’s enough value that virtually everyone will want to purchase an upgrade rather than only a percentage? Should it be every month? Should it be once every year, two years, etc.? This is a very hard question to answer and every software company handles it differently.
Not only does every company handle it differently, but sometimes different releases of the same product/project are handled differently! And this happens to be the case with this latest version of LandlordMax. Normally I only like to release a major version of LandlordMax when we’ve added enough new features that it will excite a large percentage of our customers! If it’s only a few features, we sometimes will just release that as a patch, but I generally like to push features to major releases.
This particular upcoming release will be different than usual in that it’s only been a short time since the last release. Although version 2.12 states that it was released in December, it was actually released in April. That means it’s been just 6 months, which is very quick for a new major release. Is it too soon is the better question! And this is where I’m facing a very big delimna which I’ve finally resolved over the last few weeks.
I’m sure you’re wondering why it was a difficult choice, and I’m going to explain why right now. In the upcoming version we’ve added several features that have a major impact on how people perform their daily tasks. One of these features is the “Late” button shown in this animated tutorial. Although this is just a simple button, the amount of effort it will save some of our customers is significant. Another small feature that has large implications is that when you now create a new lease, a scheduled accounting entry will also automatically be created for you. The more tenants (ie. leases) you have, the more beneficial this quickly becomes. For some of our larger customers with hundreds of tenants, this is a huge benefit!
On top of this we’ve added many other features. I don’t want to divulge everything yet, but another major new feature is the ability to create, store, and print receipts. This is a whole new section that many people requested. We’ve also added date formatting, some preference settings, etc.
As well, we’ve done a lot of very significant performance enhancements. Between version 2.12b and version 2.12c we initially did some amazing performance enhancements, as much as an order of magnitude faster for many screens (that’s 10x faster performance!). Well in this version we did another order of magnitude in performance for most data and list screens! We ran a test database with over 2000 tenants, over 2000 units, over 5000 workorders, over 5000 receipts and invoices, over 50,000 accounting entries, and all the related data. I can assure you that the larger your database, the more significant the performance enhancements! Some screens have improvements where the display is virtually instantenous for larger tables (under 1/2 second)! We’ve improved the speed of the UI (User Interface) and the database calls (which I’ll probably write about the later very shortly). All in all, there are some very significant performance enhancements in this upcoming version!
Now you’re probably still asking yourself where’s the dilemma? The dilemma is that we wanted to add two other new and very powerful features for this upcoming version. The problem is that neither of these features is going to be ready for at least 2 more months. So do we wait 2 months for these two features or do we go ahead and release now with all the great features and benefits we’ve already implemented?
You still don’t get the dilemma? The dilemma is that if we release now, we might now also want to release the other two great features in 2 months. Releasing major versions too often will annoy your customers! Nobody wants to be upgrading every other day. So if we release now, then when do we release the two other major features? In case you’re wondering, these are very highly requested features, so I believe they will have a significant impact on sales and customer happiness.
So we can postpone the release for 2-3 months, which means we lose revenue (opportunity cost) as with every new version, every new features, we increase our sales. If we release in 2-3 months, I personally believe that these two new features will generate additional significant sales by themselves! So we want those in sooner than later too. So if we release now, do we push those features to the next major release to avoid having too many upgrades and annoy our customers or do we release them in 2 months? Which do we do?
As well, each release has technical support costs. Although our upgrades are fairly easy to do, all you need to do is re-install the software overtop the old one (the database is automatically converted for you), many of our customers still require technical support. What you have to understand is that many of our customers aren’t all technically literate (we do offer the easiest property management software after all!), which means it will convert to some extra technical support costs for us. This adds to the equation in that more releases is more expensive.
So just to recap as this is fairly complex, here are our three choices:
1. Release today missing two major features. Re-release again in 2-3 months as another major upgrade (knowing that people don’t like too many new major releases, and that there will be additional technical support costs).
2. Release today missing two major features. Push the 2 major features into the next major release several months away, even possibly as long as a year (and lose the additional sales for that time).
3. Release in 2-3 months and withold all the great features we’ve already built. This also means we’ll lose additional sales during 2-3 months.
As an extra factor, September to April is our busiest time (they’re multiples of the rest of the year). So these 2-3 months are right in the middle of where we make most of our yearly revenue! This means that 2-3 months is actually like 6 months for most businesses!
Which would you choose? I personally opted for option 1. I’m willing to absorb the extra support costs that come with each upgrade because I think the additional revenue during our busy season will outweigh them. I also believe that we shouldn’t hold back our current features for these two other features, no matter how great they are! I don’t care if they’re pure gold, we already have so many highly requested features that I’d like to get them out there now rather than later. The other two features are important enough to me that I don’t want to wait until another major version, I’d rather release them as another upgrade in 2-3 months. They’re big enough to warrant an upgrade rather than a patch, but I’m not willing to wait for the next major release.
Which option would you take with these assumptions?
Permalink to this article Discussions (9)
Business versus Technical Solutions
Last week I published an article here entitled “LandlordMax’s Most Challenging Bug” which received lots of comments both online and through personal emails (probably more people sent emails than commented). One thing that really struck me was the difference in thinking between people who run a business (from small ISV owners to managers) and technical people (developers, architects, etc.). Based on their background the solutions varied substantially. I’m not talking how to tackle the problem technically (btw there were some great tips and information being shared, thank you!), there was no doubt there was a lot of variation here, but I’m talking in terms of what types of solutions made economical sense.
What really struck me is that most developers completely ignored the cost to benefit side of the equation! I’m not saying that you should always base your decision on cost to benefits (I don’t want to acquire design debt for example), but sometimes this becomes a strong factor in the decision making. This is something that I use to lack, I always wanted to get in there and find the correct technical solution. The reality is that sometimes it’s not the right thing to do. This is a hard pill for technical people to swallow. I know it use to be for me. Not so much anymore being a lot more on the business side of things, but in the past it was a common issue.
Using my last article as a basis for this argument, let’s look at the cost to benefit of different types of solutions. Not actual solutions, but cost to benefits of the types of solutions. Rather than share my actual numbers, let’s just round realistic numbers to make the calculations, it’ll be much easier that way. So our first assumption is that allocating a developer to a task for 1 full day will cost $1000 in immediate salary. We should of course add in the costs of benefits, hardware, software, training, testing, etc., but for now let’s just say it’s $1000/day for a developer. Now remember this cost does not include any testing!
Ok, now I’ll assume that our fictional company makes $1 million in revenue a year, a simple round number. Assuming we have a unit price of $150 per unit, then this means we sell 6667 units per year.
Now before I proceed, let me backtrack a little. For those of you who are interested, you can read the full article here. However, just to get everyone up to speed, here’s the quick version. We found a bug in LandlordMax regarding how it reads certain types of JPG images. This bug is also present in many larger software application such as Internet Explorer and FireFox, so it’s not a simple solution. Also, images aren’t part of our core functionality. Don’t get me wrong, they’re a great feature, but we didn’t have them in the first 3 major versions. Now the problem is that we have two solutions, one that’s quicker to implement and one that isn’t. This problem only affects 0.05% of our total customers, and of those 90% will be satisfied with this solution. The other solution is complex, will take more than a week or two, and probably won’t fully work (IE and FireFox with very large resources still don’t have it full working). This solution will satisfy 90% of those customers too, possibly more.
Using these parameters, we can see there are two sides to this coin. Most technical people will want to fully solve the issue, to get it right. Yes the costs are high, but let’s do it right. The business side want’s to see what’s the cost to benefit. Now just a quick side step, you have to remember that you can’t always just look at the cost to benefit otherwise you’ll get so far into design debt that you’ll eventually kill your company. However, in this case, we’re not very likely to expand on this issue once it’s solved so it’s very unlikely that we’ll add any design debt no matter what solution we decide.
In any case, let’s look at the two solutions.
Solution 1:
An acceptable solution to the problem which will take about 1/2 a developer day, padded to 1 full day for safety. In this case, the cost is $1000. Now if we calculate it terms of cost to benefit, it means we’re paying $1000 for 0.05% of our 6667 customers, or 333 customers. On average, this means that we’re paying $3.33 to add this solution for these customers, of which 90% will be ok with the solution. The remainder would like a better solution but will probably live with it since this is only a small part of why their using the software, after all this is not the core functionality of the software. Also remember that these few people who are used to using this type of image mode also use to having this issue with a number of other major software applications. So it’s nothing new.
Solution 2:
We provide as best a technical solution as we can, knowing that we probably won’t be able to solve it fully as other software companies with budgets multiple orders of magnitude bigger larger than our total revenue can’t solve it. We’d be lucky to spend only a week, probably 2 weeks, and this might only reduce the number of people facing the issue by a percentage. But let’s be optimistic and say that we’ll solve it for 90% of the people who use this image mode.
Then in this case, we’ll spend 10 developer days, $10,000, to solve it. This means that it costs us $10,000 for our 333 customers. On average, this means we spend $30 per customer on this solution alone. This is now a significant percentage of the purchase price (20% of the total purchase price for fixing a small bug). But again, remember that it’s only for 90% of these 333, so we’re only really solving it for 300 people, bringing our per customer solution price to $33.33, or 22% of the total purchase price. We still have to deal with the remainder 10%, or 33 people. Assuming we use solution 1 for the remainder, this now brings up our price to $11,000, $10,000 for the initial solution and $1,000 for the remainder. Our total price per customer is now $33 for just this bug fix, or 22% of the total purchase price.
Which Solution is Right?
Which of these two solutions would you be more inclined to implement from a business side? What about from a technical side?
From a technical side, at least from my experience, we always want the perfect solution. But from a business side, it makes a lot more sence to go with solution 1. And don’t forget, solution 2 is probably a lot more costly than we estimated, it might take us a month, maybe two, or what if it’s a never ending series of issues? If the solution takes two months, which is not so hard to imagine once you see how Mozilla (FireFox) solved it (and that’s not even fully working), that brings our cost per customer to approximately $120 per customer. We’re now at 80% of the total purchase price for just one bug fix that’s not critical! Yes it’s only a portion of the customer, yes we could amortize it, yes we could calculate in the total lifetime purchases of the customer, and so on. But looking at the numbers when the first scenario is perfectly acceptable, I just can’t see how I can justify scenario 2.
As a developer, I can easily find ways to justify solution 2 such as design debt, etc. But from a business perspective solution 2 makes no sense!
UPDATE: Now add to solution 1 the fact that we now have an additional 9-10 developer days to add more features and benefits to the software. Let’s say we can increase our sales by 2% by instead allocating this same developer for the time difference to a new highly requested feature (maybe it’s only 1%, maybe it’s 10%, in any case, we’ll just use 2% since it’s easily feasible). If that’s the case, we can increase our sales of $1 million to $1,020,000, or by $20,000. Now not only have we paid for our bug fix, we’ve also paid for our developer and made a profit!
And the thing to remember here is that we’re not just helping 0.05% of the people (which we are), we’re also making 100% of the all our customers happier with a new feature (well maybe not 100%, but a much much larger percentage than 0.05%) that they wanted!
Permalink to this article Discussions (13)
Is Technical Phone Support a Viable Option for a Software Company?
Yes and no.
Yes, in that it lets you get closer to your customers. There’s nothing quite like talking to your customers one on one to find out exactly what they think of your product, of your company, how they found you, and everything else. Having a phone number also gives some credibility to your company.
No, because phone support is extremely costly. Most people don’t realize it, but phone support is several times more expensive than online support for the same customer base! As well, although it increases the sales, it’s nowhere near in proportion to the extra costs. I now understand why pretty much every software company charges for phone support.
So is it a viable option? Maybe… Rather than debate the hypothetical, I’m going to share our latest experience with free phone support and our prototype project here at LandlordMax. There’s nothing better than a case study! The results might be different for you and your company, but this is what happened for us.
When I first started LandlordMax, I offered support through email only. In the beginning it was pretty simple, I could manage it all through my email client. As the company grew, the support needs grew where we ended up purchasing a customer support system called FogBugz (allowing multiple people to manage support through a web application). As our needs continued to grow and exceeded even this software (we still actively use it for project management and bug tracking, it’s strong suite), we moved up to HelpSpot which is focused on customer service. This is an online system which accepts requests by email, through online forms, etc. All requests are allocated a ticket number and everyone also receives an online link where they can view the details of the request directly online if they want (including every detail, from how long it took to respond, and so on). This is great because it alleviates a lot of the issues with people who have very aggressive spam filters (because we’re a real estate based business, sometimes we need to use words such as “mortgage”, etc., which are often wrongly picked up as spam by email filters).
Because of the way our customer service system works, we’re able to offer free unlimited online support which is guaranteed to be answered within 1-2 business days (generally we answer it on the same day). This is great because most of our competitors charge for ANY support, and some quite a bit! Never mind phone support which I’ll get to in a minute.
About three months ago we decided that we wanted to start offering free phone support to our customers. Up until now, that is for the past 3-4 years, as I just described, we’ve been offering online support only (email, web forms, etc.). We wanted to see if it made a difference, how much, and if we could offer it for free. You see, although I could charge for phone support like our competitors, I really don’t like this option. To give you an idea of the market, most of our competitors charge between $100-200/hour for phone support!!! Some only offer email support if you buy a support contract. Another competitor will only sell you their software if you also buy a minimum support service package of $200! Personally I don’t believe in this. If you buy a product, you shouldn’t have to pay to get some help in answering your questions. I understand there is a place for premium support, for example a guaranteed response within 24 hours, etc., but this wasn’t out goal today.
I also do understand the business behind it, phone support does cost money. And let me assure you, it really does cost quite a bit. Not just in technology or service costs, but in man-hours! Man-hours are your largest cost factor, no doubt about it. Anyways, what we decided to do was offer free unlimited phone support for 3 months as a trial experiment to see if it was a viable option for us. Hopefully by offering phone support this would increase our customer’s happiness, and hence increase our sales. We also decided to use 3 months because it gives it some time to build momemtum As well, perhaps we’d also be able to add some extra sales from people who were more timid about purchasing software from a website and would rather purchase it over the phone.
That was three months ago. Today I know the results. So let’s look at the results of our experiment. Although I’m not going to share the detailed metrics, here’s a summary of what happened:
- The average time to support a customer increased significantly over the phone versus online support. There’s nothing wrong here, it’s just the way it is. I would say that on average the time spent responding to a customer increases by 2-10 times. This can be attributed to the fact that some people ask more questions on the phone, some wish for you to wait while proceeding through the steps (for example waiting for the purchase email to make it through), sometimes you wish to wait to verify that the customers issue is fully resolved, and so on. Overall I would say this is fairly accurate metric for us.
- For each person who answers the phone you need to train them in your software. This includes how it works, how to properly answer questions, what the procedures and policies are, etc. To achieve a good support level this is not a small task.
- With phone support, although we don’t promise an immediate answer (we keep the same guarantee of 1-2 business days), phone calls break people’s workflow, their rhythm. For every break in concentration expect between 15-30 minutes of lost time to get back to the same productive state. With online support this can be drastically reduced by answering requests in batches during breaks, or what we list to call “mental breaks” (where you need to look at something different to give you brain a break). By doing this we keep all support responses in blocks and greatly increase overall productivity!
- Long distances phone charges do add up… We’re using a VOIP system but that’s also not without it’s own costs.
- Sales have increased, but nowhere near in proportion to the extra costs (especially if you add in the time costs). I’d say that we’ve barely increased sales by 10% and almost multiplied our support costs by 5-6 times. Therefore it doesn’t make sense to spend 5-6 times more money to make 10% more!
- One thing that you really benefit from is that you get real live customer feedback about your software. I personally found that when I was on the phone, people told me a lot more about what they liked and didn’t like about the software right away. They also told me what their biggest pains where, which is golden! Which features do you think we’re going to add next? Probably where our customers biggest pains are!
Therefore, weighing in the pros and cons, it looks like we’re going to discontinue free phone support. Actually at this time, we’re going to discontinue all phone support. We’ll probably try it again in the future, things do change, but for now it just doesn’t make economical sense.
I can already hear some people saying why don’t you just offer paid phone support for those customers who want it. This way you don’t have to build it into your price and those that are interested can pay. The reality is that I’ve found that only about 7% of our customers (combined with pre-sales) use phone support. I can’t speak for every industry, but assuming these numbers, and the fact that we’d have to charge, I believe that the total percentage of people who would use paid phone support would drop significantly. Because there is a minimum fixed cost associated to having a call center, we’d still have to charge a minimum fee per call to just cover the costs. Assuming only 10% of the people who use phone support would be willing to pay the fee (I’d guess around $100/hour), then that would mean 0.7% of all customers would use this service. I’m not willing to risk the significant amount of capital it would take (we’d now also have to add a billing system to our phone system) to support 0.7% of our customers. At that point, unfortunately, I’d have to welcome them to purchase from our competitors.
As you can see, it’s not that I don’t want to offer phone support for LandlordMax, it’s just that it’s not a viable option for us. And yes I understand that some people will not purchase anything from a company that doesn’t offer phone support, but that’s ok. I’m willing to lose that very very small percentage of customers. Assuming they’re 10% of the 0.7% of customers willing to pay for phone support, we’d be losing 0.07% of our potential customers.
Therefore, to answer the question based on our experiment, is it viable for software companies to offer technical phone support. Again the answer is yes and no. It depends on your market and who you are:
Software under $100
I seriously doubt you can do it for free. I also doubt you can charge for it either! Unless you have economies of scale and you can seriously amortize your costs, no one is going to pay you the price of your software for assistance! And if you did offer phone support, it couldn’t be more than one call for free at best, if that. I looked up Quicken, a large company that can use the advantage of economies of scale, and they only offer free phone support for installation, purchase related questions, etc. After that, any help within the software (for example how to setup a bank, etc.) will cost you $24.95 per issue, or 86% of the purchase price!
Software between $100-$250
You’d still be hard pressed, but you might have a chance. Of course you could only offer one incident at most, and every additional call would have to be charged. Also if your company is smaller than a medium sized company ($10 million plus in annual revenue), I just don’t see how you could offer free phone support.
Software between $250-$1000
Possibly. Here’s where it gets interesting. I think in this case the industry and specifics of the software will determine whether you can or not. To give you an idea of just how difficult it still is at this level of pricing, Microsoft Office only offers you two free phone support sessions and then they charge you $35 per additional incident, all this for a product that costs $399 for the “standard” edition!
Software over $1000
Generally software over $1000 comes with some sort of SLA (Service Level Agreement). The more expensive the more comprehensive the agreement. Under $5000 it will be somewhat limited, but over $30,000 it becomes generally becomes much more comprehensive (before LandlordMax I had only worked with one company that sold software for under $30,000). Often in these markets there are a limited number of customers, and the vast majority are corporations where phone support is expected as part of the SLA (wouldn’t you expect it if you paid $1 million for a software package).
So all said and done, looking at our cost to benefit ratios, it looks like we’ll have to end our phone support for now. There’s not much to debate about. Like I said earlier, we’ll probably try it again in the future, maybe next year… I don’t know. But for now, we’re going to go back to online support only (email, online forms, etc.). I just can’t justify the substantial extra costs for the amount of extra revenue it provides. This would be like asking a landlord to build a private pool for each apartment unit to generate an extra 10% in revenue. It just wouldn’t make sense, landlords don’t do that.
To quickly end the discussion, since I know some people will ask, do you regret experimenting with offering phone support? Absolutely not! I think every business is different, and every business should try it! You can’t grow without trying. Michael Jordan didn’t just start scoring baskets on day one, he tried a lot of things before he figured out just what worked for him. So try things, test what works and doesn’t for your company. Maybe you’ll have very different results than we did at LandlordMax. Please comment if you did, I’d love to hear about it.
Permalink to this article Discussions (15)
How Much Effort is There in Each Software Update?
Software releases generally come in two flavors, updates and upgrades. Updates are small changes where the version number barely changes and mostly consists of bug fixes, enhancements (perhaps performance), and possibly some new small features. Upgrades are generally considered major releases and often the first number of the version changes. These include major enhancements and lots of new features. Now everyone knows a lot of work goes into major new upgrades, there’s no doubt when you look at the list of new features. But what about updates? How much effort is involved in releasing updates? More than most people realize!
I just took a look at all the updates we released for LandlordMax Property Management Software version 2.12, which is now at version 2.12e, and it was quite lengthy as you can clearly see from this list of new features and fixes for each update. What’s the best metric to show how much effort was involved? That’s very debatable. One could argue LOC (Lines of Code) but that’s very skewed.
To give you a quick idea of why that’s skewed, let’s take a look at some of the huge performance enhancements we did for version 2.12c. Between version 2.12b and version 2.12c, as you can see from the graph below, we added about 250 new lines of code. Very few. But if you look at the effort, it took us many man hours to accomplish, probably more than all the other updates combined! So why so few lines of code? Because we removed as much if not more software code than we added. On top of this, a lot of the time we made modifications to existing code (for example optimizing the database queries), where we didn’t add or remove any code but just changed it. Version 2.12c was by far the update that required the most effort but this isn’t accurately reflected in the lines of code…
I can already see the next question, what about just measuring the total amount of time taken to implement each new update rather than using lines of code as a metric? That would be great except that we don’t really keep track here at LandlordMax of what we do in that kind of detail. I don’t know myself if I’ve spent two hours on this, then three hours on that. I know the total amount of time I spend working on LandlordMax, but I don’t know exactly on what. And to be honest, I don’t want to subject myself to this level of time tracking (even daily tracking) just to have metrics, it’s a waste of time and money. I’d rather spend that time adding more features to the software. I’m not billing a client, I’m trying to produce a software product, therefore the details of where the time is spent is not as important as building a quality product. With that being said, I do have a good idea of how much time each update took, a good guess-estimate. And I can tell you that version 2.12c was the largest by far.
In any case, I can only use the best metric I have in hand since I don’t have enough details to graph the time spent per update. Although this is not entirely accurate it’s the best I can do. That being said, it’s interesting to note that between the initial release of version 2.12 and the final release of version 2.12 (version 2.12e), we’ve added over 2000 lines of code. Assuming 40 lines per page, that’s 50 pages of new code. And remember, that’s not counting how much code has been modified, how much code has been replaced, etc.
So to answer the original question, how much effort is there in each software update? A lot! Based on the previous releases using only the lines of code as a metric, I can assure you that if we based it on time it would be a much larger percentage, we’ve added 10% as much code as a brand new full version upgrade release to the updates!
Permalink to this article Discussions (7)
What's the Difference Between a Major Software Release and a Software Update?
As far as I’m concerned, an update should only consist of bug fixes or improvements in the software (performance, etc.), it should not include any new features. Major and minor software releases include the same fixes as updates, but they also include new features and functionality. This is what and ideal world would be for me, but the reality is not quite so black and white as you’ll soon see from my examples using my company LandlordMax Property Management Software.
Just a quick addendum for those of you who aren’t as familiar with LandlordMax Property Management Software, the way we do release versions is Year.Month. Year being how many years since the first version, and month being the month of the year. So if we were to release this month, it would be version 3.09, next month version 3.10, and so on. We do this because we offer one year of free upgrades to all releases of LandlordMax with each purchase, major and minor.
So why isn’t it so black and white? Sometimes it’s nice to add a quick little feature to an update to help our customers. We just can’t wait until the next major release, we want to offer it now! Maybe many of our customers requested it and we’d like to oblige them rather than make them wait for a full release, of even a minor release. For example, one feature we added to an update of version 2.12 (version 2.12a) was the ability to sort building units in a way that made much more sense to our customers.
Initially we had the units sorted alphanumerically, but this didn’t make sense to our customers. For example you’d get:
10a
10b
11c
1a
22a
2a
3b
Whereas what you really wanted was:
1a
2a
3b
10a
10b
11c
22a
You’ll notice that 2a is before 10a, which if you do an alphanumeric sort this is not the case. A small modification but it had a lot of implications to our users. This really helped them in searching for units because it makes more sense if you think about it from their perspective!
The biggest “enhancement” we did though was to greatly improve the performance of LandlordMax. Now should this be considered an update or a new release? This is debatable, and we went the view that this was an enhancement, hence an update (I’ve seen many software vendors use this as an excuse to launch a new release). But let me tell you this was no small feat, it involved many man hours!
Why didn’t we just release it as another minor update, say from version 2.12 to version 3.03, or something like that? Because if we did that, everyone who purchased the software that was eligible up to version 3.02 would not be able to receive this update. Was it significant enough for them to purchase an upgrade? Not likely, not unless they had a substantially large database. Was it worth it for them to upgrade? Yes, especially if they had larger databases. So it was worth an update but I doubt many would have paid for an upgrade, it wasn’t enough to validate the expense. But we wanted to release it sooner than later since it significantly affected our larger customers (we have many larger customers), and all our new potential customers trying out the software for the first time. Hence in this case we opted for an update.
This week we were faced with another situation. I was talking to one of our potential customers on the phone and he brought up a very good point. He had a 150 unit building, and was looking to add two more 150 unit buildings within the next few months. His issue was that he had to enter in all the tenant lease information AND all the scheduled accounting entries for those leases. Now I don’t know about you, but I could sure appreciate his argument of not wanting to enter in the same 450 similar pieces of information twice! He did suggest that he could have one of his clerks do it, but that would take time away from their other tasks, and I completely agree. This lead to the discussion of having the software automatically generate the scheduled accounting entry for each new lease when it’s initially saved for the first time. This is a great feature, one that we had planned on implementing before but that had been pushed back due to resource limitations. We only have so many resources and we try our best to implement the most sought after features and requests. In any case, I completely agreed with this gentleman, this is a feature that should be in the software sooner than later. After hearing his plight, I decided we could no longer wait for this feature, we needed to add it now rather than later.
Now here’s the dilemma, we’re also nearing another update release of version 2.12, version 2.12f. This update is mainly another performance update on the data entry screens. What we’ve done is cached all the combo box (drop down menu) items to avoid a lot of unnecessary database calls. If you have a database like the sample database I’m creating for the showcase video, this can result in a lot of extra processing that’s not really necessary. For example the tenant combobox can be easily cached, especially if you consider how often the tenant list changes versus how often we render that combobox (almost every data entry screen). This provided a significant performance increase to data screens with large databases (in my test case, this was 2659 tenants that didn’t need to be extracted from the database each time! We’ve done the same with all the major comboboxes and it made a noticeable change. The improvement went from 2-3 seconds to a virtually instantaneous display of all the data entry screens, with the exception of when there is an update to be made. If you’ve studied Graphical User Inteface (GUI) disciplines, you know that anything above 2 seconds agitates the users and makes them think the software is not responding. A significant improvement!
As I was saying, the dilemma is that if we’re about to release an update anyways in the near future, should we just tack on this new lease feature? It’s easy to say yes, but you have to remember that each new feature does cost us money to implement. And if we add that one feature, why not another one that’s really beneficial. For example we could also add the ability to convert suggested accounting entries that are late as accounting entries with no amount paid and no date paid (this is beneficial because if after a certain number of days your tenants haven’t paid you, you want to quickly take all the suggested accounting entries and mark them as unpaid. If you have a lot of these, it can take quite some time to manually edit the amounts and dates one by one)? What about adding a few new reports? This could be considered a minor upgrade. The dilemma is that, assuming we release next month, it will have been 10 months since our last release (not counting updates). Is a few new features in a year enough to warrant an upgrade? Will enough people whose license have expired purchase an upgrade? I don’t know, but I’d prefer to really make a convincing argument for an upgrade by giving them much more value than the cost of the upgrade! That’s just me.
So what are we to do? Do we give away more new feature for free as an update? Do we release a minor release after 10 months with only a few new features and performance enhancements? Will it be worth it for enough customers to purchase the upgrade and benefit from it? I don’t think either of these options is really any good… So the answer is I don’t know.
What we did decide though is that we’ll release a major update rather than a minor update very soon. Rather than just working on the 2.12 branch and adding the features there, we’ll release all the new features we’ve already implemented and tested for version 3.xx. We’d of course like to get all the new features we planned for that release, but instead what we’ll do is cut it a bit short and release it with everything we’ve already implemented (which is no small list). We’re going to do this because I believe there’s enough new value already implemented that most of our existing customers whose license is going to expire with the new major release will find more than enough value in it to buy the upgrade. By the way, just as a quick plug, remember that upgrades are discounted at 50% of the current price. Anyways, I know if it was me I’d prefer to have all the new features we’ve already implemented as part of a major upgrade, and there’s some great new features and benefits in there! If everything goes according to plan, we’re hoping to have the next major release available something in October as version 3.10! I’m not promising anything, but that’s what we’re currently anticipating.
Permalink to this article Discussions (0)
| « PREVIOUS PAGE |
