Monthly Archives: April 2007

A software vendor’s first impressions of GoogleCheckout

google_checkout1.gifGoogleCheckout has only recently become available to UK-based businesses such as mine. On the 20th March I took my first payment for PerfectTablePlan using GoogleCheckout as my payment processor. I now offer GoogleCheckout as a payment processor in addition to PayPal and 2Checkout. Here are a few early observations on GoogleCheckout for anyone else thinking of signing up.

Sign-up

The online sign-up form refused to accept my company number, but wouldn’t tell me what the problem was. Thankfully Google support were quite responsive and told me I had to add a ’0′ on the front of the 7 digit company number to make it 8 digits. There are obviously still some bugs to iron out. Google put a small amount of money into my bank account (which makes a pleasant change) and I had to say how much to prove it was my account. It took about 5 days to complete the whole process, most of which was waiting for the payment to appear in my bank account.

Fees

This is the biggie. For every £1 you spend on GoogleAdWords you can process £10 in sales for free through GoogleCheckout until 2008. Should you exceed your Adwords quota (or not use Adwords) you will be charged only 1.5% + £0.15 per transaction. By way of comparison, the fee on £20 sale is:

GoogleCheckout: £0.45 (£0.00 if within Adwords quota)

PayPal: £0.68 (rates may vary between different account types)

Plimus: £2.00

Over hundreds or thousands of sales, that is a big difference. To be fair the Plimus rates are lower for higher ticket items and they probably offer a lot more services for software vendors than GoogleCheckout or PayPal, but it is hard to see them continuing to charge 10% when faced with this sort of competition.

Currency

I can only set a price in Pounds Sterling through GoogleCheckout. This is a real pain. People like to be quoted a fixed price in their own currency (Americans especially). So I want to be able to set a fixed price in pounds, a fixed price in dollars, a fixed price in euros etc as I do with PayPal. But I can’t. Non-UK customers can still buy my software through GoogleCheckout, but the price will be something odd like $36.23 and will change as the exchange rates change. Consequently I continue to use PayPal as my main payment processor for non-UK sales.

Adwords logo

You can tie your GoogleCheckout account to your AdWords account. As well as getting free processing this gives your ads a little GoogleCheckout logo. It certainly makes them stand out, but it is too early to say yet what effect this will have on clickthrough ratios and sales for my business.

Google are pretty zealous about enforcing these badges. I put through a GoogleCheckout transaction on my own credit card and a few hours later the GoogleCheckout logo appeared next to my Google Adwords ads. I went to bed. Next morning I woke to an email from Google saying they had revoked the logo as they couldn’t find the GoogleCheckout payment page. Blimey, give me chance – I hadn’t published the changes on my site yet! I explained the situation and the logo was restored in due course.

Integration

I integrate with GoogleCheckout using e-junkie, which I also use for integrating with PayPal. This allows me to display a licence key and email a licence key to the customer on purchase completion. I had quite a struggle to get e-junkie to do what I wanted with PayPal due to a combination of my own quirky requirements and patchy e-junkie documentation. But, now that I have it working with PayPal, adding GoogleCheckout was very straightforward. Other people seem less than impressed by the GoogleCheckout API, but e-junkie has successfully shielded me from all that.

Note that the email GoogleCheckout sends you for each purchase is very sparse. It doesn’t even contain the purchaser’s name. You have to go to the GoogleCheckout website for that or get it through their API. Thankfully e-junkie have an option to send you an additional email, which contains copious details about the order.

User experience

I did a couple of GoogleCheckout test transactions with my own credit card. The whole process was fairly lightweight and painless, similar to paying with a credit card by PayPal. Customers are also given the option to save all their details for future purchases.

Email confidentiality

