Monthly Archives: April 2008

Getting customer feedback

Lack of feedback is one of the most difficult things about caring for a small child. You know they are unhappy because they are crying. But you don’t know if that unhappiness is due to: hunger, thirst, too hot, too cold, ear ache, stomach ache, wind, tiredness, boredom, teething or something else. They can’t tell you, so you can only guess. Creating software without feedback is tough for the same reasons. You know how well or badly you are doing by the number of sales, but without detailed feedback from your customers and prospective customers, it is difficult to know how you could do better.

The importance of feedback is amply illustrated by many of the stories of successful companies in the excellent book “Founders at work” by Jessica Livingston. For example, PayPal started out trying to sell a crypto library for the PalmPilot. They went through at least 5 changes of direction until they realised that what the market really wanted was a way to make payments via the web.

So good feedback is essential to creating successful software. But how do you get the feedback?

Face-to-face meetings

Meeting your customers face-to-face can give you some detailed feedback. But is time consuming and doesn’t scale when you have hundreds or thousands of customers. You can meet a lot of customers at a exhibitions, but it hardly an ideal venue for any sort of in-depth interaction. Also, they may be too polite to tell you what they really think to your face.

Technical support

Technical support emails and phone calls are a gold-mine of information on how you can improve your product. If one customer has a particular problem, then they might be having a bad day. But if two or more customers have the same problem, then it is time to start thinking about how you can engineer out the problem. This will both improve the utility of your product and reduce your support burden.

In order to take advantage of this feedback the people taking the support calls need to be as close to the developers as possible. Ideally they should be the same people. Even if you have separate support and development staff you should seriously think about rotating developers through support to give them some appreciation of the issues real users have with their creation. Outsourcing your support to another company/country threatens to completely sever this feedback.

Monitoring forums and blogs

Your customers are probably polite when they think you are listening. To find out what they really think it can be useful to monitor blogs and relevant forums. Regularly monitoring more than one or two forums is very time-consuming, but you can use Google alerts to receive an alert email whenever a certain phrase (e.g. your product name) appears on a new web page. This feedback can be valuable, but it is likely to be too patchy to rely on.

Usability testing

A usability test is where you watch a user using your software for the first time. You instruct them to perform various typical tasks and watch to see any issues that occur. They will usually be asked to say out loud about what they are thinking to help give you more insight. There really isn’t much more to it than that. If you are being fancy you can video it for further analysis.

Usability tests can be incredibly useful, but it isn’t always easy to find willing ‘virgins’ with a similar background to your prospective users. Also the feedback from usability tests is likely to be mainly related to usability issues, it is unlikely to tell you if your product is missing important features or whether your price is right.

Uninstall surveys

It is relatively easy to pop-up a feedback form in a browser when a user uninstalls your software. I tried this, but got very few responses. If they aren’t interested enough in your software to buy it, they probably aren’t interested enough to take the time to tell you why. Those that I did get were usually along the lines “make it free”[1].

Post purchase surveys

I email all my customers approximately 7 days after their purchase to ask whether there is anything they would like me to add/improve/fix in the next version of the software. The key points about this email are:

  • I give them enough time to to use the software before I email them.
  • I increase the likelihood of getting an answer by keeping it short.
  • I make the question as open as possible. This results in much more useful information than, say, asking them to rate the software on a one to ten scale.
  • I deliberately frame the question in such a way that the customer can make negative comments without feeling rude.

The responses fall into five categories[2]:

  1. No response (approx 80%). They didn’t respond when given the opportunity, so I guess they must be reasonably happy.
  2. Your software is great (approx 10%). This really brightens up my day. I email them back to ask for permission to use their comment as a testimonial. Most people are only too happy to oblige.
  3. Your software is pretty good but it doesn’t do X (approx 10%). Many times my software actually does do X – I tell them how and they go from being a satisfied customer to a very happy customer. Also it gives me a pointer that I need to make it clearer how to do X in the next version. If my software doesn’t do X, then I have some useful feedback for a new feature.
  4. Your software sucks, I want my money back (rare). Thankfully I get very few of these, but you can’t please all of the people all of the time. Sometimes it is possible to address their problem and turn them from passionately negative to passionately positive. If not, I refund them after I get some detailed feedback about why it didn’t work for them[3].
  5. Stop spamming me (very rare). From memory this has happened once.

