Exec Summary: No company can cater to all customers. A roadmap allows customers to see if your product is right for them. An API allows customers to create their own, customised interface to your core product.
A while back, I wrote a blog post explaining what an API is. However, I never explained “why” APIs exist…at least not from a business perspective (I did explain that an API allows for customisation of the interface to a product).
However, there are more fundamental business reasons behind APIs.
Many small companies and startups produce a single software product. Even large companies have been known to spin-off a smaller company for single product development (outside of the silos) because of the flexibility inherent a smaller company.
A small company has its limitations, not least of which is manpower. All of the developers within a small software company will be working on the core product, whether that be bug-fixes, new features, or examples to showcase the product.
In order to sell the product, however, a company needs to cater to the needs of its customers. Customers always have their own specific wants (which will be presented as “needs”), their own preferred ways of doing things, and, most importantly, their own software dependencies. Startups, in particular, will bend over backwards in order to get customers at the start. The product features will be shaped by those early-adopter customers.
But kowtowing to customer demands is not scalable. No company, no matter how big, can afford to tailor their product towards one particular customer’s desires and technology (unless their business model is to only have one customer). Moreover, constantly tailoring a product to multiple customers’ desires is a recipe for disaster and burnout (and probably insolvency).
Thankfully, there are ways to address customer needs while still providing a best-in-class core product. Two of the most important weapons in an expanding software company’s arsenal are (1) a product roadmap and (2) an API.
Product Roadmap
What executives in business want more than anything is stability and certainty, especially when it comes to small companies or startups. They want to know that, if they invest in your product, that the product will still exist (with support) in a year’s time. Having a product roadmap will address these fears by showing that your company has planned for the future, and that the founders are concentrating on the product and not just an exit strategy.
More importantly, from a limited resources point of view, a product roadmap tells customers, “this is the direction that the product will take, and if you don’t like it, then you’re not our target customer”. Not only does the product roadmap filter out “bad” customers, saving the sales and marketing people time, but it also puts in stone the upcoming new features of the product. This in turn allows salespeople to point at the roadmap and say “that feature is due in August” or to say “that feature is not planned, but I will try to get it put on the roadmap”. If the feature is subsequently added to the roadmap, the customer will know for when it is planned, and can plan accordingly. If the feature is denied, then the customer may not be the target customer for that product.
While turning down a customer may be possible for more established businesses, it is particularly difficult for a startup (they need the cash-flow) and for a salesperson (they want the commission).
This is where the API comes in.
API
An API has been described (by me) as the strings by which a controller (the custom portal/interface) is attached to a marionette (the product). The controller can be customised for the user without affecting the underlying core product.
By providing an API, you are asking customers to develop their own interface to your product. In this way, the customers themselves can provide the tweaks necessary to fit their own needs, while still using the core product.
For example, a customer might want your product to pull elements from a database. If you build native database support into your product, you are now either limited to supporting one specific kind of database, or you are setting yourself up to develop and support multiple databases for multiple customers. This kind of support and development is not the core of your software product and, therefore, a waste of time.
If the API allows users to import and export files from your product, there is no need to build in native database support. Any customer can write some code that will pull an element from their own database and then import it into your product (or vice versa). This generic hook allows for the greatest flexibility when it comes to meeting customer requirements.
An API must, however, be well built. Terence Eden writes in his blog about the minimum requirements of an API in order to attract developers. Companies like APIphany can help with this. If your API is well built and easy to use, customers are not going to resist doing their own customisations (well, not as much) leaving you free to concentrate on development of the core product and features.
(update: 08/08/2012)
I forgot to mention IFTTT (IF This, Then That) which is a small “if” statement for webapps. You can trigger something in one webapp if something else happens in another webapp. It’s a great example of what one can do with APIs in terms of integration (or making two products play nicely together).
Conclusion:
So, remember:
Roadmap – reduces customer uncertainty, enables salespeople to sell the correct (core) product
API – enables customers to build their own customisations to meet their own needs, enables the integration of other products for easy partnerships that drive sales
musings 