GoogleCheckout gives customers a checkbox option to keep their email address secret from the vendor. The vendor gets a made-up email address which Google then (in theory) redirects to the vendor. The customer can instruct Google not to forward further emails at any point. I can see why customers might find this attractive, but I also see it causing headaches for vendors. What happens when a customer emails you from their real address and asks you to resend their licence key 6 months later? Unless they can quote their transaction code (which they have almost certainly lost as well) it is going to be a pain to work out if they purchased a key or not. About 50% of my customers have gone for the confidential option so far.

Promotional opt-in

Customers also have a checkbox option whether they want to receive promotional emails. About 20% of my customers so far have opted in. I will be adding them to my newsletter mailing list in due course.

Fraud protection

It is too early for me to say how good the GoogleCheckout anti-fraud measures are.

Customer acceptance

I think it is very important to give customers a choice of Payment processor, so I have both GoogleCheckout and PayPal buttons on my pounds sterling purchase page. The GoogleCheckout buttons are in arguably the more prominent position, but so far 70% of customers have chosen PayPal. I am not sure why. Perhaps because PayPal is a more recognised brand than GoogleCheckout amongst my customers. Or maybe it is due to teething problems with GoogleCheckout – I had one customer phone me up yesterday to say he just got an hourglass when he tried to pay through GoogleCheckout.

Conclusion

At this stage I can only give first impressions. Overall GoogleCheckout doesn’t appear quite as polished as more established systems, such as PayPal, and only being able to set a price in a single currency is a pain, but it is very cheap. It will be interesting to see what effect their pricing has on other payment processors.

A final word of caution. If you use GoogleAdwords, GoogleAnalytics and GoogleCheckout then Google knows a frightening amount about your business. They could decide you are making too much money and increase your minimum bids on Adwords accordingly. Or they could use their vast cash mountain to put most of the GoogleCheckout competitors out of competition and then ramp up their rates. But of course Google won’t do that, because that would be evil

Programming in flares

waves off HawaiiFashion is such a ridiculous business. Every year anorexic clothes horses strut up and down modelling ridiculous clothes no-one is ever going to wear. Hemlines go up or down. Various baubles are ‘in’ or ‘out’. Grey is the new black. We geeks are above all that. Comfortable in our jeans, bad haircuts and nerdily sloganed black t-shirts we know that #000000 != #0c0c0c . We care not a jot for fads and fashions. Or do we?

Actually, I think software development follows its own fads and fashions, just as slavishly as any Gucci-clad fashionista. Here are a few past and present software development ‘fashions’ that spring to mind:

  • 3GLs
  • 4GLs
  • methodologies (SSADM, Yourdon etc)
  • CASE tools
  • object orientation
  • UML
  • Java
  • XML
  • extreme programming/agile methods
  • Ruby on Rails

While all of these ideas contain something useful, they never turn out to be the panacea we were promised. Consequently they follow (or, I predict, will follow) an all-to-familiar boom and bust cycle:

  1. potential – The technology appears to have some promise.
  2. hype – The technology is wildly over-hyped. Massive and unrealistic increases in productivity are touted.
  3. hysteria – Lots of books and magazine articles are written. Developers worry their careers will suffer if they don’t learn the new technology, and soon.
  4. backlash – The reality falls far short of expectations and the whole worth of the technology is called into question. But actually the technology is improving as it matures.
  5. realism - Expectations settle down to more realistic levels and the best elements of the technology are absorbed into mainstream practice.

We can visualise the cycle in a simple graph:

boom_and_bust21.gif

Java is a good example of this cycle. It started its life as Oak, a language for set-top boxes. Renamed to the more catchy Java and pushed by Sun as a write-once run-anywhere language it soon passed from hype to hysteria on a wave of coffee related puns. Everything would soon be written in Java we were told in endless gushing articles. The performance issues would be sorted out in the next release. Corel were rewriting their office suite in Java. Netscape were rewriting their browser in Java. C++ was finished. Sun’s stock rose meteorically.