I consider them all positive outcomes, except for the last one. Even if I have to make a refund, I get some useful feedback. Anyway, if you didn’t find my software useful, I don’t really want your money.

Being pro-active like this does increase the number of support emails in the short-term. But it also gives you the feedback you need to improve your usability, which reduces the number of support emails in the longer term. I think the increased customer satisfaction is well worth the additional effort. Happy customers are the best possible form of marketing. Post-purchase emails are such a great way to get feedback, I don’t know why more people don’t use them. Try it.

If you make it clear that you are interested in what your customers have to say they will take more time to talk to you. If you act on this feedback it will improve your product (some of the best features in my software has come from customer suggestions). A better product means more customers. More customers means more feedback. It is a virtuous cycle.

All you have to do is ask.

[1] Only if you pay my mortgage. Hippy.

[2] The percentages are guesstimates. I haven’t counted them.

[3] My refund policy specifies that the customer has to say what they didn’t like about the software before I will issue a refund.

Business of Software FAQ

As a regular on FogCreek’s Business of Software forum I see the same questions come up time and again.

  • How do I do SEO?
  • How do I improve my return on Adwords?
  • Which hosting company should I use?
  • Which payment processor should I use?
  • etc.

So I have quickly thrown together a BOS FAQ page in an attempt to raise the level of debate. Hopefully other people will add it to it. Even if you don’t read the forum you might find some of the links useful.

Radical new software business model

David Heinemeier Hansson of 37Signals espouses a radical new business model: create something people want, then charge them money to use it.

The secret to making money online (video, 32 minutes)

I think it is well worth watching, especially if you have been brainwashed into the prevailing VC-funded, Facebook-or-bust, flip-it-before-we-run-out-of-cash mentality. If you still aren’t convinced, read this post by Dennis Forbes.

Selling your software in retail stores (all that glitters is not gold)

Selling your software in retail storesDevelopers often ask in forums how they can get their software into retail. I think a more relevant question is – would you want to? Seeing your software for sale on the shelves of your local store must be a great ego boost. But the realities of selling your software through retail are very different to selling online. In the early days of Perfect Table Plan I talked to some department stores and a publisher about selling through retail. I was quite shocked by how low the margins were, especially compared with the huge margin for online sales. I didn’t think I was going to make enough money to even cover a decent level of support. So I walked away at an early stage of negotiations.

The more I have found out about retail since, the worse it sounds. Running a chain of shops is an expensive business and they are going to want take a very large slice of your cake. The various middlemen are also going to take big slices. Because they can. By the time they have all had their slices there won’t be much left of your original cake. That may be OK if the cake (sales volume) is large enough. But it is certainly not something to enter into lightly. Obviously some companies make very good money selling through retail, but I think these are mostly large companies with large budgets and high volume products. Retail is a lot less attractive for small independents and microISVs such as myself.

But software retail isn’t an area I claim to be knowledgeable about. I just know enough to know that it isn’t for me, at least not for the foreseeable future (never say never). So when I spotted a great post on the ASP forums about selling through retail, I asked the author, Al Harberg, if I could republish it here. I thought it was too useful to be hidden away on a private forum. He graciously agreed. If you decide to pursue retail I hope it will help you to go into it with your eyes open. Over to Al.

In the 24 years that I’ve been writing press releases and sending them to the editors, more than 90 percent of my customers have been offering software applications on a try-before-you-buy basis. In addition, quite a few of them have ventured into the traditional retail distribution channel, boxed their software, and offered it for sale in stores. This is a summary of their retail store experiences.

While the numbers vary greatly, a software arrangement would have revenues split roughly:

  • Retail store – 50 percent
  • Distributor – 10 percent
  • Publisher – 30 to 35 percent
  • Developer – 5 to 10 percent

Retail stores don’t buy software from developers or from publishers. They only buy from distributors.

The developer would be paid by the publisher. In the developer’s contract, the developer’s percentage would be stated as a percentage of the price that the publisher sells the software to the distributor, and not as a percentage of the retail store’s price.

The publishers take most of the risks. They pay the $30,000(US) or so that it currently takes to get a product into the channel. This includes the price of printing and boxing the product, and the price of launching an initial marketing campaign that would convince the other parties that you’re serious about selling your app.

