Digital Products and Marketing

There are compelling reasons to sell digital products online. The cost of distribution is low and the marginal cost per unit is virtually zero. Once the product is created, and a market found, digital products can be downloaded by consumers effectively an infinite number of times. Payment gateways are numerous and the costs are a small fraction (1-4%) of the purchase price.

For New Zealand domiciled entities, GST (Good and Service Tax – 15%) is not collectable on digital products that are downloaded offshore, however GST may be claimed on expenses incurred in New Zealand. This deliberate government policy is to encourage zero weight tech exports from New Zealand, earning the country valuable foreign exchange.

Over the past few years, I have sold several digital products online. This category included several e-books and some software. I used ClickBank as the payment gateway. This was easy to use and the fees reasonable, however there is a lot of junk on there. The e-books covered topics such as how to quit smoking “The Quit Smoking Book” and how to trade CFD’s and Forex. These sold for around $29.95. Over about two years I sold about 4-5 copies.

The software was a tool for SQL server admins and developers called the “DDL Extractor”. Basically it did as the title said, it extracted the database’s data definition language (DDL) to text files that could be searched, archived and added to source control. The first version had simple command line interface. I updated it to have a basic windows form GUI. It sold for between $19.95 and $49.95. Again I sold about 4-5 copies over two years.

All the products had their own domain and website. The pages had relevant content and sales copy. I created all the pages from scratch and hosted on GoDaddy. Marketing was mostly done through Google Adwords, Facebook ads, writing posts on Ezine and mentioning my products on forums such as stack overflow . All with links back to the relevant product sales page. The least effective and most expensive was Adwords. My account eventually got suspended for reasons more cryptic than a wet crossword puzzle. After weeks of trying figure out why, it turns out that at the time Adwords didn’t like pages that directly linked to a payment gateway. Nuts to that.

So, after all that I made around $300 of sales, and that’s before domain registration, hosting and the countless hours spent in the evenings writing coding and marketing. After all expenses including depreciation I accumulated about $5000 in losses. Epic Fail.

After a hiatus of about two years, I still like the idea of having a suite of digital products for sale. Having people find, pay and download a product you created – to solve a real problem – is a great feeling. Having payments rolling in while you are sleeping is also a great buzz. However, it must be profitable and the market must be large enough to sustain a business. How to achieve this has as yet, escaped me.

A few years ago Amy Hoy of Unicorn Free and 30×500 fame did a talk at a conference I attended, WDCNZ. I found the talk interesting and decided to follow her on Twitter. After reading many of her blog posts I entered my email address and began reading these posts. I’ve really enjoyed reading them. The basic premise is that you figure out your market before creating a product. It also explains just how to do this. One of the posts was the inspiration for me to start blogging again.

Now, to find that Market Product fit.

Test Driven Development is Hard

Really hard.

Sure, writing a contrived test for a simple function is pretty straight forward. There are many frameworks that developers use, and some will even form the test stubs for you. Having the discipline to always write tests is a challenge. Writing test first for weakly defined requirements is difficult. Retrofitting large and complex legacy code bases get hard – and costly.

Test first promotes modularity, clear requirements and acceptance criteria. It encourages thoughtful domain modelling and ensures code works as intended. But what if you don’t have clear requirements, if you inherit a mud ball of legacy code, the language is new and the budget tight, where do you start. How do you decide where to focus your efforts, what parts of the code to test and what to refactor?

The first thing is to commit to writing unit tests. You then need buy in from stakeholders – users, analysts, managers and fellow developers. This is an important and valuable exercise. The stakeholders need to know what’s in it for them. This can help get a team focused and all pulling in the same direction. So, what are the advantages of test driven development for project stakeholders.

Users: Test Driven Development encourages users to think about their business requirement in clear terms. This results in quality applications that satisfy user requirements with less errors.

Analysts: Encourages requirement gathering that is clear, organised, atomic and written with well defined acceptance criteria.

Managers: Higher quality applications with less errors. Lower lifetime cost of software by lower cost maintenance.

Developers: Can rest easy knowing their code works as intended. That requirements are clear and changes are nothing to fear.

Once the testing framework has been established, in the case of legacy code you might find that that much of the applications features cannot be tested. The logic is split between layers and classes, there are branches that cross multiple classes and layers. It is then time to refactor the code base. Check out Martin Fowlers book Refactoring.

New features should have tests written first. This should be manageable as the user requirements are now well defined and thought out with clear acceptance criteria. Happy managers that see the value in unit tests and developers who can make changes to the code with confidence. Developing software is a team effort, and test driven development can help focus a team. The best time to start test driven development is your next line of code.