In fact Java apps of the time were ugly and slow and the cross-platform capabilities turned out to be problematic. Write-once run anywhere became write-once, test everywhere. Java Corel office was rapidly abandoned when the beta was found to be completely unusable (I tried it myself, it was a joke). Netscape’s attempts to produce a web browser in Java also failed. The backlash began. In actual fact Java is now not much slower than C++ for many applications. But the Java zealots cried wolf so many times in the past that few people believe them any more. Finally we are reaching a realistic understanding of the strengths and limitations of Java, but most of us lost interest in Java a long time ago and are too busy pursuing the next ‘great thing’.

What is the latest fad? Agile methods is certainly a contender. Agile methods are ‘lightweight’ methodologies, a backlash against ‘heavyweight’ methodologies, such as Rational unified Method and SSADM. If you search for “agile” in ‘Books>Computers & Internet’ on Amazon.com you get 2,964 matches. How can so much possibly be written about a ‘lightweight’ approach? A recent C/C++ conference I went included no less than 6 talks with ‘agile’ in the title (and a couple more on the related topics of ‘lean development’ and ‘scrum’). No doubt there are whole conferences about agile methods. While I don’t doubt that an agile approach contains useful ideas, I very much doubt that it is a one-size-fits-all, ‘one true way’ to develop software. But you would be forgiven for thinking that it was if you listened to some of the agile zealots (especially the ‘extreme programming’ wing of the agile church).

Boom and bust is a painful, expensive and pathological way to adopt new ideas and technologies. Why can’t we take a more measured and mature approach? Fred Brooks warned us over 30 years ago that software development is hard and it probably always will be. But the message appears still not to have sunk in. We are still looking for for that mythical silver bullet. The problem is partly caused by many developers having a lack of perspective. They are so focused on the minutiae of programming and the latest cool technologies that they just can’t see the bigger picture. Because they don’t understand the past they are condemned to repeat it (to paraphrase Santayana).

Much of the cycle is also driven by self-interest. The pundits make a very nice living selling books, consultancy and training. The journalists get something new to write about. The developers and team leads get to do ‘cool’ stuff and add some exciting new acronyms to their CVs. The vendors are happy to sell expensive new tools. Unfortunately the employers, shareholders and customers end up with late, over-budget and buggy software because the developers choose a cool new, bleeding-edge technology over something more mature and well understood. But it is too late by the time the problems become apparent.

Development environments are now vast ecosystems of languages, libraries and tools. Surely it is better to take the time to master one of these environments and understand its strengths and weaknesses, than to be continually chasing the latest fashion and never master anything. Better the devil you know than the devil you don’t. I am not against progress and I certainly don’t think we should try to use the same tool for every job. Many of the technologies I have listed above led to major steps forward, even if they didn’t live up to the initial hype. But software development should be a means to an end and we should never be so wrapped up in the technology that we lose sight of that. Professional developers should pay less attention to the latest fashions and focus more on solving problems for their customers. An experienced C programmer is almost certainly more productive than an inexperienced Ruby programmer. Wear your flares with pride.

Dealing with embedded GIF spam

embedded GIF SPAMSpam and phishing emails can be a huge drain on productivity for an Internet based business. I use Mozilla Thunderbird and I find the spam filtering works tolerably well. Most of the incoming spam is quietly siphoned off into a ‘Junk’ folder and there appear to be very few false positives. I supplement this with a message filter to move all emails purporting to be from paypal.com or ebay.com (99% of which are phishing emails) to a ‘Suspicious’ folder, which I check from time to time. But I still get lots of spam with embedded GIF images, which Thunderbird’s spam filter seems to be powerless to handle.

Mostly these are ‘pump and dump’ stock tips, but some of them are for viagra, cialis etc. Some of the spammers even helpfully include images of the body parts targeted by these medications. After a quick Google I found out how to set up a message filter for embedded GIFs on Uzik’s blog. Any email with an embedded GIF that comes from someone I don’t know now gets sent to my ‘Suspicious’ folder. Thanks Uzik! A similar approach should work in many other email clients.

Thunderbird embedded GIF rule

a rule for embedded GIFs (click to enlarge), see Uzik’s blog for more details