If your software doesn’t sell, the retail stores ship the boxes back to the distributor. The distributor will try to move the boxes to other dealers or value-added resellers (VARs). But if they can’t sell the product, the distributors ship the cartons back to the publisher.

While stores and distributors place their time at risk, they never risk many of their dollars. They don’t pay the publisher a penny until the software is sold to consumers (and, depending upon the stores’ return policies, until the product is permanently sold to consumers – you don’t make any money on software that is returned to the store, even though the box has been opened, and is not in good enough condition to sell again).

The developer gets paid two or three months after the consumer makes the retail purchase. Sometimes longer. Sometimes never. If you’re dealing with a reputable publisher, and they’re dealing with a major distributor, you’ll probably be treated fairly. But most boilerplate contracts have “after expenses” clauses that protect the other guys. You need to hire an attorney to negotiate the contract, or you’re not going to be happy with the results. And your contract should include an up-front payment that covers the publisher’s projection of several months’ income, because this up-front payment might well be the only money that you’re going to ever see from this arrangement.

Retail stores’ greatest asset is their shelf space. They won’t stock a product unless there is demand for it. You can tell them the most convincing story in the world about how your software will set a new paradigm, and be a runaway bestseller. But if the store doesn’t have customers asking for the app, they’re not going to clutter their most precious asset with an unknown program.

It’s a tough market. It’s all about sales. And if there is no demand for your software, you’re not going to get either a distributor or a store interested in stocking your application. These folks are not interested in theoretical demand. They’re interested in the number of people who come into a retail store and ask for the product.

To convince these folks that you’re serious, the software publisher has to show a potential distributor that they have a significant advertising campaign in place that will attract prospects and create demand, and that they have a press release campaign planned that will generate buzz in the computer press.

Many small software developers have found that the retail experience didn’t work for them. They’re back to selling exclusively online. Some have contracted with publishers who sell software primarily or exclusively online. Despite all of the uncertainties of selling software online, wrestling with the retail channel has even more unknowns.

Al Harberg

Al Harberg has been helping software developers write press releases and send them to the editors since 1984. You can visit his website at

Chinese domain scam

I got this email yesterday:

Dear Sir

We received a formal application from a company who is called Meiao Investment Co.,Ltd are applying to register “ oryxdigital” as their domain name and Internet keyword in China and also in Asia on Apr 17 2008. During our auditing procedure we find out that the alleged Meiao Investment Co.,Ltd has no trade mark, brand nor patent even similar to that word. As authorized anti-cybersquatting organization we hereby suspect the alleged Meiao Investment Co.,Ltd to be a domain grabber. Hence we need you confirmation for two things,

First of all, whether this alleged Meiao Investment Co.,Ltd is your business partner or distributor in China.

Secondly, whether you are interested in registering these domains. (The alleged Meiao Investment Co.,Ltd will be entitled to obtain a domain not needed by original trademark owner.)

If you are not in charge of this please transfer this email to appropriate dept.

This is a letter for confirmation. If the mentioned third party is your business partner or distributor in China please DO NOT reply. We will automatically confirm application from your business partner after this audit procedure.

Bst Rgs


Registration Commissioner

Beijing HA ZD Networks Science and Technology Co., Ltd

Tel: +86-10-82772601

Fax: +86-10-82773610

Needless to say, it’s yet another scam. The “Meiao Investment Co” (if they even exist) have no interest in my domain. I am guessing the scammer just wants me to pay good money for a worthless .cn domain. Sigh. More details here.

Hopefully somebody Googling “Meiao Investment Co” or “” will find this post and save themselves a few dollars.

Update 28-Oct-13: Christopher Hofman Laursen contacted me to say he has published a list of 200 Chinese domain name scammers at: .

Über bloggers Jeff Atwood and Joel Spolsky are joining forces to launch .

According to Jeff Atwood:

Stackoverflow is sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit. It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

According to Joel Spolsky:

We’re starting to build a programming Q&A site that’s free. Free to ask questions, free to answer questions, free to read, free to index, built with plain old HTML, no fake rot13 text on the home page, no scammy google-cloaking tactics, no salespeople, no JavaScript windows dropping down in front of the answer asking for $12.95 to go away. You can register if you want to collect karma and win valuable flair that will appear next to your name, but otherwise, it’s just free.

