All last week we focused on Autodesk Exchange, looking at the steps needed for preparing, submitting and re-submitting your app for inclusion on the Apps tab.
I won’t dwell too much more on the topic, but did just want to give some quick, high-level tips for people thinking about posting apps for inclusion on Autodesk Exchange. (My thanks to Stephen Preston – who has been intimately involved in the Apps tab since its inception – for helping brainstorm some of these items.)
1. Focus on software quality
We do test the applications submitted to us before posting them on Autodesk Exchange, but we may not catch everything. If your software is of poor quality, with significant issues that “clearly” should have been picked up in testing, your customers will vote with their feet and stop using the app. And what’s worse (or better, from an eco-system perspective), they’ll give your app a poor rating.
Some basic suggestions around software quality:
- Make sure your code has robust error-handling and reporting. Consider implementing a mechanism that writes errors and significant events to a log-file, which can later be transmitted to you for analysis.
- Test, test, test.
- You need to invest in Quality Assurance. Inadequate testing – and therefore premature release to customers – will very likely kill your app.
- Respond to feedback quickly and courteously.
- Monitor feedback received via your support alias and deal with it effectively. A negative product experience can be turned into a positive one, if handled well.
2. Check the language quality
First impressions are not made from the software but from the documentation presented to the user. If you have poorly written text accompanying your – quite possibly excellent – app, many users will just run away.
Have someone with an aptitude for the English language check and correct your submission. This may be a native English speaker, but be aware there are native English speakers who do not write at all well (just as there are people whose mother tongue is not English who somehow manage to write it excellently).
Ultimately you should find someone you can trust (and still check their edits, before submitting ;-).
3. Think about the user experience
The first two points clearly feed into this third one: we are working really hard to maintain a quality experience with apps posted on Autodesk Exchange – consistent usage documentation, one-click installation, logical location of ribbon items – so do think about it carefully with respect to your own application.
If you can get user feedback to help you hone the usability of your application – just as Autodesk does at a larger scale – then this will really help you. But otherwise at least try to think about usage from a customer experience perspective: it’s no longer a given that technical software has to be arcane and difficult to master.
4. Protect your IP investment appropriately
Consider implementing obfuscation, if you have a .NET app you don’t wish to be decompiled.
Also, there is no direct mechanism provided for “locking” your software, to stop it from being copied from one system to another. If you feel some kind of licensing mechanism is needed – given the investment you’ve made in your application, possibly over many years – then you will need to implement or procure such a system yourself.
My main piece of advice in this area is that the protection should be appropriate for your Intellectual Property investment.
For instance, if you have an inexpensive (or free) application that did not take long to develop, it probably makes sense to go “light” on locking: you have more to lose by upsetting customers (making them jump through hoops) than you do by preventing abuse. I believe most people to be fundamentally honest and happy to pay when it’s easy to do so.
On a related note, think about providing bulk- or site-licensing terms for your customers.
5. Don’t be greedy
My recollection – and I could well have this wrong – is that Apple expected an average price of $10 to be paid for an iPhone app, back in the early days of their App Store. The reality ended up being at around the $1 mark.
That’s not to say the same dynamic is at play for AutoCAD applications, too, but I do expect much of the initial wave of “sales” to be from customers who want to get stuff for free. Think about this when you price your application, and whether you provide a full app or a functionally-limited trial version. There’s a lot of benefit to be derived from creating awareness around your apps, goodwill you can hopefully monetise in the long run.
In conclusion…
Over time, I expect Autodesk Exchange to be a significant driver of third-party software sales to Autodesk customers. It’s still early days, though: only users of English AutoCAD 2012 who access Autodesk Exchange (i.e. they haven’t clicked the checkbox to stop it from showing on startup, or they click the icon to launch it, from time to time) – and are aware of the availability of the Apps tab – will even consider downloading apps.
As we build awareness around this mechanism, popularity will inevitably rise: all the more reason to get something up there soon, to ride that adoption wave. ;-)