Note that some legitimate emails may have embedded GIFs as background images. While this practice is highly questionable you won’t want to lose these emails, so you should check your ‘Suspicious’ folder from time to time.

Of course this is only partial solution. The only real solution is to stop the spam in the first place. I say cut off their goolies.

10 questions to ask before you write a single line of code

I would guess that the majority of the software that I have written in my career has never been used. Or, at least, not used enough to justify the long hours I and my colleagues lavished on it. I am sure that I am far from unique in this. I flatter myself that the software was intuitive, well documented and robust, but we never managed to convince enough people that the software solved a real problem for them. Creating high quality software is hard, but it just isn’t enough. The software also has to be marketed effectively.

Effective marketing means:

  • identifying a problem that people will pay you adequately to solve
  • letting these people know about your solution
  • convincing them that your solution solves their problem, at least enough to try it
  • doing all the above cost effectively

This is no easy task in a complex and constantly changing world, bursting at the seams with billions of people and millions of other products.

Crucially, decisions you make about marketing can (and should) have a big effect on the end product. So you need to make key marketing decisions before you develop the product. This may sound like stating the obvious, but even a casual inspection of developer forums shows that many software developers spend hundreds or thousands of hours developing a product without thinking about how they are going to market it, or even whether there is a market for it. If you are writing software as a hobby or to scratch your own itch, that’s fine. Knock yourself out. But if you are writing commercial software you need to have a very clear idea of your market and you need to develop the product with that market very much in mind.

To the developer, safe in their world of beautiful abstractions, marketing seems a rather grubby business. It smacks of deception, manipulation and impure motives. I remember a business studies lecture I attended as part of my physics degree as a brief respite from partial difference equations and thermodynamics, where the lecturer asked a room full of engineers and scientists how we would market a sonic mouse repeller. “Does it actually work?” asked a sceptic. “Does that matter?” asked the lecturer. There was a profound silence as the awful implications of his reply sunk in.

But, if you have a good product, you shouldn’t have to lie to your customers. Good marketing should be about communication, not deception. Like coding, it is easy to do badly, and difficult to do well. If we want our software to reach its full potential we need to either place our trust fully in someone else or we need to get involved. Personally, I find it hard to entrust the success of my hard work 100% to someone else. Especially someone from marketing!

Here are 10 questions I think every developer should ask themselves (or their marketing department) before starting to develop a software product in earnest.

1. What is your ’10 second elevator pitch’?

You should be able to describe the benefits of your software to potential customers in one sentence (two at a stretch). This is the ‘strapline’ that will go at the top of your web page. If it is difficult to describe, it is going to be difficult to market – difficult to create web pages for, difficult to do search engine optimisation for and difficult to write ads for. If you are struggling with this one, maybe you need to focus the product on a narrower problem.

2. Who is going to buy/use the software?

The software needs to be tailored to the intended user. Technical users will be interested in powerful functionality, whereas non-technical users will be more interested in a simple user interface. Graphics designers will care a lot about visual aesthetics. Emergency services will care a lot about reliability.

If you are selling to organisations the buyer may not be the same person as the user. Tailor the marketing to the buyer. What issues are they most worried about, what sort of license will they prefer (lease or purchase), what budget do they have? Business customers will usually be less price sensitive than consumers.

3. Who are your competitors?

In an efficient market you would expect the level of competition to be directly proportional to the size of the market. But the market isn’t completely efficient, so some niches may be more lucrative than others. Find out who your competitors are. What features do they have, how are they priced? Don’t take too long over it though – if you can’t find a competitor in a few hours of searching, then neither will many customers. Note that some of your competition might not even be software – for example there are a couple magnetic/Velcro based products that are competitors to my own seating planner software.