There is nothing there yet, apart from a podcast. But, with their combined talents and high profiles, it could be a great resource for software developers. I will be watching with interest.

Functional programming – coming to a compiler near you soon?

We can classify programming languages into a simple taxonomy:

Commercial programmers have overwhelmingly developed software using imperative languages, with a strong shift from procedural languages to object oriented languages over time. While declarative style programming has had some successes (most notably SQL), functional programming (FP) has been traditionally seen as a play-thing for academics.

FP is defined in Wikipedia as:

A programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

Whereas an imperative language allows you to specify a sequence of actions (‘do this, do that’), a functional language is written in terms of functions that transform data from one form to another. There is no explicit flow of control in a functional language.

In an imperative language variables generally refer to an address in memory, the contents of which can change (i.e. is ‘mutable’). For example the rather unmathematical looking “x=x+1” is a valid expression. In FP there are no mutable variables and no state.

In an imperative language a function can return different values for the same input, either because of stored state (e.g. global or static variables) or because it is interfacing with an external device (e.g. a file, database, network or system clock). But a pure functional language always returns the same value from a function given the same input. This ‘referential integrity’ means an FP function call has no ‘side-effects’ and consequently can’t interface with external devices. In other words it can’t actually do anything useful – it can’t even display the result of a computation to your VDU. The standard joke is that you only know a pure functional program is running because your CPU gets warmer.

The functional language Haskell works around the side-effects issue by allowing some functions to access external devices in a controlled way through ‘monads’. These ‘impure’ functions can call ‘pure’ functions, but can never be called by them. This clearly separates out the pure parts of the program (without side-effects) from the impure ones (with side-effects). This means that it is possible to get many of the advantages of FP and still perform useful tasks.

FP is much closer to mathematics than imperative programming. This means that some types of problems (particularly algorithmic ones) can be expressed much more elegantly and easily as functional programs. The fact that a function has no side effects also means that it’s structure is much easier to analyse automatically. Consequently there is greater potential for a computer to optimise a functional program than an imperative program. For example in FP:

y = f(x) + f(x);

Can always be rewritten as:

z = f(x);

y = 2 * z;

Saving a function call. This is more difficult to do in an imperative language, because you need to show that second call to f(x) won’t return a different value to the first.

Functional programs are also inherently much easier to parallelise, due to the lack of side-effects. We can let the FP interpreter/compiler take care of parallelism. No need to worry about threads, locks, critical sections, mutexes and deadlocks. This could be very useful as processors get ever more cores. However imperative languages, with their flow of control and mutable variables, map more easily than functional languages onto the machine instruction of current (von Neumann architecture) computer. Consequently writing efficient FP interpreters and compilers is hard and still a work in progress.

Elements of FP are steadily making their way into mainstream commercial software:

  • Erlang is being used in commercial systems, including telecoms switching systems.
  • Microsoft Research has implemented F#, a .Net language that includes FP elements based on ML.
  • Work is underway to add elements of FP to version 2.0 of the D programming language.
  • Google’s MapReduce is based on ideas from FP.
  • The Mathematica programming language has support for FP.
  • The K programming language is used in financial applications.
  • The Perl 6 compiler is being written in Haskell. <insert your own sarcastic comment here>.

I recently attended ACCU 2008 which had a whole stream of talks on FP. All the FP talks I attended were packed out. That is quite something given that the audience is primarily hardcore C++ programmers. There seemed to be quite a consensus in these talks that:

  • FP is starting to move out of academia and into commercial use.
  • FP is more suitable than imperative style programming for some classes of problem.
  • FP is not going to replace imperative programming. The bulk of commercial development will still be done in an imperative style, but with FP mixed in where appropriate.
  • Hybrid languages that mix OO and FP will become more common.

I don’t see Haskell replacing C++ any time soon. But I can definitely see the benefits of using FP to tackle some types of problems.

Further reading:

The Functional programming reference in Wikipedia

This article is based loosely on notes I made at ACCU 2008 from attending the following talks:

  • “Caging the Effects Monster: the next decade’s big challenge”, Simon Peyton-Jones
  • “Functional Programming Matters”, Russel Winder
  • “Grafting Functional Support on Top of an Imperative Language”, Andrei Alexandrescu

Any mistakes are almost certainly mine.