Direct emailing is the one of the important marketing tools nowadays. However, it can be failure if you cannot choose the right list of customers. Failure means your money invested in it would be waste and also time you dedicated would be useless.
Therefore, if you want to make each cents and time out of it, following is the checklist.
Checklist of Mailing List Research Questions
1. Where do the names on the list come from? What sources are being used to create the list?
2. How often is the list updated? And when was it last updated?
3. Are new names being added on an ongoing basis, and if so, can names be selected by recency? 4. What demographic selections are available?
5. What other mailers have used the list recently? And what kinds of offers were they making?
6. What are the terms for one-time and multiple use?
7. Are net-name arrangements available and what are they?
Monday, July 26, 2010
Monday, July 19, 2010
Why the Adobe Flash Platform?
The Adobe Flash Platform (see Figure 2) includes the following products and technologies:
* Adobe Flash Player is available on 99% of PCs and forms the core client-side runtime of the Adobe Flash Platform.
* The open-source Flex framework provides abstractions to connect to disparate data services via HTTP, SOAP, or AMF. The Flex framework uses an easy to learn declarative language called MXML for developing user interfaces.
* Adobe Flash Builder is an Eclipse-based IDE. It provides robust code editing, navigation, interactive debugging, and a WYSIWYG design surface to accelerate application development.
* Adobe Creative Suite tools, such as Flash Catalyst, enables designers to collaborate with developers to create engaging user experiences.
* Adobe LiveCycle Data Services simplifies data management tasks such as tracking changes, synchronization, paging, and conflict resolution.
100 ways to increase your software sales in 2009
Increase targeted traffic to your website:
1. SEO your website.
2. Write a blog or newsletter of interest to the sort of people who might buy your software.
3. Get more links to your website.
4. Try Google Adwords Pay Per Click (PPC) ads.
5. Write a guest post on someone else’s blog.
6. Try CNet Pay Per Download ads.
7. Promote your software through download sites using the ASP PAD repository, a paid submission tool or free submission tool.
8. Promote your software through platform sites e.g. Apple downloads or Office online.
9. Start an affiliate program.
10. Try Microsoft Adcentre PPC ads.
11. Bid higher for your PPC phrases.
12. Advertise on stumbleupon.
13. Write additional content for your site.
14. Give away a ‘lite’ version of your software.
15. Offer discount coupons.
16. Add a forum to your website.
17. Offer free review copies of your software to bloggers.
18. Do a press release.
19. Run a competition.
20. Write better ads for your PPC campaign.
21. Direct (snail) mail.
22. Run ads in print magazines.
23. Include your URL when posting on relevant forums.
24. Try Yahoo Search Marketing PPC ads.
25. Buy banner ads on targeted blogs, forums and other websites.
26. Add extra keywords to your PPC campaigns.
27. Talk about your software on a podcast.
28. Add a viral element to your software.
29. Do a publicity stunt.
30. Get word of mouth recommendations by giving great support.
31. Get listed in online directories such as DMOZ.
32. Post a screencast on YouTube.
Increase your visitor->download rate:
1. Have an online demo movie.
2. Offer a free trial.
3. Offer a money back guarantee.
4. Port your software to additional platforms e.g. iPhone.
5. Have a clean and professional website.
6. Add case studies to your website.
7. Make sure your website functions with all the major browsers.
8. Get someone else to proof read the copy on your website.
9. Talk to visitors in a language they understand i.e. not technical jargon, unless they are techies.
10. Reduce the number of barriers to downloading the trial (don’t require an email address).
11. Add a product FAQ to your website.
12. Show your price prominently.
13. Improve the usability of your website.
14. Include your contact details on the website.
15. Make sure the people can understand what your software does within 2 seconds of arriving at your site.
16. Make the ‘download’ button more prominent on your website.
17. Fix any errors in your website.
18. Include screenshots on your home page.
19. Add a list of famous customers to your website.
20. Use a digital certificate for your installer and executable.
21. Add (genuine!) testimonials to your website.
22. Create better landing pages for your PPC campaigns.
23. Add a privacy policy to your website.
24. Add live online support to your website.
25. Check your web logs/analytics to find out why/where visitors are leaving your website.
Increase your download->sale rate:
1. Offer more than one payment processor.
2. Improve the usability of your software.
3. Accept purchase orders.
4. Offer Trialpay as an alternative payment method.
5. Offer sensible prices in additional currencies.
6. Require an email address to download your software and follow-up with marketing emails.
7. Increase or reduce the price of your software.
8. Fix bugs in your software.
9. Lengthen or shorten the trial period.
10. Offer bulk purchase discounts.
11. Improve your installer.
12. Make the ‘buy’ button more prominent on your website.
13. Make your software more beautiful.
14. Allow users to buy your product easily from within the software itself.
15. Localize your software into another language.
16. Offer organizational licences.
17. Try limiting your trial by features instead of time (or vice versa).
18. Improve the speed/memory performance of your software.
19. Improve your product documentation.
20. Offer alternative payment models (e.g. an annual subscription instead of a one-off fee).
21. Offer alternative licensing models (e.g. per site instead of per user).
22. Write an introductory tutorial.
23. Reduce the number of clicks and key presses required to make a sale.
24. Add that new feature that people keep asking for.
Increase the value of each sale:
1. Increase the price of your software.
2. Charge extra for optional modules.
3. Upsell additional products and services of your own or as an affiliate.
4. Charge for major upgrades.
5. Offer multiple versions at different price points e.g. standard/business/enterprise.
6. Offer an optional CD.
7. Charge an annual maintenance fee.
8. Charge for support.
9. Offer a premium support plan.
Explore alternative sales channels:
1. Sell through resellers.
2. Exhibit at tradeshows.
3. Cold call prospects.
4. Allow other companies to sell white label versions of your software.
5. Include your software on cover-mounted magazine CDs.
6. Sell through retail stores.
7. Sell on Ebay.
8. Sell on Amazon.
9. Promote your software on one day sale sites, such as BitsDuJour or GiveAwayOfTheDay.
10. Create a new product.
Notes:
* Items are in no particular order in each category.
* Some of the items are mutually exclusive.
* I have tried about 80% of the above. Some worked, some didn’t. In fact, many of them were a total waste of time and money. But the ones that didn’t work for me might work great in a different market (and vice versa). I discuss my experiences with some of them in more detail here: Promoting your software part1, part2, part3, part4, part5, part6.
* This is by no means an exhaustive list. Feel free to suggest more in the comments.
* Don’t know where to start? Perhaps you need a fresh pair of eyes.
Thanks to Stuart Prestedge of Softalk for suggesting some of the above.
1. SEO your website.
2. Write a blog or newsletter of interest to the sort of people who might buy your software.
3. Get more links to your website.
4. Try Google Adwords Pay Per Click (PPC) ads.
5. Write a guest post on someone else’s blog.
6. Try CNet Pay Per Download ads.
7. Promote your software through download sites using the ASP PAD repository, a paid submission tool or free submission tool.
8. Promote your software through platform sites e.g. Apple downloads or Office online.
9. Start an affiliate program.
10. Try Microsoft Adcentre PPC ads.
11. Bid higher for your PPC phrases.
12. Advertise on stumbleupon.
13. Write additional content for your site.
14. Give away a ‘lite’ version of your software.
15. Offer discount coupons.
16. Add a forum to your website.
17. Offer free review copies of your software to bloggers.
18. Do a press release.
19. Run a competition.
20. Write better ads for your PPC campaign.
21. Direct (snail) mail.
22. Run ads in print magazines.
23. Include your URL when posting on relevant forums.
24. Try Yahoo Search Marketing PPC ads.
25. Buy banner ads on targeted blogs, forums and other websites.
26. Add extra keywords to your PPC campaigns.
27. Talk about your software on a podcast.
28. Add a viral element to your software.
29. Do a publicity stunt.
30. Get word of mouth recommendations by giving great support.
31. Get listed in online directories such as DMOZ.
32. Post a screencast on YouTube.
Increase your visitor->download rate:
1. Have an online demo movie.
2. Offer a free trial.
3. Offer a money back guarantee.
4. Port your software to additional platforms e.g. iPhone.
5. Have a clean and professional website.
6. Add case studies to your website.
7. Make sure your website functions with all the major browsers.
8. Get someone else to proof read the copy on your website.
9. Talk to visitors in a language they understand i.e. not technical jargon, unless they are techies.
10. Reduce the number of barriers to downloading the trial (don’t require an email address).
11. Add a product FAQ to your website.
12. Show your price prominently.
13. Improve the usability of your website.
14. Include your contact details on the website.
15. Make sure the people can understand what your software does within 2 seconds of arriving at your site.
16. Make the ‘download’ button more prominent on your website.
17. Fix any errors in your website.
18. Include screenshots on your home page.
19. Add a list of famous customers to your website.
20. Use a digital certificate for your installer and executable.
21. Add (genuine!) testimonials to your website.
22. Create better landing pages for your PPC campaigns.
23. Add a privacy policy to your website.
24. Add live online support to your website.
25. Check your web logs/analytics to find out why/where visitors are leaving your website.
Increase your download->sale rate:
1. Offer more than one payment processor.
2. Improve the usability of your software.
3. Accept purchase orders.
4. Offer Trialpay as an alternative payment method.
5. Offer sensible prices in additional currencies.
6. Require an email address to download your software and follow-up with marketing emails.
7. Increase or reduce the price of your software.
8. Fix bugs in your software.
9. Lengthen or shorten the trial period.
10. Offer bulk purchase discounts.
11. Improve your installer.
12. Make the ‘buy’ button more prominent on your website.
13. Make your software more beautiful.
14. Allow users to buy your product easily from within the software itself.
15. Localize your software into another language.
16. Offer organizational licences.
17. Try limiting your trial by features instead of time (or vice versa).
18. Improve the speed/memory performance of your software.
19. Improve your product documentation.
20. Offer alternative payment models (e.g. an annual subscription instead of a one-off fee).
21. Offer alternative licensing models (e.g. per site instead of per user).
22. Write an introductory tutorial.
23. Reduce the number of clicks and key presses required to make a sale.
24. Add that new feature that people keep asking for.
Increase the value of each sale:
1. Increase the price of your software.
2. Charge extra for optional modules.
3. Upsell additional products and services of your own or as an affiliate.
4. Charge for major upgrades.
5. Offer multiple versions at different price points e.g. standard/business/enterprise.
6. Offer an optional CD.
7. Charge an annual maintenance fee.
8. Charge for support.
9. Offer a premium support plan.
Explore alternative sales channels:
1. Sell through resellers.
2. Exhibit at tradeshows.
3. Cold call prospects.
4. Allow other companies to sell white label versions of your software.
5. Include your software on cover-mounted magazine CDs.
6. Sell through retail stores.
7. Sell on Ebay.
8. Sell on Amazon.
9. Promote your software on one day sale sites, such as BitsDuJour or GiveAwayOfTheDay.
10. Create a new product.
Notes:
* Items are in no particular order in each category.
* Some of the items are mutually exclusive.
* I have tried about 80% of the above. Some worked, some didn’t. In fact, many of them were a total waste of time and money. But the ones that didn’t work for me might work great in a different market (and vice versa). I discuss my experiences with some of them in more detail here: Promoting your software part1, part2, part3, part4, part5, part6.
* This is by no means an exhaustive list. Feel free to suggest more in the comments.
* Don’t know where to start? Perhaps you need a fresh pair of eyes.
Thanks to Stuart Prestedge of Softalk for suggesting some of the above.
Rich Internet applications
Figure 1. The RIA ecosystem
In the early days of Internet computing, application interfaces were mostly text based and the main development challenges centered on handling the volume of data traffic and diversity of services. Advances in SOA helped pave the way for new software delivery models over the web. The need for providing better user experiences became amplified with software as a service (SaaS) becoming a mainstream, proven methodology for delivering complex software products. RIAs provide that improved user experience by combining the reach of the web with rich, interactive user interfaces. Rich refers to the ability to incorporate client side interactivity and intuitive user interfaces resulting in engaging experiences, whereas reach is the ability to make an application available to almost anyone, anywhere. Technology advancements along with concepts such as social networks are fueling many of the so called “Web 2.0” applications in which data, exposed through services, is considered to be the central element. In RIAs, local computing power is used for rendering user interfaces, integrating video and animations, or even offline data analysis.
RIA platform expectations
An RIA platform is an integrated set of technologies meant for designers, developers, and consumers that provides everything needed to create and deliver compelling applications (see Figure 1). The following are the key expectations of an RIA platform:
* Ubiquitous client runtimes—Runtimes reside on PCs, mobile devices, and (increasingly) consumer electronics to fulfill the goal of universal reach.
* Write once run everywhere consistency—Given that browser and device fragmentation is expected to deepen, the client runtime should work across platforms, and browsers, and it should provide consistent experiences across devices.
* Designer-developer workflows—Design is a key element for creating engaging experiences and designers need to collaborate with developers.
* Heterogeneous data access—RIAs typically access data in disparate formats such as JavaScript Object Notation (JSON) and XML from a variety of services such as RESTful services and web services. The RIA platform should enable this.
* Developer productivity—Shortening time to market is a big competitive advantage. Developers can help an organization seize this advantage with productivity enhancing tools and easy to learn and easy to maintain languages.
*
Data synchronization, data management, and on-demand data access—For RIAs that must operate when disconnected, these capabilities are essential.
Challenges in building data-centric RIAs
Because organizations have already invested in building service-oriented architectures, one of the key challenges that RIA developers face is the need to integrate with existing server-side technologies such as J2EE, ColdFusion, PHP, or web services. To this end, they need to be able to work in a seamless way with both client and server code within an Integrated Development Environment (IDE). Further, the IDE should provide design time facilities that abstract diverse services and data formats by using technology-agnostic representation of the service operations and data.
XML and JSON are less efficient for exchanging large volumes of data. As a result developers often use binary formats such as Action Message Format (AMF) for such situations. Services that are exposed over AMF can be developed in different languages, including object-oriented (Java) and script-oriented (PHP) languages. RIA developers need a uniform way of working with these AMF services, similar to how Web Service Definition Language (WSDL) has provided a uniform way of working with various web services. There is also a need for the IDE to help the RIA developer author user interfaces by leveraging technology-agnostic data representations to help boost developer productivity.
Failed Software Launch – Lessons Learned
Posted May.28, 2010 under Marketing Campaigns, Sell Software
Andy Brice from Successful Software blog just released an excellent article where he is featuring 13 examples of software launches gone sour.
The article cover thirteen different software products and their launches that didn’t turn out like the software creators expected.
There are many lessons to be learned and if you are serious about your Software Marketing I suggest you read through the whole article.
Some of the bigger takeaways are that the software authors failed to research the market enough before venturing out and creating their software and the failed to market it when the product was released.
Take it away Andy…
Software entrepreneur culture is full of stories of the products that succeeded. But what about the products that failed? We rarely hear much about them. This can lead to a very skewed perspective on what works and what doesn’t (survivor bias). But I believe that failure can teach us as much as success. So I asked other software entrepreneurs to share their stories of failure in the hope that we might save others from making the same mistakes. To my surprise I got excellent 12 responses, which I include below along with one of my own. It is a small sample and biased by self selection, but I think it contains a lot of useful insights. It is an unashamedly a long post, as I didn’t want to lose any of these insights by editing it down.
Case #1: DRAMA
Contributor
Andy Brice.
The product
DRAMA (Design RAtionale MAnagement) was a commercialization of a University prototype for recording the decision-making process during the design of complex and long-lived artefacts, for example nuclear reactors and chemical plants. By recording it in a structured database this information would still be available long after the original engineers had forgotten it, retired or been run over by buses. This information was believed to be incredibly valuable to later maintainers of the system, engineers creating similar designs and industry regulators. The development was part funded by 4 big process engineering companies.
Why it was judged a commercial failure
Everyone told us what a great idea it was, but no-one bought it. despite some early funding from some big process engineering companies, none of them put it into use properly and we never sold any licences to anyone else.
What went wrong
* Lack of support from the people who would actually have to use it. There are lots of social factors that work against engineers wanting to record their design rationale, including:
o The person taking the time to record the rationale probably isn’t the person getting the benefit from it.
o Extra work for people who are already under a lot of time pressure.
o It might make it easier for others to question decisions and hold companies and engineers accountable for mistakes.
o Engineers may see giving away this knowledge as undermining their job security.
* Problems integrating with the other software tools that engineers spend most of their time in (e.g. CAD packages). This would probably be easier with modern web-based technology.
* It is difficult to capture the subtleties of the design process in a structured form.
* A bad hire. If you hire the wrong person, you should face up to it and get rid of them. Rather than keep moving them around in a vain attempt to find something they are good at.
* We took a phased approach, starting with a single-user proof of concept and then creating a client-server version. In hindsight it should have been obvious that not enough people were actively using the single-user system and we should have killed it then.
Time/money invested
At least 3 man years of work went into this product, with me doing most of it. Thankfully I was a salaried employee. But the lack of success of this product contributed to the demise of the part of the company I was in.
Current product status
The product is long dead.
Any regrets?
It was a fairly painful experience. I would rather have spent all that money, time and energy on something that someone actually used. But at least I learnt some expensive lessons without using my own money.
Lessons learned
* Creating a new market is difficult and risky.
* Changing people’s working habits is hard.
* Social factors can make or break a product. The end-users didn’t see anything in it for them.
* If the end-users don’t like a product, they will find a way not to use it, even if their bosses appear to be enthusiastic about it.
* Talk is cheap. Lots of people telling you how great your product is doesn’t mean much. You only really find out if your product is commercially viable when you start asking people to buy it.
Case #2: CleanChief
Contributor
Sam Howley.
The product
CleanChief was to be ‘The easy management solution for cleaning organisations’. Managing assets, employee schedules, ordering supplies, you name it CleanChief handled it. Essentially it was light weight accounting software for cleaning companies.
Why it was judged a commercial failure
A small number of copies were sold. No one is actively using it at present. Once I realised that it wasn’t a complete product and that additional development was required I moved on to other product ideas. I had basically run out of enthusiasm for the product.
What went wrong
* I am not an accountant.
* I have never run a cleaning company.
* I developed it for more than two years without getting feedback from real cleaning companies. I was arrogant enough to think that I knew what they wanted (or could work it out on my own). Or maybe it was that I was just where I was most happy and comfortable – writing software. Talking to real users was new and to be honest a bit scary for me.
* A successful cleaning company operator, a friend of a friend, offered to become involved for a 30% share. This was a gift from the heavens, exactly what I needed. I refused.
* In a way, even though I spent so long on the product, I gave in too soon, I was just getting feedback from real users, just getting my first batch of sales when I decided to move on.
* I developed the application in VB6 even though I knew it was outdated technology when I started the project.This meant there was no ‘cool factor’ when discussing it with other developers, I told myself it didn’t bother me, but it probably did.
Time/money invested
I worked on it at night and weekends for about 2 1/2 years. I paid for graphic design work, purchased stock icons and images. I probably spent a couple of thousand Australian dollars in total and an awful lot of time.
Current product status
I moved on to other products that have gone much better. My newer products were released in months rather than years and I looked for real feedback from real users from day one. they are:
* QueryCell – an Excel add-in making SQL in Excel easy.
* QuizNightChief – the easy way to organise a quiz Night.
* CustomerCradle – The easiest way to record and report on where your customers come from.
I do occasionally ponder returning to CleanChief and trying to raise it from the ashes.
Any regrets?
No. Looking back I learned a few lessons from a huge amount of time and work, it was a very inefficient way to learn those lessons. But when you are new to something like starting a business or creating useful software being inefficient at learning lessons is the best you can do, it’s a thousand times better than not learning lessons at all.
I learned so much more in my two and a half years of trying to develop CleanChief than I did in the two and a half years prior to that, during which time I really wanted to start a software business but didn’t take any action.
Lessons learned
Hearing or reading some piece of advice is totally different to living it. Here are some of the ideas that I always agreed were true but didn’t fully understand the implications of until I had lived them out:
* Force yourself to get out and talk to people. Ask their advice. Almost everyone will help if you ask them for feedback.
* Force yourself to cold call a few businesses in your target market.
* Create a plan of how to market your product.
* Try and use your product as much as possible as you build it.
* Get out of your comfort zone from day one
* Do not have the mind set that the day you release version 1.0 is the finish line, it’s the starting line, so hurry up and get there.
Case #3: Chimsoft
Contributor
Phil Anderson.
The product
ChimSoft – Software for Chimney Sweeps.
Why it was judged a commercial failure
I believe this failed for two reasons:
* Focusing on too small of a niche
* Me not being able to work full time on it.
I don’t consider it a complete failure because I sold two copies when it retailed for $2k, and maybe 10-15 more copies when I lowered the price to $200. Those sales proved that I wasn’t completely off base in thinking there was a market for the software, but the cost of customer acquisition and the size of the market were too small. Customers wanted to have a bunch of phone calls, face-to-face etc… the type of stuff you only see with much more expensive software. The problem was that for a niche this small we had to charge a lot of money to make it worthwhile for us, but the customers were small businesses where this is a major investment, so the fit was never right. The other issue was the people that did buy it were not super tech savvy, so there was a high cost of support that made even a $200 product not worth it.
What went wrong
* Having all partners who were not full-time, and had equal equity. I ended up doing most of the work and this is the main reason I didn’t force success is I felt I was in it alone.
* Focusing on too narrow of a niche. The plan all along was to expand for all service industries, but it was much harder to make that move than we expected.
* Not researching pricing more, we knew small businesses made major purchases for things that really helped their business, but I think it would have been better to have a cheaper product with wider appeal than an expensive product with narrow appeal.
Time/money invested
I invested maybe a year of time and $3k into the company. I did not take any huge risks on it, so there were no big negative outcomes.
Current product status
The company folded in 2007, I refocused my efforts on my existing companies (AUsedCar.com and BudgetSimple.com) and both have been doing well enough that I quit my day job.
Any regrets?
I don’t regret it entirely, I think I learned several valuable lessons about working with other people, small business sales, trade-shows and software development.
Lessons learned
* Pick partners wisely. Don’t try to be even-steven with equity. Use restricted stock to ensure everyone does their part.
* Know what your customers expect (24/7 phone support?) to determine if you can do this while working a day job.
Case #4: PC Desktop Cleaner
Contributor
Javier Rojas Goñi.
The product
PC Desktop Cleaner. Simple software that cleans your desktop and archives your files.
Why it was judged a commercial failure
My goal was to sell 10 units per month. I’ve sold less than 1 unit per month.
What went wrong
* I think that the product concept is not useful enough. It’s not a thing that people would pay for.
* The market exists (some people buy) but it’s too little or difficult to reach.
* I didn’t do any market research. I just got in love with the idea and did it. Later, I’ve learnt to use “lazy instantiation marketing” and have trashed a lot of embryo projects. :-)
Time/money invested
I think I wasted near $500 in development tools and some freelancers. Not too much.
Current product status
I’m still selling it. I’ve thought about others products, but not really decided yet.
Any regrets?
No, it was a lot of fun and I learnt lot of things. In my “day job” I own a small firm that sells software for production scheduling. I’ve learn a lot of SEO and AdWords in the DesktopCleaner project that now I’m using with great results.
Lessons learned
Go for it, maybe you win, maybe you fail, but you will grow and get tons of useful knowledge on the way.
Case #5: Smart Diary Suite
Contributor
Dennis Volodomanov.
The product
Smart Diary Suite.
Why it was judged a commercial failure
It sells and the profits cover current investments in the product, but there is little left over on top of that.
What went wrong
If I had a chance to do anything differently:
* Take it seriously from day one.
* Never stop developing and supporting.
* Invest as much as possible in marketing early on.
* Don’t stop believing in your creation.
Time/money invested
Up to this point, I have spent 13 years on Smart Diary Suite and a lot of money went into buying hardware, software, hosting, marketing, etc… All of that money came from my day job, but at this point SDS has recovered all of that back and is now making a small profit. The actual amount is hard to calculate (over the 13 year span), but we would be talking in tens of thousands of US dollars.
Current product status
For a while it may have seemed like SDS is not going to be successful, but that’s probably my fault – I stopped believing for a little while. Now I am back, starting again and this time I’ll make sure it doesn’t fail.
Any regrets?
I do not regret doing it. I regret allowing myself to stop working on it, basically bailing out on it for a while – that is my biggest mistake.
Lessons learned
If you want a successful product – believe in it and let others know that you believe in it.
Case #6: Highlighter
Contributor
Mike Sutton.
The product
Highlighter. A utility to print neatly formatted, syntax highlighted source code listings.
Why it was judged a commercial failure
I earnt a grand total of £442.52 (about $700 in todays money) in just over two years, so I guess it paid for itself if you exclude my time.
What went wrong
Since it was my first product and I was very green about both marketing and product development. I would suggest the following would have made things better:
* Get feedback from potential users about the product (eg from the ASP forums). Some parts of the program where probably too option heavy and geeky.
* Diversify. If people didn’t want to print fancy listings, maybe they would have wanted them formatted in HTML.
* Better marketing. I’m not sure this would have saved it, but all I knew in those days was uploading to shareware sites. I never even sent a press release.
I figure it failed simply because it was a product nobody wanted. Actually, more importantly than that,, it was a product *I* didn’t want to use, but it developed from a larger product I was working on, on the assumption I could earn some money on the side from part of the code. Since then I’ve stuck to products which I’ve actually wanted to use myself. There’s a lot to be said for dogfooding, not just for debugging, but for knowing where the pain points are and what extra features could be added.
Time/money invested
I would guess a couple of months of evening/weekend development time. Financially there was little spent, except that I offered the option of a printed manual and CD for an extra charge. One customer took me up on the offer, so I had to get 100 manuals printed and 99 of them went in the bin.
Current product status
I moved on to another product which has sold over £50,000 and a third which has earnt even more than that. Not enough to retire on but considering I only do this part time it must work out at a great hourly rate. There’s a lot to be said for not giving up…
Any regrets?
Nope. I figure every failure in life teaches you valuable lessons. Of course if I’d made a large financial investment I may feel differently, but that’s one of the big advantages of software over physical product sales.
Lessons learned
Just to reiterate – develop something which you find useful, instead of second guessing others.
Case #7: R10Clean
Contributor
Steve Cholerton.
The product
R10Clean. A data cleaning and manipulation tool.
Why it was judged a commercial failure
In the 18 months or so it’s been on the market I have sold 6. It has been £199, £99 and £19 – with no effect on sales !
What went wrong
Not sure what I did wrong ? The product is maybe too techie ?
Time/money invested
No effect financially as at the time I was in a strong financial position.
Current product status
I still have it for sale but do not market it at all. I have other products.
Any regrets?
I don’t regret it as it saved me a ton of time when I was working with legacy databases a lot, as a commercial product it has been raved about (once!) and received a good review from the Kleper report, but has failed totally.
Lessons learned
Advice to others ? Just because you need it personally, don’t assume the rest of the world does too. :-)
Case #8: nBinder
Contributor
Boghiu Andrei.
The product
nBinder, packs multiple files into a stand alone executable with over 50 advanced output and file unpack options, conditional run and commands.
Why it was judged a commercial failure
It was the first product I began selling. It sold to 300+ customers in 4 years. But for about a year the sales began to go down and have finally stopped completely.
What went wrong
* The biggest problem was that because it was a packer intended for people that wanted to pack their products (software or games) into a single package (compressed and encrypted) many have used it for creating malware by binding malware files to legit files and then distributing the output so it isn’t detected by antivrus software (although it would be detected at runtime). Because of this I had lots of problems with antivirus companies that flagged files create with nBinder as malware. This was of course affecting legit users as their files would be falsely marked as malware. I used virustotal.com to see which antivirus detected it and contacted the antivirus manufacturer as soon as I detected the problem. In most cases they would remove it from their definitions. But it was an uphill battle because it would appear again in a matter of weeks. Some small AV companies didn’t event bother to reply to my emails to fix the problem. Others were using heuristics to flag files create with my applications and AV developers were reluctant to whitelist files created with nBinder. You can imagine it that it was enough for an AV such as Kaspersky or Norton to pick my files as malware for a day and customers would be affected and not use my product any more, especially that it took about 3 days for AVs to remove the false positive.
* Infrequent updates. Due to lack of time I only updated the product once or twice a year and this affected the product a lot.
* No marketing. I decided that I didn’t want to invest money in marketing so, except for a short AdWords campaign, I invested no money in marketing.
* My decision to develop 3 products instead of concentrating on one or two affected development time and quality. I have worked on 3 products simultaneously instead of concentrating on making a single good one. The reason I worked on 3 is because I enjoyed developing different software in different categories. I didn’t start this for money but for the fun of development.
Time/money invested
I invested almost no money (except for hosting costs). Time invested I can’t really say exactly, but not too much as I only worked on nBinder in short bursts like 6 hours a day for a week or so before releases.
Current product status
Still for sale. My other products are:
* nCleaner – a free system cleaner that has gone quite well (over 2 million downloads).
* nMacro – an automation tool that has seen some limited success (bought by over 100 customers in a year or so).
Any regrets?
It’s not a total failure as I did make some money out of it with no investment, so I don’t regret starting it, but it could have been much better.
Lessons learned
Words of advice for others trying to make money from software development:
* Study the market and the current trends very well.
* Before deciding to take on large competition make sure you have something better (at least from one point of view) than the competition ( for example you might not have the same features but you have a better GUI and general presentation).
* Do not get scared of an overly populated market segment. For example with nBinder I picked a segment with very little competition but also few possible users and the results were not so great (I didn’t have many users). With nCleaner I went head-to-head with lots of already established products but also the market is very big. Although nCleaner is free it has had the most success because there are so many potential users (anyone with a PC actually), so it had over 2 millions downloads and I still receive lots of mails regarding it, even if the last update was in 2007. So it is possible to have success in a market with lots of competition with no investment but it’s hard to reach the level of more established products.
Case #9: Net-Herald
Contributor
Torsten Uhlmann.
The product
Net-Herald – a monitoring application for water supply companies. It was a complex client server application that would receive monitoring data from specialized hardware and store that data inside a SQL database. The client displays that data in different graphs, provides printable reports or sends alarm messages via SMS if a monitored value is not within its specified limits.
I developed Net-Herald as a perfect fit for that specialized hardware that is provided by a local manufacturer. That way, so I hoped, I could profit from their sales leads and would find a smoother way into these water supply companies. The downside of course, was that my software would only work with their hardware.
Why it was judged a commercial failure
I sold a first license fairly soon after I had a sellable product, although it took the customer nearly a year until they finally bought. But since then I sold only one more license within the last 4 years or so.
What went wrong
* I didn’t do my own marketing and the hardware guys weren’t really concerned with selling my software.
* Water management companies have a terribly long sales cycle. Other vendors monitoring applications usually cost tens of thousands and are geared toward large suppliers. Whenever a supplier buys into such a product he is unlikely to change within the next decade or more. I tried to position my software towards small suppliers but even then most of them were already locked into another vendor’s solution.
* My software only worked with a specific hardware. That narrowed the marked down substantially.
* In the end the software became too complex for one poor mortal to maintain. Because the software didn’t produce any substantial income I had to stop adding new features which would make it attractive for more prospective clients.
* This kind of software is not sold over the Internet. Rather it needs very active sales people that nurture clients over a rather long period of time.
* All these facts indicate that software like this should not be developed by a one man show.
Time/money invested
The development time for the first sellable version was maybe about 9 months. I didn’t have a job income at that time, but got funding due to government support for small start-up businesses. So I didn’t drain our family’s personal finances. But I did of course invest a great deal of time and sweat.
Current product status
Now, I have drawn a line and stopped active development of Net-Herald. I still do some custom extensions for my first clients. But I no longer market the software. I have instead focused on my consulting services. I also try to learn developing and selling software with my cross-platform drag and drop product Simidude.
Any regrets?
I didn’t succeed yet selling my own software (which is still my goal) but I do not regret doing it. I developed Net-Herald using (Java) technologies that now give me leverage at my consulting gigs. All in all it was a heavy ride. But it was fun and I would do it again.
Lessons learned
* My biggest mistake was the lack of market analysis. I trusted the word of the hardware manufacturer without verification.
* I have written more about the above and some other failures on my blog.
Case #10: HabitShaper
Contributor
Adriano Ferrari.
The product
HabitShaper – set and track daily targets for your goals (weight loss, quit smoking, jogging, writing, etc…).
Why it was judged a commercial failure
I sold a few copies, but not enough to make back the time I invested in it and my conversion numbers and traffic are below average.
What went wrong
* Did not do enough pre-production research (talking to customers, etc).
* Did not do a large enough beta to make up for lack of initial research.
* Ignored gut-feeling that my product is better suited to being web-based and multi-platform (incl. mobile).
* Did EVERYTHING myself (logo, web design, video, software, AdWords, etc).
Time/money invested
I worked on it two years, part-time, while doing Masters/PhD in Physics. It had no impact on my finances (very little money invested) or circumstances.
Current product status
I am relaunching as a web-based product this summer.
Any regrets?
Not in the least! I learned about as much from making HabitShaper as I have from my MSc thesis and PhD work.
Lessons learned
* Most important: PAPER prototypes, minimum viable product, and iterate.
* Don’t be afraid to launch early.
* Launch a little bigger than you’d expect (it’s harder to find those initial customers than you think).
* Don’t be afraid to change directions, especially early on.
* Doing things yourself is a great learning experience, but if you want to get your product out to customers as fast as possible, don’t be afraid to invest money and outsource your weaknesses.
Case #11: BPL
Contributor
Jim Lawless.
The product
BPL – Batch Programming Language Interpreter.
Why it was judged a commercial failure
I sold about 10 copies.
What went wrong
* I didn’t really do enough research to find out if the target market was in existence. I was hoping that network admins and support staff members would find it easier to use than batch files and less complicated than any of the free scripting language options available. So, I just rushed to get the MVP (Minimum Viable Product) out the door.
* I never did provide a compiler that would build a stand-alone EXE. I think that might have met with more success.
* I didn’t do much as far as advertising the existence of the product.
Time/money invested
I only spent a few weeks coding and documenting it in my spare time. Support issues sometimes took a whole evening, but nothing major. It did not have any impact on my finances as I had invested nothing but my time.
Current product status
I will still address support issues with this product for registered users, but I don’t actively sell it. I’ve open-sourced the program and it still really isn’t seeing heavy use.
I was more successful with other products. I have a few retired products that saw some good bulk-purchase deals ( command-line DUN HangUp, command-line scheduler ) and I still sell the following (for Windows):
* MailSend – Command-line SMTP mailer.
* MailGrab – Command-line POP3 reader.
* CMD2EXE – Packages up a batch file into an EXE.
* ScreenKap – Command-line screen capture.
All of the above still bring in a modest passive income.
Any regrets?
Not at all. “Nothing ventured,…”.
Lessons learned
Had I not attempted to bring the BPL product to life, I might still be sitting here wondering “what if?” I think it was very beneficial for me to invest the time to try out this idea.
Case #12: Anonymous
Contributor
Anonymous.
The product
A time tracker.
Why it was judged a commercial failure
Because it is not my primary income. I have about 150 customers in one year.
What went wrong
* No marketing.
* No real thought into features.
* I don’t spend any time on it.
In my defense, the reason I do not spend much time on it is that the market became saturated with ‘me toos’ right after I released, which was quite expected. In fact, as I was looking for users, I got an email from a competitor suggesting that I don’t enter the market because they are working on the same thing! I don’t know what I would do differently. Maybe spend more time on it? I think the law of diminishing returns applies quite early in this space so I am not sure.
Time/money invested
Since inception (Nov 2008), I’ve spent close to 250 hours total. Total cash outlay was something like $500.
Current product status
I never tried to make it succeed, to be honest. It was only a learning experience for me. What I probably need now is to go all in. Quite frankly, if I double the sales for this product, I can quit all consulting work. But I really do not think it is a good idea to work on this app full time as it is too simple.
Any regrets?
Definitely not.
Lessons learned
* Do it!
* Solve a problem people know they have.
* Don’t invest too much time and money at the beginning.
* Don’t be wedded to a particular idea.
* Don’t only listen to your customers. Listen to yourself. After all, you created the idea which attracted the customers.
* Never promise a feature for a sale. I’ve never done it but the pressure is really great. My stock response is always: “While such a feature may be available in the future, I recommend that you only use current features when deciding on your purchase.”
* Do use Google to your advantage.
Case #13: ScreenRest
Contributor
Derek Pollard.
The product
ScreenRest - a consumer software product that reminds users to take regular rest breaks while using their computer.
Why it was judged a commercial failure
ScreenRest failed commercially because we built a product without having a clearly defined market. This was compounded by it offering prevention, not a solution. ScreenRest continues to regularly sell a small number of licences but not in sufficient quantity to justify further enhancements. The conversion rates are good, but there are simply not enough visitors to the website.
What went wrong
* Not doing market research first.
* Creating a prevention rather than solution product – people generally wait until they have a problem and then look for a solution.
* Creating a product with medical associations – the SEO and PPC competition for related keywords is prohibitive for a product with a low purchase price.
Time/money invested
At least £2000 was spent on the project, including software licences and additional hardware. The product and website were created over roughly 12 months by myself and my wife Lindsay, some during spare time, then part-time and finally full-time so it is difficult to determine the total number of hours. Working part-time and then full-time on ScreenRest caused a significant impact on our finances. Although right from the beginning we saw this as in investment for building a business.
Current product status
Once the product was complete and we started learning SEO it became all too apparent that organic search traffic for related keywords was going to be insufficient. Research into PPC then revealed that the price point was too low to support purchasing medical terms. Planned features for ScreenRest have been put on hold and no further marketing is planned. We continue to support new and existing ScreenRest customers and plan to do so for the foreseeable future. Rather than create another software product we chose to use what we had learned about marketing, copywriting and SEO to create a series of websites targeting a range of topics (often known as niche sites). The most successful of these sites we are expanding in value and functionality to fill gaps not serviced by the competition.
Any regrets?
No. ScreenRest succeeded in every way intended, other than commercially. Creating it was a rewarding learning exercise that started us down a path to finding the intersection of our skills, experience and market opportunities.
Lessons learned
* Start with market research – creating a high-quality product you believe in is not enough on its own.
* Make sure you can identify a specific target market, that you can reach that market and that it is large enough to support your financial goals.
Conclusion
Analysing the above (admittedly small and self-selected sample) it is clear that by far the commonest cause of failure were:
* lack of market research
* lack of marketing
With the benefitof 20/20 hindsight it seems blindingly obvious that we should:
* spend a few days researching if a product is commercially viable before we spend months or years creating it
* put considerable effort into letting people know about the products we create
Yet, by my count, a whopping 6 out of 13 of us admitted to failing to do each of these adequately. Probably we were too busy obsessing over the features and technical issues so beloved of developers, which actually contributed to far fewer failures.
It is also noticeable that, despite the failure of these products, there are few regrets. Important lessons were learned and no-one lost their house. Many of us have gone to develop successful products and the others will be in a much stronger position if they do decide to try again.
A big thank you to everyone who ate a large slice of humble pie and submitted the above. I hope we can prevent other budding software entrepreneurs making the same mistakes. Even if you don’t succeed, you will learn a lot.
Source: Successful Software
Andy Brice from Successful Software blog just released an excellent article where he is featuring 13 examples of software launches gone sour.
The article cover thirteen different software products and their launches that didn’t turn out like the software creators expected.
There are many lessons to be learned and if you are serious about your Software Marketing I suggest you read through the whole article.
Some of the bigger takeaways are that the software authors failed to research the market enough before venturing out and creating their software and the failed to market it when the product was released.
Take it away Andy…
Software entrepreneur culture is full of stories of the products that succeeded. But what about the products that failed? We rarely hear much about them. This can lead to a very skewed perspective on what works and what doesn’t (survivor bias). But I believe that failure can teach us as much as success. So I asked other software entrepreneurs to share their stories of failure in the hope that we might save others from making the same mistakes. To my surprise I got excellent 12 responses, which I include below along with one of my own. It is a small sample and biased by self selection, but I think it contains a lot of useful insights. It is an unashamedly a long post, as I didn’t want to lose any of these insights by editing it down.
Case #1: DRAMA
Contributor
Andy Brice.
The product
DRAMA (Design RAtionale MAnagement) was a commercialization of a University prototype for recording the decision-making process during the design of complex and long-lived artefacts, for example nuclear reactors and chemical plants. By recording it in a structured database this information would still be available long after the original engineers had forgotten it, retired or been run over by buses. This information was believed to be incredibly valuable to later maintainers of the system, engineers creating similar designs and industry regulators. The development was part funded by 4 big process engineering companies.
Why it was judged a commercial failure
Everyone told us what a great idea it was, but no-one bought it. despite some early funding from some big process engineering companies, none of them put it into use properly and we never sold any licences to anyone else.
What went wrong
* Lack of support from the people who would actually have to use it. There are lots of social factors that work against engineers wanting to record their design rationale, including:
o The person taking the time to record the rationale probably isn’t the person getting the benefit from it.
o Extra work for people who are already under a lot of time pressure.
o It might make it easier for others to question decisions and hold companies and engineers accountable for mistakes.
o Engineers may see giving away this knowledge as undermining their job security.
* Problems integrating with the other software tools that engineers spend most of their time in (e.g. CAD packages). This would probably be easier with modern web-based technology.
* It is difficult to capture the subtleties of the design process in a structured form.
* A bad hire. If you hire the wrong person, you should face up to it and get rid of them. Rather than keep moving them around in a vain attempt to find something they are good at.
* We took a phased approach, starting with a single-user proof of concept and then creating a client-server version. In hindsight it should have been obvious that not enough people were actively using the single-user system and we should have killed it then.
Time/money invested
At least 3 man years of work went into this product, with me doing most of it. Thankfully I was a salaried employee. But the lack of success of this product contributed to the demise of the part of the company I was in.
Current product status
The product is long dead.
Any regrets?
It was a fairly painful experience. I would rather have spent all that money, time and energy on something that someone actually used. But at least I learnt some expensive lessons without using my own money.
Lessons learned
* Creating a new market is difficult and risky.
* Changing people’s working habits is hard.
* Social factors can make or break a product. The end-users didn’t see anything in it for them.
* If the end-users don’t like a product, they will find a way not to use it, even if their bosses appear to be enthusiastic about it.
* Talk is cheap. Lots of people telling you how great your product is doesn’t mean much. You only really find out if your product is commercially viable when you start asking people to buy it.
Case #2: CleanChief
Contributor
Sam Howley.
The product
CleanChief was to be ‘The easy management solution for cleaning organisations’. Managing assets, employee schedules, ordering supplies, you name it CleanChief handled it. Essentially it was light weight accounting software for cleaning companies.
Why it was judged a commercial failure
A small number of copies were sold. No one is actively using it at present. Once I realised that it wasn’t a complete product and that additional development was required I moved on to other product ideas. I had basically run out of enthusiasm for the product.
What went wrong
* I am not an accountant.
* I have never run a cleaning company.
* I developed it for more than two years without getting feedback from real cleaning companies. I was arrogant enough to think that I knew what they wanted (or could work it out on my own). Or maybe it was that I was just where I was most happy and comfortable – writing software. Talking to real users was new and to be honest a bit scary for me.
* A successful cleaning company operator, a friend of a friend, offered to become involved for a 30% share. This was a gift from the heavens, exactly what I needed. I refused.
* In a way, even though I spent so long on the product, I gave in too soon, I was just getting feedback from real users, just getting my first batch of sales when I decided to move on.
* I developed the application in VB6 even though I knew it was outdated technology when I started the project.This meant there was no ‘cool factor’ when discussing it with other developers, I told myself it didn’t bother me, but it probably did.
Time/money invested
I worked on it at night and weekends for about 2 1/2 years. I paid for graphic design work, purchased stock icons and images. I probably spent a couple of thousand Australian dollars in total and an awful lot of time.
Current product status
I moved on to other products that have gone much better. My newer products were released in months rather than years and I looked for real feedback from real users from day one. they are:
* QueryCell – an Excel add-in making SQL in Excel easy.
* QuizNightChief – the easy way to organise a quiz Night.
* CustomerCradle – The easiest way to record and report on where your customers come from.
I do occasionally ponder returning to CleanChief and trying to raise it from the ashes.
Any regrets?
No. Looking back I learned a few lessons from a huge amount of time and work, it was a very inefficient way to learn those lessons. But when you are new to something like starting a business or creating useful software being inefficient at learning lessons is the best you can do, it’s a thousand times better than not learning lessons at all.
I learned so much more in my two and a half years of trying to develop CleanChief than I did in the two and a half years prior to that, during which time I really wanted to start a software business but didn’t take any action.
Lessons learned
Hearing or reading some piece of advice is totally different to living it. Here are some of the ideas that I always agreed were true but didn’t fully understand the implications of until I had lived them out:
* Force yourself to get out and talk to people. Ask their advice. Almost everyone will help if you ask them for feedback.
* Force yourself to cold call a few businesses in your target market.
* Create a plan of how to market your product.
* Try and use your product as much as possible as you build it.
* Get out of your comfort zone from day one
* Do not have the mind set that the day you release version 1.0 is the finish line, it’s the starting line, so hurry up and get there.
Case #3: Chimsoft
Contributor
Phil Anderson.
The product
ChimSoft – Software for Chimney Sweeps.
Why it was judged a commercial failure
I believe this failed for two reasons:
* Focusing on too small of a niche
* Me not being able to work full time on it.
I don’t consider it a complete failure because I sold two copies when it retailed for $2k, and maybe 10-15 more copies when I lowered the price to $200. Those sales proved that I wasn’t completely off base in thinking there was a market for the software, but the cost of customer acquisition and the size of the market were too small. Customers wanted to have a bunch of phone calls, face-to-face etc… the type of stuff you only see with much more expensive software. The problem was that for a niche this small we had to charge a lot of money to make it worthwhile for us, but the customers were small businesses where this is a major investment, so the fit was never right. The other issue was the people that did buy it were not super tech savvy, so there was a high cost of support that made even a $200 product not worth it.
What went wrong
* Having all partners who were not full-time, and had equal equity. I ended up doing most of the work and this is the main reason I didn’t force success is I felt I was in it alone.
* Focusing on too narrow of a niche. The plan all along was to expand for all service industries, but it was much harder to make that move than we expected.
* Not researching pricing more, we knew small businesses made major purchases for things that really helped their business, but I think it would have been better to have a cheaper product with wider appeal than an expensive product with narrow appeal.
Time/money invested
I invested maybe a year of time and $3k into the company. I did not take any huge risks on it, so there were no big negative outcomes.
Current product status
The company folded in 2007, I refocused my efforts on my existing companies (AUsedCar.com and BudgetSimple.com) and both have been doing well enough that I quit my day job.
Any regrets?
I don’t regret it entirely, I think I learned several valuable lessons about working with other people, small business sales, trade-shows and software development.
Lessons learned
* Pick partners wisely. Don’t try to be even-steven with equity. Use restricted stock to ensure everyone does their part.
* Know what your customers expect (24/7 phone support?) to determine if you can do this while working a day job.
Case #4: PC Desktop Cleaner
Contributor
Javier Rojas Goñi.
The product
PC Desktop Cleaner. Simple software that cleans your desktop and archives your files.
Why it was judged a commercial failure
My goal was to sell 10 units per month. I’ve sold less than 1 unit per month.
What went wrong
* I think that the product concept is not useful enough. It’s not a thing that people would pay for.
* The market exists (some people buy) but it’s too little or difficult to reach.
* I didn’t do any market research. I just got in love with the idea and did it. Later, I’ve learnt to use “lazy instantiation marketing” and have trashed a lot of embryo projects. :-)
Time/money invested
I think I wasted near $500 in development tools and some freelancers. Not too much.
Current product status
I’m still selling it. I’ve thought about others products, but not really decided yet.
Any regrets?
No, it was a lot of fun and I learnt lot of things. In my “day job” I own a small firm that sells software for production scheduling. I’ve learn a lot of SEO and AdWords in the DesktopCleaner project that now I’m using with great results.
Lessons learned
Go for it, maybe you win, maybe you fail, but you will grow and get tons of useful knowledge on the way.
Case #5: Smart Diary Suite
Contributor
Dennis Volodomanov.
The product
Smart Diary Suite.
Why it was judged a commercial failure
It sells and the profits cover current investments in the product, but there is little left over on top of that.
What went wrong
If I had a chance to do anything differently:
* Take it seriously from day one.
* Never stop developing and supporting.
* Invest as much as possible in marketing early on.
* Don’t stop believing in your creation.
Time/money invested
Up to this point, I have spent 13 years on Smart Diary Suite and a lot of money went into buying hardware, software, hosting, marketing, etc… All of that money came from my day job, but at this point SDS has recovered all of that back and is now making a small profit. The actual amount is hard to calculate (over the 13 year span), but we would be talking in tens of thousands of US dollars.
Current product status
For a while it may have seemed like SDS is not going to be successful, but that’s probably my fault – I stopped believing for a little while. Now I am back, starting again and this time I’ll make sure it doesn’t fail.
Any regrets?
I do not regret doing it. I regret allowing myself to stop working on it, basically bailing out on it for a while – that is my biggest mistake.
Lessons learned
If you want a successful product – believe in it and let others know that you believe in it.
Case #6: Highlighter
Contributor
Mike Sutton.
The product
Highlighter. A utility to print neatly formatted, syntax highlighted source code listings.
Why it was judged a commercial failure
I earnt a grand total of £442.52 (about $700 in todays money) in just over two years, so I guess it paid for itself if you exclude my time.
What went wrong
Since it was my first product and I was very green about both marketing and product development. I would suggest the following would have made things better:
* Get feedback from potential users about the product (eg from the ASP forums). Some parts of the program where probably too option heavy and geeky.
* Diversify. If people didn’t want to print fancy listings, maybe they would have wanted them formatted in HTML.
* Better marketing. I’m not sure this would have saved it, but all I knew in those days was uploading to shareware sites. I never even sent a press release.
I figure it failed simply because it was a product nobody wanted. Actually, more importantly than that,, it was a product *I* didn’t want to use, but it developed from a larger product I was working on, on the assumption I could earn some money on the side from part of the code. Since then I’ve stuck to products which I’ve actually wanted to use myself. There’s a lot to be said for dogfooding, not just for debugging, but for knowing where the pain points are and what extra features could be added.
Time/money invested
I would guess a couple of months of evening/weekend development time. Financially there was little spent, except that I offered the option of a printed manual and CD for an extra charge. One customer took me up on the offer, so I had to get 100 manuals printed and 99 of them went in the bin.
Current product status
I moved on to another product which has sold over £50,000 and a third which has earnt even more than that. Not enough to retire on but considering I only do this part time it must work out at a great hourly rate. There’s a lot to be said for not giving up…
Any regrets?
Nope. I figure every failure in life teaches you valuable lessons. Of course if I’d made a large financial investment I may feel differently, but that’s one of the big advantages of software over physical product sales.
Lessons learned
Just to reiterate – develop something which you find useful, instead of second guessing others.
Case #7: R10Clean
Contributor
Steve Cholerton.
The product
R10Clean. A data cleaning and manipulation tool.
Why it was judged a commercial failure
In the 18 months or so it’s been on the market I have sold 6. It has been £199, £99 and £19 – with no effect on sales !
What went wrong
Not sure what I did wrong ? The product is maybe too techie ?
Time/money invested
No effect financially as at the time I was in a strong financial position.
Current product status
I still have it for sale but do not market it at all. I have other products.
Any regrets?
I don’t regret it as it saved me a ton of time when I was working with legacy databases a lot, as a commercial product it has been raved about (once!) and received a good review from the Kleper report, but has failed totally.
Lessons learned
Advice to others ? Just because you need it personally, don’t assume the rest of the world does too. :-)
Case #8: nBinder
Contributor
Boghiu Andrei.
The product
nBinder, packs multiple files into a stand alone executable with over 50 advanced output and file unpack options, conditional run and commands.
Why it was judged a commercial failure
It was the first product I began selling. It sold to 300+ customers in 4 years. But for about a year the sales began to go down and have finally stopped completely.
What went wrong
* The biggest problem was that because it was a packer intended for people that wanted to pack their products (software or games) into a single package (compressed and encrypted) many have used it for creating malware by binding malware files to legit files and then distributing the output so it isn’t detected by antivrus software (although it would be detected at runtime). Because of this I had lots of problems with antivirus companies that flagged files create with nBinder as malware. This was of course affecting legit users as their files would be falsely marked as malware. I used virustotal.com to see which antivirus detected it and contacted the antivirus manufacturer as soon as I detected the problem. In most cases they would remove it from their definitions. But it was an uphill battle because it would appear again in a matter of weeks. Some small AV companies didn’t event bother to reply to my emails to fix the problem. Others were using heuristics to flag files create with my applications and AV developers were reluctant to whitelist files created with nBinder. You can imagine it that it was enough for an AV such as Kaspersky or Norton to pick my files as malware for a day and customers would be affected and not use my product any more, especially that it took about 3 days for AVs to remove the false positive.
* Infrequent updates. Due to lack of time I only updated the product once or twice a year and this affected the product a lot.
* No marketing. I decided that I didn’t want to invest money in marketing so, except for a short AdWords campaign, I invested no money in marketing.
* My decision to develop 3 products instead of concentrating on one or two affected development time and quality. I have worked on 3 products simultaneously instead of concentrating on making a single good one. The reason I worked on 3 is because I enjoyed developing different software in different categories. I didn’t start this for money but for the fun of development.
Time/money invested
I invested almost no money (except for hosting costs). Time invested I can’t really say exactly, but not too much as I only worked on nBinder in short bursts like 6 hours a day for a week or so before releases.
Current product status
Still for sale. My other products are:
* nCleaner – a free system cleaner that has gone quite well (over 2 million downloads).
* nMacro – an automation tool that has seen some limited success (bought by over 100 customers in a year or so).
Any regrets?
It’s not a total failure as I did make some money out of it with no investment, so I don’t regret starting it, but it could have been much better.
Lessons learned
Words of advice for others trying to make money from software development:
* Study the market and the current trends very well.
* Before deciding to take on large competition make sure you have something better (at least from one point of view) than the competition ( for example you might not have the same features but you have a better GUI and general presentation).
* Do not get scared of an overly populated market segment. For example with nBinder I picked a segment with very little competition but also few possible users and the results were not so great (I didn’t have many users). With nCleaner I went head-to-head with lots of already established products but also the market is very big. Although nCleaner is free it has had the most success because there are so many potential users (anyone with a PC actually), so it had over 2 millions downloads and I still receive lots of mails regarding it, even if the last update was in 2007. So it is possible to have success in a market with lots of competition with no investment but it’s hard to reach the level of more established products.
Case #9: Net-Herald
Contributor
Torsten Uhlmann.
The product
Net-Herald – a monitoring application for water supply companies. It was a complex client server application that would receive monitoring data from specialized hardware and store that data inside a SQL database. The client displays that data in different graphs, provides printable reports or sends alarm messages via SMS if a monitored value is not within its specified limits.
I developed Net-Herald as a perfect fit for that specialized hardware that is provided by a local manufacturer. That way, so I hoped, I could profit from their sales leads and would find a smoother way into these water supply companies. The downside of course, was that my software would only work with their hardware.
Why it was judged a commercial failure
I sold a first license fairly soon after I had a sellable product, although it took the customer nearly a year until they finally bought. But since then I sold only one more license within the last 4 years or so.
What went wrong
* I didn’t do my own marketing and the hardware guys weren’t really concerned with selling my software.
* Water management companies have a terribly long sales cycle. Other vendors monitoring applications usually cost tens of thousands and are geared toward large suppliers. Whenever a supplier buys into such a product he is unlikely to change within the next decade or more. I tried to position my software towards small suppliers but even then most of them were already locked into another vendor’s solution.
* My software only worked with a specific hardware. That narrowed the marked down substantially.
* In the end the software became too complex for one poor mortal to maintain. Because the software didn’t produce any substantial income I had to stop adding new features which would make it attractive for more prospective clients.
* This kind of software is not sold over the Internet. Rather it needs very active sales people that nurture clients over a rather long period of time.
* All these facts indicate that software like this should not be developed by a one man show.
Time/money invested
The development time for the first sellable version was maybe about 9 months. I didn’t have a job income at that time, but got funding due to government support for small start-up businesses. So I didn’t drain our family’s personal finances. But I did of course invest a great deal of time and sweat.
Current product status
Now, I have drawn a line and stopped active development of Net-Herald. I still do some custom extensions for my first clients. But I no longer market the software. I have instead focused on my consulting services. I also try to learn developing and selling software with my cross-platform drag and drop product Simidude.
Any regrets?
I didn’t succeed yet selling my own software (which is still my goal) but I do not regret doing it. I developed Net-Herald using (Java) technologies that now give me leverage at my consulting gigs. All in all it was a heavy ride. But it was fun and I would do it again.
Lessons learned
* My biggest mistake was the lack of market analysis. I trusted the word of the hardware manufacturer without verification.
* I have written more about the above and some other failures on my blog.
Case #10: HabitShaper
Contributor
Adriano Ferrari.
The product
HabitShaper – set and track daily targets for your goals (weight loss, quit smoking, jogging, writing, etc…).
Why it was judged a commercial failure
I sold a few copies, but not enough to make back the time I invested in it and my conversion numbers and traffic are below average.
What went wrong
* Did not do enough pre-production research (talking to customers, etc).
* Did not do a large enough beta to make up for lack of initial research.
* Ignored gut-feeling that my product is better suited to being web-based and multi-platform (incl. mobile).
* Did EVERYTHING myself (logo, web design, video, software, AdWords, etc).
Time/money invested
I worked on it two years, part-time, while doing Masters/PhD in Physics. It had no impact on my finances (very little money invested) or circumstances.
Current product status
I am relaunching as a web-based product this summer.
Any regrets?
Not in the least! I learned about as much from making HabitShaper as I have from my MSc thesis and PhD work.
Lessons learned
* Most important: PAPER prototypes, minimum viable product, and iterate.
* Don’t be afraid to launch early.
* Launch a little bigger than you’d expect (it’s harder to find those initial customers than you think).
* Don’t be afraid to change directions, especially early on.
* Doing things yourself is a great learning experience, but if you want to get your product out to customers as fast as possible, don’t be afraid to invest money and outsource your weaknesses.
Case #11: BPL
Contributor
Jim Lawless.
The product
BPL – Batch Programming Language Interpreter.
Why it was judged a commercial failure
I sold about 10 copies.
What went wrong
* I didn’t really do enough research to find out if the target market was in existence. I was hoping that network admins and support staff members would find it easier to use than batch files and less complicated than any of the free scripting language options available. So, I just rushed to get the MVP (Minimum Viable Product) out the door.
* I never did provide a compiler that would build a stand-alone EXE. I think that might have met with more success.
* I didn’t do much as far as advertising the existence of the product.
Time/money invested
I only spent a few weeks coding and documenting it in my spare time. Support issues sometimes took a whole evening, but nothing major. It did not have any impact on my finances as I had invested nothing but my time.
Current product status
I will still address support issues with this product for registered users, but I don’t actively sell it. I’ve open-sourced the program and it still really isn’t seeing heavy use.
I was more successful with other products. I have a few retired products that saw some good bulk-purchase deals ( command-line DUN HangUp, command-line scheduler ) and I still sell the following (for Windows):
* MailSend – Command-line SMTP mailer.
* MailGrab – Command-line POP3 reader.
* CMD2EXE – Packages up a batch file into an EXE.
* ScreenKap – Command-line screen capture.
All of the above still bring in a modest passive income.
Any regrets?
Not at all. “Nothing ventured,…”.
Lessons learned
Had I not attempted to bring the BPL product to life, I might still be sitting here wondering “what if?” I think it was very beneficial for me to invest the time to try out this idea.
Case #12: Anonymous
Contributor
Anonymous.
The product
A time tracker.
Why it was judged a commercial failure
Because it is not my primary income. I have about 150 customers in one year.
What went wrong
* No marketing.
* No real thought into features.
* I don’t spend any time on it.
In my defense, the reason I do not spend much time on it is that the market became saturated with ‘me toos’ right after I released, which was quite expected. In fact, as I was looking for users, I got an email from a competitor suggesting that I don’t enter the market because they are working on the same thing! I don’t know what I would do differently. Maybe spend more time on it? I think the law of diminishing returns applies quite early in this space so I am not sure.
Time/money invested
Since inception (Nov 2008), I’ve spent close to 250 hours total. Total cash outlay was something like $500.
Current product status
I never tried to make it succeed, to be honest. It was only a learning experience for me. What I probably need now is to go all in. Quite frankly, if I double the sales for this product, I can quit all consulting work. But I really do not think it is a good idea to work on this app full time as it is too simple.
Any regrets?
Definitely not.
Lessons learned
* Do it!
* Solve a problem people know they have.
* Don’t invest too much time and money at the beginning.
* Don’t be wedded to a particular idea.
* Don’t only listen to your customers. Listen to yourself. After all, you created the idea which attracted the customers.
* Never promise a feature for a sale. I’ve never done it but the pressure is really great. My stock response is always: “While such a feature may be available in the future, I recommend that you only use current features when deciding on your purchase.”
* Do use Google to your advantage.
Case #13: ScreenRest
Contributor
Derek Pollard.
The product
ScreenRest - a consumer software product that reminds users to take regular rest breaks while using their computer.
Why it was judged a commercial failure
ScreenRest failed commercially because we built a product without having a clearly defined market. This was compounded by it offering prevention, not a solution. ScreenRest continues to regularly sell a small number of licences but not in sufficient quantity to justify further enhancements. The conversion rates are good, but there are simply not enough visitors to the website.
What went wrong
* Not doing market research first.
* Creating a prevention rather than solution product – people generally wait until they have a problem and then look for a solution.
* Creating a product with medical associations – the SEO and PPC competition for related keywords is prohibitive for a product with a low purchase price.
Time/money invested
At least £2000 was spent on the project, including software licences and additional hardware. The product and website were created over roughly 12 months by myself and my wife Lindsay, some during spare time, then part-time and finally full-time so it is difficult to determine the total number of hours. Working part-time and then full-time on ScreenRest caused a significant impact on our finances. Although right from the beginning we saw this as in investment for building a business.
Current product status
Once the product was complete and we started learning SEO it became all too apparent that organic search traffic for related keywords was going to be insufficient. Research into PPC then revealed that the price point was too low to support purchasing medical terms. Planned features for ScreenRest have been put on hold and no further marketing is planned. We continue to support new and existing ScreenRest customers and plan to do so for the foreseeable future. Rather than create another software product we chose to use what we had learned about marketing, copywriting and SEO to create a series of websites targeting a range of topics (often known as niche sites). The most successful of these sites we are expanding in value and functionality to fill gaps not serviced by the competition.
Any regrets?
No. ScreenRest succeeded in every way intended, other than commercially. Creating it was a rewarding learning exercise that started us down a path to finding the intersection of our skills, experience and market opportunities.
Lessons learned
* Start with market research – creating a high-quality product you believe in is not enough on its own.
* Make sure you can identify a specific target market, that you can reach that market and that it is large enough to support your financial goals.
Conclusion
Analysing the above (admittedly small and self-selected sample) it is clear that by far the commonest cause of failure were:
* lack of market research
* lack of marketing
With the benefitof 20/20 hindsight it seems blindingly obvious that we should:
* spend a few days researching if a product is commercially viable before we spend months or years creating it
* put considerable effort into letting people know about the products we create
Yet, by my count, a whopping 6 out of 13 of us admitted to failing to do each of these adequately. Probably we were too busy obsessing over the features and technical issues so beloved of developers, which actually contributed to far fewer failures.
It is also noticeable that, despite the failure of these products, there are few regrets. Important lessons were learned and no-one lost their house. Many of us have gone to develop successful products and the others will be in a much stronger position if they do decide to try again.
A big thank you to everyone who ate a large slice of humble pie and submitted the above. I hope we can prevent other budding software entrepreneurs making the same mistakes. Even if you don’t succeed, you will learn a lot.
Source: Successful Software
Sunday, July 18, 2010
Tuesday, July 6, 2010
International Postgraduate Research Scholarships 2011, Australia
Job Description: The main objectives of the IPRS program are to:
* attract top quality international postgraduate students to areas of research strength in Australian higher education providers; and
* support Australia’s research effort.
The IPRS program enables international students to undertake a postgraduate research qualification in Australia and gain experience with leading Australian researchers.
Scholarships are open to international students of all countries (except New Zealand) and are available for a period of two years for a Masters by research degree or three years for a Doctorate by research degree. The scholarship covers tuition fees and health cover costs for scholarship holders, and health cover costs for their dependants.
Applications for a scholarship need to be made directly to a participating university. Universities are responsible for determining the selection process by which scholarships are allocated to applicants.
Application Deadline September 30,2010
For further information
http://www.studyinaustralia.gov.au/Sia/en/Links/Universities.htm
* attract top quality international postgraduate students to areas of research strength in Australian higher education providers; and
* support Australia’s research effort.
The IPRS program enables international students to undertake a postgraduate research qualification in Australia and gain experience with leading Australian researchers.
Scholarships are open to international students of all countries (except New Zealand) and are available for a period of two years for a Masters by research degree or three years for a Doctorate by research degree. The scholarship covers tuition fees and health cover costs for scholarship holders, and health cover costs for their dependants.
Applications for a scholarship need to be made directly to a participating university. Universities are responsible for determining the selection process by which scholarships are allocated to applicants.
Application Deadline September 30,2010
For further information
http://www.studyinaustralia.gov.au/Sia/en/Links/Universities.htm
Friday, July 2, 2010
18 Memory Tricks You Need to Know
By Patricia Curtis
Can't remember where you put your glasses? Blanked on your new colleague's name? "Forgetting these types of things is a sign of how busy we are," says Zaldy S. Tan, MD, director of the Memory Disorders Clinic at Beth Israel Deaconess Medical Center in Boston. "When we're not paying good attention, the memories we form aren't very robust, and we have a problem retrieving the information later."
The key, says Harry Lorayne, author of Ageless Memory: Simple Secrets for Keeping Your Brain Young, is to get your brain in shape. "We exercise our bodies, but what good is that great body if you don't have the mental capabilities to go with it?" Sure, you could write everything down, keep organized lists and leave electronic notes on your BlackBerry, cell phone or PDA. But when you don't have access to those aids, or if you want to strengthen your brain, try these expert-recommended strategies to help you remember.
Brain Freeze: "What the heck is his name?"
1. Pay attention. When you're introduced to someone, really listen to the person's name. Then, to get a better grasp, picture the spelling. Ask, "Is that Kathy with a K or a C?" Make a remark about the name to help lock it in ("Oh, Carpenter -- that was my childhood best friend's last name"), and use the name a few times during the conversation and when you say goodbye.
2. Visualize the name. For hard-to-remember monikers (Bentavegna, Wobbekind), make the name meaningful. For Bentavegna, maybe you think of a bent weather vane. Picture it. Then look at the person, choose an outstanding feature (bushy eyebrows, green eyes) and tie the name to the face. If Mr. Bentavegna has a big nose, picture a bent weather vane instead of his nose. The sillier the image, the better.
3. Create memorable associations. Picture Joe Everett standing atop Mount Everest. If you want to remember that Erin Curtis is the CEO of an architectural firm, imagine her curtsying in front of a large building, suggests Gini Graham Scott, PhD, author of 30 Days to a More Powerful Memory.
4. Cheat a little. Supplement these tips with some more concrete actions. When you get a business card, after the meeting, jot down a few notes on the back of the card ("red glasses, lives in Springfield, went to my alma mater") to help you out when you need a reminder.
Brain Freeze: "Where in the world did I leave my glasses?"
5. Give a play-by-play. Pay attention to what you're doing as you place your glasses on the end table. Remind yourself, "I'm putting my keys in my coat pocket," so you have a clear memory of doing it, says Scott.
7. Make it a habit. Put a small basket on a side table. Train yourself to put your keys, glasses, cell phone or any other object you frequently use (or misplace) in the basket -- every time.
Brain Freeze: "What else was I supposed to do today?"
8. Start a ritual. To remind yourself of a chore (write a thank-you note, go to the dry cleaner), give yourself an unusual physical reminder. You expect to see your bills on your desk, so leaving them there won't necessarily remind you to pay them. But place a shoe or a piece of fruit on the stack of bills, and later, when you spot the out-of-place object, you'll remember to take care of them, says Carol Vorderman, author of Super Brain: 101 Easy Ways to a More Agile Mind.
9. Sing it. To remember a small group of items (a grocery list, phone number, list of names, to-do list), adapt it to a well-known song, says Vorderman. Try "peanut butter, milk and eggs" to the tune of "Twinkle, Twinkle, Little Star," "Happy Birthday" or even nursery rhymes.
10. Try mnemonic devices. Many of us learned "ROY G BIV" to remember the colors of the rainbow, or "Every Good Boy Deserves Favors" to learn musical notes. Make up your own device to memorize names (Suzanne's kids are Adam, Patrick and Elizabeth, or "APE"), lists (milk, eggs, tomatoes, soda, or "METS") or computer commands (to shut down your PC, hit Control+Alt+Delete, or "CAD").
11. Use your body. When you have no pen or paper and are making a mental grocery or to-do list, remember it according to major body parts, says Scott. Start at your feet and work your way up. So if you have to buy glue, cat food, broccoli, chicken, grapes and toothpaste, you might picture your foot stuck in glue, a cat on your knee looking for food, a stalk of broccoli sticking out of your pants pocket, a chicken pecking at your belly button, a bunch of grapes hanging from your chest and a toothbrush in your mouth.
12. Go Roman. With the Roman room technique, you associate your grocery, to-do or party-invite list with the rooms of your house or the layout of your office, garden or route to work. Again, the zanier the association, the more likely you'll remember it, says Scott. Imagine apples hanging from the chandelier in your foyer, spilled cereal all over the living room couch, shampoo bubbles overflowing in the kitchen sink and cheese on your bedspread.
Brain Freeze: "What's my password for this website?"
13. Shape your numbers. Assign a shape to each number: 0 looks like a ball or ring; 1 is a pen; 2 is a swan; 3 looks like handcuffs; 4 is a sailboat; 5, a pregnant woman; 6, a pipe; 7, a boomerang; 8, a snowman; and 9, a tennis racket. To remember your ATM PIN (4298, say), imagine yourself on a sailboat (4), when a swan (2) tries to attack you. You hit it with a tennis racket (9), and it turns into a snowman (8). Try forgetting that image!
14. Rhyme it. Think of words that rhyme with the numbers 1 through 9 (knee for 3, wine for 9, etc.). Then create a story using the rhyming words: A nun (1) in heaven (7) banged her knee (3), and it became sore (4).
Brain Freeze: "The word is on the tip of my tongue."
15. Practice your ABCs. Say you just can't remember the name of that movie. Recite the alphabet (aloud or in your head). When you get to the letter R, it should trigger the name that's escaping you: Ratatouille. This trick works when taking tests too.
Brain Freeze: "I just can't memorize anything anymore!"
16. Read it, type it, say it, hear it. To memorize a speech, toast or test material, read your notes, then type them into the computer. Next, read them aloud and tape-record them. Listen to the recording several times. As you work on memorizing, remember to turn off the TV, unplug your iPod and shut down your computer; you'll retain more.
17. Use color. Give your notes some color with bolded headings and bulleted sections (it's easier to remember a red bullet than running text).
18. Make a map. Imagine an intersection and mentally place a word, fact or number on each street corner.
Subscribe to:
Posts (Atom)