Be wary of entering a market with lots of established competitors, unless you are sure that you are offering something compelling that they aren’t. It is easy to think “This market is $1 billion dollars per year, I reckon I can get 1% of the market, that’s $10 million/year”. Dream on. The competition in such a market will be ferocious with the top 2 or 3 vendors taking a huge proportion of the market, with marketing and development budgets to match. You would probably be better to aim at a small niche in such a market, you can always grow into other niches from there. Good luck if you decide to compete head on with Microsoft, Yahoo or Google – you’ll need it. For every company that gets bought out by this unholy trinity countless other get crushed.

Be wary of entering a market with no competition. There is a tiny chance that you are a genius who has spotted a new market. It is much more likely that there are no competitors because is there is no market. Others may have steered clear for good reasons or tried and failed. Even if there is an opportunity you will have to create a new market and that can be very expensive.

4. How will your product be positioned?

What aspect of your software are you going to emphasize to make it more attractive than the competition? For example you can position based on ease of use, additional features, higher performance, better support, more flexible licensing etc. Positioning your product purely on price (e.g. ‘cheaper than X’) is rarely the best strategy.

5. How will your customers find out about it?

Before anyone can buy your software they need to know it exists. How are you going to get the message out: search engine optimisation, download sites, pay per click ads, print ads, trade shows, mailshots, viral marketing, resellers, distributors, affiliates, a free ‘lite’ version, blogging, competitions, press releases? What budget do you have? What works best will vary depending on your market and what you can afford.

6. Will you have a trial version?

The ‘try before you buy’ model is now commonplace for software sold on the Internet. Are you going to offer a trial version? Will it be feature-limited or time-limited?

7. How will you license it?

Are you going to license the software per machine, per named person, per site or per organisation? Will the license be transferable? What sort of licensing protection will you use (if any)?

8. What price will it sell at?

How much will you charge? How valuable is your software to the customer? How much money does the customer have to spend? Will you sell different versions at different price points? Are you going to charge a one-time fee + upgrade fees or a subscription?

9. How will your customers buy the software?

Are your customers going to buy the software from your website, from a retail store or are you going to have to send a salesman to their office?

10. What is the smallest amount worth delivering for version 1.0?

Getting to market fast has two main advantages:

  • you start getting sales sooner, which is good for your cash flow
  • you start getting feedback, which helps to guide further development

Get v1.0 to market fast by cutting back brutally on the features, not the quality. Many developers will feel that they can’t release v1.0 until it does at least as much as competitors, but this is usually a mistake. Many customers may not be interested in features X, Y and Z. In fact, they might even prefer a simpler product without these features. The sooner you get a product ‘out there’ the sooner you will find out. If you don’t get any sales or feedback, that is also telling you something very important.


Many of your initial marketing decisions will be based on guesses and gut feel. Thats OK. The only people with a good understanding of your market are your competitors, and they aren’t likely to tell you much. The best you can do is to make educated guesses and evolve your marketing as you get feedback on what works and what doesn’t. Note also that many of these decisions are coupled. If you are charging $30 for a license it is unlikely that you will need or be able to afford salesmen. If you are selling large enterprise solutions ‘try before you buy’ may not be appropriate.Once you have got your basic marketing plan, test it. Go and find some people who you think are potential customers and ask them “If I make this product, will you buy it?” (don’t expect friends and family to give you an honest answer – they are more interested in not hurting your feelings). The more you can make them think they are making a commitment, the more likely they are to give you a truthful answer. If the answer is a resounding “no”, or you can’t find any potential customers or they can’t find the time to talk to you – it is time to reconsider. Having your killer idea shot down in flames is painful, but its a lot less painful than investing thousands of hours in something that is never going to sell. Trust me – I only wear my marketing hat some of the time. Further reading/listening:

How much money will my software make (and what has that got to do with aliens)?


From time to time people appear on the Business of Software discussion forum and ask “How much money will I make if I create a software product and sell it from a website?”. There are so many factors at play it is very difficult predict, but it isn’t entirely hopeless. We can look for inspiration to the astronomer Frank Drake.

