Why do we need APIs? (and a product roadmap)

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

Advertisement

User Experience as a USP

Exec Summary – User Experience (UX) is increasingly becoming the USP of similar products. Easy-to-use means lower costs and quicker efficiencies gained on the learning curve. This in turn can be used to show the bottom-line benefits of a product.

The learning curve is also a reason why User Experience (UX) is becoming such a hot issue at the moment. As our world and gadgets become more complex, there comes a point at which the law of diminishing returns kicks in and some things are simply not worth the effort. If, however, that effort is minimal, then the value offered by the product does not have to be as huge in order for people to buy it.

Obviously, this doesn’t change the basics of strategy/sales – you still have to offer a larger benefit than your competition. However, if the products offer a very similar outcome, the one that is easiest (or more intuitive) to use will usually win. This is more and more becoming something that customers value as a unique selling proposition (USP).

Consumer attention spans are waning. People want the outcome itself, not to spend time learning how to achieve that outcome.

For example, I was recently examining technical support ticket desk SaaS products. My needs were as follows:

1. access for external customers controlled via login
2. simple and automatic segregation of tickets based on a customer
3. reports to show time spent on a particular customer
4. submission of tickets by email
5. knowledge base (also access-controlled)

Some products were aimed at internal IT desks within a large corporation (and seemed very good at that job) and therefore I did not fit their customer profile. However, many (most?) other products were aimed at customers exactly like me. Of these, all of them addressed the points on my checklist above – but they did so in very different ways.

I’m not going to name any names, but, in my eyes, there were clear winners and losers.

One product in particular (let’s call it “Product A”) had a powerful and flexible product that met my needs. Unfortunately, all of that complexity was visible at once when using the product. There were so many menus and buttons shown that my poor 13″ laptop screen was overwhelmed – nearly half the screen was taken up by them, leaving me with little room for anything else (1024×768 people!).

The other products I saw (also complex and powerful) had far simpler interfaces, with the complexity…not hidden, but tucked away inside an intuitive menu system. The same functionality as in Product A was easy to find, but did not use up all of my screen’s real-estate. Furthermore, were I to place one of my non-technical salespeople in front of Product A, they would be just as overwhelmed as my screen by all of the options. Simply answering a ticket would be a struggle. Many would need to be answered before any efficiencies would kick in. For this reason alone, Product A did not make the cut.

Product B, the product that was eventually chosen, provides a far simpler experience to the end-user. My salesperson can log in, see what tickets are assigned to them, and answer those tickets via a simple interface. The complexity is hidden from the user and only accessible to an admin like myself – which is, I think, how it should be. The time that I invest in setting up the system is an up-front/one-off chunk of time. Once the system has been set up, it should then operate in that way for as long as is needed. The complex options do not need to be visible to everybody.

In summary, user experience and the learning curve are very closely linked these days. The internet has made it cheaper and easier for products to be launched, many of them attacking the same user segments. The key differentiator of these products is increasingly becoming how easy they are to learn/use. Easier to use means quicker efficiencies gained, which means lower training costs, which means it is easier to justify expenditure on that system with a cost-benefit analysis.

Update – 17 Sept 2012: This is a really good article along the same lines from Fast Company Design. It talks about how a good User Interface will play a huge part in any startup’s bid to be great.

What is an API?

In my current job, I’ve had a lot to do with our product’s Application Programming Interface (API) – namely documenting it. For those of us who live in the technical world, we’ve dealt with APIs for many years and take them for granted. However, for those who live outside the technical world, an API is just another techie-TLA. The documentation with any API tells us how to use it, but not fundamentally what it is.

So here is my attempt at a simplified, non-technical analogy of an API.

Imagine, if you will, a puppet. We want to make the puppet dance. To do this, we grab the puppet by the arms, lift it, and make it perform a dance. This is akin to controlling a product (the puppet) through its native User Interface (its limbs). In other words, it is controlling the puppet using the bits that the puppet-maker made.

However, there comes a day when we want to control the puppet using two wooden sticks in the shape of an X.

Why would we want to do this? Well, for a start, it gives us a lot more control over our interface to the puppet. Because we have direct control over the sticks, we can customise them to fit our hands perfectly. We can paint the sticks any colour we want without affecting the puppet in any way. We could, if we wished, connect the same part of the stick to both the right arm and the right leg, meaning that these limbs would both move in unison with only one twitch of our hand.

This allows full control over the look and feel of the controlling interface.

With this in mind, we design our two sticks in the way that makes them a perfect fit for our hands. This leaves us with a puppet, and a controlling interface. All we have to do now, is hook them up.

With what does one connect a puppet to a stick? String, of course.

These strings allow for the movements made with the wooden X to directly control the movements of the puppet. And, as mentioned above, those movements can be customised, depending on where and how one ties the strings.

So a standard product (the puppet) is being controlled (via string) from a customised interface (the two sticks).

In this case:
– the puppet is the underlying product/program.
– the sticks represent the interface – designed, built and customised by you, the user.
– the strings are the API – they are what connect the controlling interface to the underlying product.

The end of a string is a somewhat generic connector. In other words, strings can be connected to almost anything. They could be tied directly to your fingers, meaning you’re the only one who can control the puppet; they could be tied to some kind of robot, which could make the puppet dance automatically; they could be tied to the two sticks, and those sticks can be given to anyone (or anything), allowing control of the puppet by whomever has the sticks.

This is the same for an API. The API allows a custom interface to control a product using a generic/standardised method. This allows for the control of a product from a custom-branded portal/interface. The interface designed by you can be an intuitive interface for your customers’ needs, saving you the cost of developing the underlying product.

It opens up a whole new layer for user experience design – one that does not need to involve creating an actual product. If the product is good, and can be controlled via an API, then there’s nothing to stop you adding value through a more intuitive interface. This allows the product’s developers to concentrate on the core product, while you can create the interface. And, as Apple has shown, a good interface can go a long way.

Moreover, it opens up an easy route for partnerships between technical companies. A customer might want a whole solution, but the best companies might be the best because they have concentrated on one specific area (“core competencies”” and all that). Using APIs, an interface can be developed that will use the best products out there, and seamlessly integrate them via their associated APIs. This is a win-win situation – the customer gets the best products, and the companies get sales.

So, hopefully, this will demystify APIs somewhat for those from a non-technical background. They are simply a means to attach one’s own controlling interface to a product, allowing for custom designs and/or automation.

All that you need to worry about now is checking that the underlying puppet isn’t Pinocchio, about to develop a mind of its own and not obey the strings.