Frank Drake wanted to know many alien civilisations there are currently in our galaxy that we could potentially talk to. That’s a pretty BIG question. But Drake broke it down into a number of smaller questions in his famous Drake equation :

N = R x Fp x Ne x Fl x Fi x Fc L

Where:

  • N is the number of civilizations in our galaxy with which we might expect to be able to communicate at any given time
  • R is the rate of star formation in our galaxy
  • Fp is the fraction of those stars that have planets
  • Ne is the average number of planets that can potentially support life per star that has planets
  • Fl is the fraction of the above that actually go on to develop life
  • Fi is the fraction of the above that actually go on to develop intelligent life
  • Fc is the fraction of the above that are willing and able to communicate
  • L is the expected lifetime of such a civilization for the period that it can communicate across interstellar space

These are still tough questions to answer. We know that the final value is >= 1 (assuming the success of reality TV doesn’t exclude us from being classified as intelligent) but many of the factors are highly uncertain. In particular there is huge uncertainty over the civilisation lifetime factor L. The equation was first derived at the height of the cold war, when many scientists understandably took a very pessimistic view over whether technological civilisations could avoid blowing themselves up. The more optimistic thought that advanced civilisations would disappear inside Dyson spheres after a few millenia. But at least astrophysicists and xenobiologists can have much more meaningful debates over these individual factors than they can by just arguing about the final estimates. Drake himself came up with a value of N=10.

In the same vein, here is my equation for how much software you will sell in any given month:

S = P x N x Ft x Fb

Where:

  • S is the sales per month in units of currency
  • P is the price of a licence (in the same units as S)
  • N is the number of unique visitors to your website per month
  • Ft is the fraction of visitors who try your software
  • Fb is the fraction of visitors who buy the software after trying it

This obviously assumes that the Internet is your main sales medium, you don’t have to give many refunds, people will always download and try the software before buying and a raft of other assumptions. But it’s a start. We could break it down into a lot more factors, e.g. to include the fraction of potential customers who didn’t use a crack, but the advantage of the above factors is that they are simple and relatively easy to measure.

Drake only had one data point to work from for most of his factors – our own earth. Similarly a we don’t have a lot of data to work from, as software vendors tend to be rather coy about their sales data. As a data point the stats from my own table planning software site show that approximately 10% of visitors download the software and approximately 10% of these go on to buy a licence. This means that only around 1% of visitors to the site buy a licence. This percentage (Ft x Fb) is known in the jargon as the ‘conversion ratio’. 1% seems really low, but I understand from various sources that 1% is actually quite respectable. Afterall it includes all the people who ended up on my site while searching for “diy picnic table plans” or “multiplication table printing” (if you only include visitors that visited the home page the conversion rate goes up to a more respectable 4%).

So now you can plug in your own numbers and get a rough idea of what your sales might be. Or, perhaps more helpfully, you can re-arrange the equation to find out how many visitors you need per month:

N = S / ( P x Ft x Fb )

If we plug in: S = $10,000/mo, P = $100, Ft = 10% and Fb=10%, we get N= 10,000 unique visitors per month. You can then ask yourself if 10,000 unique visitors per month is achievable for your product.

Some points to note:

  • The price will have an effect on the conversion percentage. But decreasing the price will not always increase the conversion percentage. Because price sends a signal about the quality of your product, it may even have the opposite effect. This is a complex topic and beyond the scope of this article.
  • Not all visitors are equal. Highly targeted visitors going to a well designed web site with an excellent product might have conversion ratios as high as 5-10%. Poorly targeted visitors (e.g. coming from badly worded online ads or purchased from dubious ‘traffic programs’) will have conversion ratios barely discernible from 0%.
  • Just like the Drake equation, if any of the factors are 0, the result will be zero, no matter how large the other factors are, i.e. it doesn’t matter how many visitors you get if the link to the purchase page is broken.

Feel free to leave a comment with your values for for P, N, Ft and/or Fb.

So what is my value for N? I’m not telling. But, I don’t think any of them are aliens.